web-dev-qa-db-ja.com

HTTPSプロキシは、HTTPリクエストのプロキシクライアントとサーバー間のトラフィックを暗号化しますか?

DIY方式で検閲を回避するために、私は個人用にプライベートプロキシを設定する予定です。私が試みる可能性のある方法の1つは、ISPによって検閲されていない海外サーバーでホストされているHTTPSプロキシ(明示的には、Webプロキシではない)を使用することです。

ただし、HTTPプロキシとHTTPSプロキシの違いについて読んだ内容では、プロキシクライアントとプロキシサーバー間のトラフィックの暗号化に関する懸念を明らかにするのに十分な情報が得られませんでした。これは、による検閲の緩和を成功させるために重要です。

この図 によると、HTTPSプロキシ経由でのHTTP URIの取得は、暗号化されていないHTTP GETリクエストの前にSSL/TLSハンドシェイクが実行されることを除いて、通常のHTTP経由で取得する場合と違いはありません。これが事実である場合、URLフィルタリングとDPIが私の代わりに長い間実装されているため、プロキシとの通信はほぼ確実にリセットされます。したがって、HTTPSプロキシの使用は非常に制限されます。HTTP転送されたサイトに、「YouTubeやFacebookなど」を指すURLを含む[Share to ...]ボタンがある場合、これを検出してプロキシサーバーに通信できます。その後、中断されます。

さらに、メインストリームブラウザーのプロキシ設定ページで、ユーザーにHTTPとHTTPSの異なるプロキシを指定するオプションが与えられていることを確認しました。これは、HTTPプロキシまたはHTTPSプロキシ、あるいはその両方を介したHTTPリクエストは決して暗号化できないことを意味します。少なくとも定義された従来の方法で?

プロキシクライアントとプロキシサーバー間のすべてのトラフィックが、HTTPまたはHTTPSであるかどうかに関係なく、確実に暗号化されている場合にのみ、HTTPSプロキシの構築を開始します。ただし、開始TCP接続を除きますそして握手。

この問題の説明を楽しみにしています。

9
Yann Ren

段階的に確認する方が簡単な場合があります。まず、HTTP全体(SSLなし)では、HTTP要求はヘッダーのコレクションであり、ターゲットURLを示し、TCP接続(通常はポート80))を介して送信されます。リクエストヘッダーは、通常GETまたはPOSTである「動詞」で始まります。

プロキシがある場合、リクエストはプロキシに送信されます。次に、プロキシはターゲットサーバー(または別のプロキシ)への接続を開き、その新しい接続を介して要求を転送します。応答は同じパスを逆方向にたどります。

次にSSLに入ります。 SSLは次の方法でHTTPと結合されます:TCP接続が確立されると、SSLハンドシェイクが実行され、クライアントとサーバー間に暗号化されたトンネルが確立されます。HTTPリクエストはこのトンネル内で送信されます。

プロキシが存在する場合、SSLを利用したサーバーと通信したいクライアントはCONNECTリクエストを送信します。要求は、ターゲットサーバーの名前とポートを識別します。次に、プロキシはそのサーバー(TCP)に接続し、バイトを前後に転送します。 SSLハンドシェイクは、クライアントとサーバー間で発生します。プロキシは「外側」に保持されます。プロキシ(およびクライアントとプロキシの間、およびプロキシとサーバーの間の回線上の盗聴者)は引き続きハンドシェイクメッセージを表示できるため、どのサーバーに接続しているかを知ることができます(特に Server Name Indication を介して)。サーバーから送り返された証明書も)。

プロキシ自体がまたSSLサーバーである場合があります。その場合、クライアントとプロキシ間の通信自体がSSLトンネルにカプセル化されます。クライアントからプロキシへの接続がSSLで保護されている場合、クライアントとプロキシの間の回線上の盗聴者は、クライアントがプロキシと通信していることを知ることができますが、要求と応答を見ることができません。特に、最終的なターゲットサーバーのIDを知ることはできません。

2つのSSLは無相関です。人々が「HTTPSプロキシ」と言うとき、それらは2つの異なることを意味するかもしれないので、これはいくつかのかなりの混乱を意味します。

  • 「CONNECT」動詞を認識し、SSLを利用した最終的なターゲットサーバーに接続を転送できるプロキシ。
  • それ自体がSSLサーバーであり、クライアントとのSSLに関与するプロキシで、要求と応答がクライアントとプロキシの間を通過するときにそれらを保護します。

2つの特性は互いに直交しているため、どちらか一方、または両方を取得できます。両方がある場合、クライアントは実際に2つのSSL接続を管理し、一方は他方にネストされます。


クライアントとプロキシの間の回線で盗聴者を倒したい場合、攻撃者の目的が、話しているサイトのIDを推測することである場合、SSLを利用したプロキシ、つまり、SSLを単独でサポートするプロキシが必要です。 ;また、CONNECTをサポートするプロキシが必要になるため、SSLを利用したプロキシの保護下でHTTPとHTTPSの両方のWebサイトを閲覧できます。

特定のプロキシが特定のプロトコルをサポートする場合とサポートしない場合があるため(少なくとも概念的には、プロキシは「接続」要求の理解を拒否する場合があります)、Webブラウザは、使用するプロトコルの種類に基づいて異なるプロキシを使用するように構成できます。あなたの場合、これは混乱を増すだけです。

別の方法は、SOCKSプロキシを使用することです。これは [〜#〜] ssh [〜#〜] で簡単に設定できます。 SSH搭載のSOCKSプロキシを使用すると、ブラウザから発信されるすべての通信は、クライアントマシンとプロキシサーバー間のSSHトンネルを経由します。

16
Tom Leek