クライアントからのセキュリティで保護されていない http トラフィックをセキュリティで保護された https トラフィックとしてサーバーに転送し、再び戻す透過的なプロキシを開発しようとしています。私の主張をよりよく説明するために、次の画像を見てください。
さまざまな理由で、クライアントが HTTP のみを使用し、HTTPS にポート 443 を使用できないとします。一部のサーバーはポート 80 からのトラフィックを受け入れないため、プロキシはそれらをポート 443 に再ルーティングする必要があります。これは考えられるシナリオです。
- www.google.com に向かってポート 80 に向かうクライアントからデータを受信します。
- https://www.google.comとの接続をポート 443 に初期化します (ハンドシェイクなどを行います)
- クライアントからのデータを暗号化し、https://www.google.comのポート 443 に送信します。
- https://www.google.comから応答を受け取り、それらを復号化し、クライアントのポート 80 に送り返します。
これは透過的なプロキシであるため、クライアント (私の場合は多数) に追加の構成は必要ありません。トラフィックがノードを通過するように、ネットワークはすでに構成されています。現在、私のノードは単にデータを再ルーティングし、ウイルスが含まれている場合は一部をブロックします。これは、WinPcapを使用して下位のネットワーク レイヤーにアクセスすることによって行われますが、生のパケットを使用して行うのが難しすぎる場合 (主にハンドシェイクが懸念されます)、アプローチを変更してもかまいません。
私が試したこと: 注: www.google.com は、ウェブ上の任意のサイトである可能性があります。これは単に例として使用されています。
- イリジウムの提案。別のアプリケーションが TcpClient を使用して接続する場合、TcpListener は新しい接続のみを受け入れるため、これは機能しません。これは透過プロキシであるため、機能しません。
- 代わりに HttpListener を使用します。ただし、自分の IP (www.google.com ではなく) への接続のみを受け入れるため、これは機能しないようです。
- 前と同じように HttpListener を使用しますが、今回はパケットを自分の IP に転送して、HttpListener が接続を受け入れるようにします。何らかの理由で、これは機能していないようです (wireshark を介して検査すると、TCP SYN パケットが再送信され続けますが、理由や修正方法がわかりません)。
- SslStream を使用してhttps://www.google.comに接続し、クライアントから受信した生のパケットからコンテンツを取得してストリームに書き込みます。SslStream は TCP パケット (ACK や SYN など) を単独で処理するため、これは機能しません。ストリームは Http リクエストのみを想定しています。それが機能しないもう 1 つの理由は、ストリームから TCP パケットの内容を読み取ることができず、HTTP 応答の内容しか読み取れないためです (したがって、クライアントはそこに座って ACK を待っています)。
- クライアントからの TCP パケットをそのままポート 443 に転送し、サーバーからポート 80 に転送し (HTTP 要求と応答のみが SSL で暗号化されるため、違いはありません)、HttpRequest クラスを使用してすべての http 要求を作成します。および応答 (クラスが独自にハンドシェイクを処理するため)。両側で ACK が間違っているため、これは機能しません。
そのようなプロキシを開発するための最良の方法は何でしょうか?
編集: TcpListener または HttpListener が透過プロキシとして機能する方法はありますか? (クライアントのコンピューターでの構成なし)。クライアントが接続しようとしていることを HttpListener が正確に認識するのはいつですか?