HTTPS経由でのプロキシサーバーの認証
HTTPS経由でWebサイトを閲覧する場合、Webブラウザーは通常、バックグラウンドで多くの作業を行います-安全なチャネルのネゴシエーション、サイトの証明書の検証、信頼チェーンの検証など。
ブラウザーがWebプロキシを使用するように構成されている場合、現在のHTTPプロトコルはCONNECTメソッドをサポートします。これにより、ブラウザーはWebサイトへのTLSトンネルをセットアップできます。もちろん、サイト）。
ブラウザはプロキシサーバーのIDに関して何をしますか？
プロキシに証明書がない場合、MitMによって偽装される可能性があります。
プロキシdoesに証明書があっても、チェックされていない場合は、偽装できる可能性があります。
プロトコル（または関連するRFC）は、これをどのように処理するかを定義していますか？一般的なWebブラウザーは通常、どのようにこれを処理しますか？
プロキシに証明書がない場合、ユーザーにフィードバックはありますか？プロキシに証明書はあるが無効な場合、フィードバックはありますか？
さらに、リクエストがプレーンHTTPの場合でも、Webプロキシを安全に認証するための対策はありますか？
たとえば、WebサイトへのリクエストがHTTPを介していても、HTTPSを介してプロキシに接続しています...
プロキシを介してトンネリングされているか、SSLチェーンをインターセプトするかどうかに関係なく、websiteを識別する方法を尋ねていないことに注意してください。
むしろ、許可されていないサーバーがMitMingしていないことを確認するためにproxy自体のIDを確認したい...
慣例として、最初に、尋ねられた正確な質問に答えましょう。
現在、HTTPSを使用したproxyへの接続は広くサポートされていません。 squid documentation には、この件に関するいくつかの情報があります。まとめると：
Chromeではサポートされていますが、GUIサポートがないため、 プロキシ自動構成スクリプト を介して構成する必要があります。これは、「システム全体のプロキシ構成」を使用するnotも意味します。
Firefoxはそれをサポートしていませんが、この機能は2007年以降にリクエスト済みとしてマークされています。（更新： FF 33+でサポート ）
他のブラウザでは何も表示されません。「まったくサポートされていない」ことを意味すると推測できます。
プロキシの「やや無効な」証明書が検出されたときにChromeが何をするかをテストする必要がありますが、ブラウザの正確なバージョンに依存している可能性があります（これは常に変化し、多くの場合透過的に）オペレーティングシステム（証明書の処理はOSに委任される傾向があるため）、および証明書が有効ではない方法（期限切れ、不正なサーバー名、不明なトラストアンカーなど）。また、固有のチキンとここでの卵の問題： X.509 によって義務付けられている完全な証明書の検証には、失効のチェック、つまりパス内のすべての証明書のCRLのダウンロードが含まれます。CRLダウンロードのURLは通常、証明書自体にあります。ただし、HTTPトラフィックにプロキシを使用している場合、CRLのダウンロードはそのプロキシを経由する必要があります...まだプロキシ証明書を検証していません。チキンも卵もありません。
また、プロキシの自動構成ファイル形式はHTTPSプロキシを実際にはサポートしていないことにも注意してください。このファイルには正式なstandardはありませんが、習慣は 古いNetscapeドラフト に従うことです。これは、PACファイルがプロキシを返すJavascript関数を定義していることを示していますホスト名とポート、ただしプロトコルではありません。つまり、HTTPSはありません。 HTTPSプロキシのサポートのために、Chromeは暗黙的にこの拡張機能を使用しますデファクト規約により、HTTPS URLに権限がない場所に詰め込み、それからいくつかの意味をなすブラウザ。
慣例として、どのような代替提案ができるか見てみましょう。
クライアントとプロキシ間の保護された通信を確実にするために、次の2つのソリューションが適用できる場合があります。
[〜＃〜] vpn [〜＃〜]を使用します。これは非常に汎用的であり、OSレベルで動作するため、すべてのブラウザーに適用されます。もちろん、クライアントにものをインストールする人machineがそのマシンの管理者権限を持っている必要があります（単純な非特権ユーザーとしてこれを行うことはできません）。
SSHベースのSOCKSプロキシを使用します。クライアントシステムで、次を実行します。
ssh -N -D 5000 theproxy;次に、localhost:5000をSOCKSプロキシとして使用するようにブラウザを設定します。このソリューションでは、プロキシサーバー（theproxy）もSSHサーバーであり、アカウントがあり、悪質なファイアウォールによってSSHポートがブロックされていないことが必要です。
SOCKSプロキシソリューションは、トラフィックが確実にプロキシマシンを通過するようにしますが、cachingは含まれません。これは、通常最初にプロキシを使用する理由の1つです。ただし、いくつかの追加ツールを使用して変更できます。 SOCKSプロキシとは、カスタムトンネルを介してすべてのTCP/IPトラフィックを（一般的に）リダイレクトすることです。アプリケーションの一般的なサポートは、通常のOSレベルのネットワーク呼び出しをSOCKSを使用するバージョンに「置き換える」ことで可能です。実際には、これは特定のDLLが標準OSライブラリにプッシュされます。これは nixベースのシステムでサポートされています とLD_PRELOADを使用します。これはWindowsでも実行できると仮定すると、完全なソリューションは次のようになります。
- クライアントからプロキシマシンへのSSHベースのSOCKSトンネルを使用します。
- SOCKSクライアントDLLはブラウザに適用され、SOCKSプロキシとして
localhost:5000を使用するように設定されています。 - ブラウザは
theproxy:3128を単純なHTTPプロキシとして使用したいだけです。
次に、ブラウザが参照するときに、theproxy:3128への接続を開きます。これは、DLLがインターセプトし、localhost:5000に開くSOCKSトンネルにリダイレクトします。その時点で、SSHはデータを取得し、SSHトンネルの保護下でtheproxyに送信します。データはtheproxyに存在し、この時点でポート3128への接続は純粋にローカルです（したがって、ネットワークベースの攻撃者から）。
SSH-SOCKSセットアップにキャッシングを追加する別の方法は、 透過プロキシ を適用することです。 Squidはそれを行うことができます （「インターセプトキャッシング」という名前で）。
SSH保護でキャッシングを行う別の方法は、SSHを使用してマシンからプロキシへの一般的なトンネルを構築することです。これを実行してください：
ssh -N -L 5000:localhost:3128 theproxy
次に、localhost:5000を[〜＃〜] http [〜＃〜]プロキシ（SOCKSではない）として使用するようにブラウザを設定します。これはFTPやGopherなどの代替プロトコルにはプロキシを適用しませんが、とにかくそれらを使用するのは誰ですか？
慣例として、質問をしてみましょう。
man-in-the-middle攻撃 から保護したいと言っています。しかし、実際には、プロキシisはMitMです。本当に欲しいのは、プロキシがMitMを行うonlyエンティティであることです。ブラウザとプロキシ（またはSSH-SOCKSまたはVPN）間のHTTPSでは、クライアントとプロキシ間のリンクのみを保護でき、プロキシとターゲットWebサーバー間のリンクは保護できません。過酷な場所であることが知られているワイドインターネットで何が起こるかを考慮せずにMitM攻撃が確実に阻止されると主張するのはおかしいでしょう。
MitMに対するエンドツーエンドの保護のために、SSLを使用します。つまり、HTTPS Webサーバーを参照します。ただし、これを行うと、ブラウザからプロキシへのリンクをさらに保護する必要がなくなります。
プロキシ認証を検討する場合、ブラウザとプロキシ間のトラフィックを保護することは理にかなっています。一部のプロキシは、サービスへのアクセスを許可する前に明示的な認証を必要とします。これは、大企業では一般的でした（？プロキシにパスワードを送信する場合、パスワードがスパイされることを望まないため、SSLを使用します。ただし、ローカルネットワークを盗聴できる攻撃者は、必然的に1つのローカルマシンを管理者権限で制御します（おそらく、彼が持ってきたラップトップ）。彼の迷惑な力は、インターネット帯域幅の単純なリーチングをはるかに超えています。また、インターネットアクセスをユーザーごとベースで制限すると、最新のオペレーティングシステムへのマッピングが不十分になり、ソフトウェアの更新など、多くのタスクでインターネットアクセスに依存する傾向があります。インターネットアクセスは使用量ごとに基づいてより効率的に制御されます。
したがって、HTTPプロキシへのアクセスの保護hasにはいくつかのメリットがありますが、それはかなり珍しいシナリオでのみです。特に、ほとんどのMitM攻撃を無効にすることとはほとんど関係がありません。
クライアント側のChromeとプロキシ側のSquidは、https経由で機能します。詳細は Secure Web Proxy を参照してください。
Chromeが無効なプロキシ証明書について警告を表示しますが、この設定の経験がないため確認できません。）.
@Thomas Porninの回答を使用する代わりに（SSHの使用を提案）、サービスバスを使用して、ローカルポートからリモートサーバーへの透過的な接続を維持できます。
「認証」は、プロキシクライアントソフトウェアがサービスバスに接続するときに発生します。このサービスバスのエンドポイントは、イントラネット、企業プロキシなど、何でもかまいません。クライアントソフトウェアがユーザーを認証すると、ミニVPNが（SSHのように）作成されます。
はじめに
この.Netクライアントはローカルにインストールされ、ターゲットは信頼する必要があるプロキシまたはその他のデバイスです。
Install Port Bridge
注：SQLクライアントと1433を任意のポートに精神的に置き換えます...これはすべてこれと同じですTCPベースのプロキシ
このプロジェクトにより、複数のNAT化されたサーバーが、単一のサービスバス接続を介してインターネット経由で複数のNAT化されたクライアントにアクセスできます。
それは本当にあなたを考えさせるかなりスマートな実装です。以下はソースです
http://blogs.msdn.com/b/clemensv/archive/2009/11/18/port-bridge.aspx
...と同じの別の説明。
http://brentdacodemonkey.wordpress.com/2010/05/05/Azure-appfabric-%e2%80%93-a-bridge-going-anywhere/
また、codeplexに「SocketShifter」と呼ばれる関連プロジェクトがあります： http://socketshifter.codeplex.com/ codeplexサイトはportbridgeの使用を勧めていますが、 （2010年8月）時点のinsであり、どちらがより最新であるかは不明です。調査する価値があるかもしれません。