0

Boost ASIO を使用して単純な HTTP/HTTPS プロキシを作成しようとしています。HTTP は問題なく動作していますが、HTTPS に問題があります。記録のために、これはローカル プロキシです。とにかく、これはトランザクションが私のセットアップでどのように機能するかの例です。

ブラウザが Google.com を要求する
ブラウザに嘘をつき、127.0.0.1 :443 に移動するように指示する
ブラウザ ソケットが 443 でローカル サーバーに接続する
ヘッダーを読み取ろうとするので、実際のホスト ルックアップを実行して 2 番目のアップストリームを開くことができますソケットを使用して、リクエストを簡単に転送できます。

これは、物事がすぐに失敗する場所です。着信ソケットのヘッダーを印刷しようとすると、要求を行っているブラウザーによって既に暗号化されているように見えます。最初は、ごちゃごちゃしたコンソール出力はヘッダーが圧縮されているだけだと思っていましたが、徹底的なテストを行った結果、そうではありませんでした。

だから、誰かが私を正しい方向に向けることができるかどうか疑問に思っています.おそらく、ここで何が起こっているのかをよりよく理解できる読み物に. 「サーバー」(私のプロキシ) への接続が完了してクライアントと通信する前に、ヘッダーがすぐに暗号化されるのはなぜですか? 一時キーですか？初期ヘッダーを無視して、クライアントにどの一時キーを使用するか、または圧縮/暗号化しないかを伝えるコマンドを送り返す必要がありますか? 助けてくれてありがとう、私はしばらくこれにこだわっていました。

4

1 に答える 1

0

HTTPS は、安全な SSL 接続を介してすべての HTTP トラフィック、ヘッダーなどを渡します。これは、本質的に中間者攻撃である、まさにあなたがやろうとしていることを防ぐための設計によるものです。成功するには、SSL セキュリティを無効にする方法を考え出す必要があります。

これを行う 1 つの方法は、ブラウザが受け入れる SSL 証明書を提供することです。ブラウザーが証明書について不平を言う一般的な理由がいくつかあります。(1) ブラウザーが信頼する機関によって証明書が署名されていない、(2) 証明書の共通名 (CN) が URL ホストと一致しない。

ブラウザー環境を制御している限り、(1) は、独自の認証局(CA) を作成し、その証明書をオペレーティング システムやブラウザーで信頼できるものとしてインストールすることで簡単に修正できます。次に、プロキシで、CA によって署名された証明書を提供します。基本的に、プロキシが提供する証明書を信頼しても問題ないことをブラウザに伝えています。

(2) は、HTTP ヘッダーを読み取ってブラウザーが到達しようとしていたホストを特定する前に、証明書に正しい CN を指定する必要があるため、より困難になります。さらに、要求される可能性のあるホストがわかっている場合を除き、一致する証明書を動的に生成 (および署名) する必要があります。おそらく、プロキシに IP アドレスのプールを使用し、スプーフィング DNS サービスと調整して、どの接続でどの証明書を提示する必要があるかを知ることができます。

一般に、HTTPS プロキシはお勧めできません。ブラウザのセキュリティの粒度に実際に逆らうことになるので、私はそれを思いとどまらせます。

この本は SSL/TLS のリファレンスとして気に入りました。OpenSSLなどのツールを使用して、独自の証明書を作成および署名できます。

于 2013-03-01T19:51:05.887 に答える