web-dev-qa-db-ja.com

透過SSLプロキシのセットアップ

ポート80を通過するトラフィックを検査するために、2つのネットワークカードでLinuxボックスをセットアップしました。1つはインターネットへの送信に使用され、もう1つはネットワークスイッチに接続されています。ポイントは、デバッグのためにそのスイッチに接続されたデバイス上のすべてのHTTPおよびHTTPSトラフィックを検査できることです。

次のiptablesのルールを作成しました。

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

192.168.2.1:1337では、記録にCharles（ http://www.charlesproxy.com/ ）を使用する透過的なhttpプロキシを使用しています。

ポート80はすべて問題ありませんが、ポート1337を指すポート443（SSL）に同様のルールを追加すると、チャールズ経由の無効なメッセージに関するエラーが発生します。

Charlesと同じコンピュータで以前SSLプロキシを使用しました（ http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ）が、透過的にそれを行うことに失敗しましたなんらかの理由。私がググったいくつかのリソースはそれは不可能だと言います-誰かが理由を説明できれば、私はそれを答えとして受け入れたいと思います。

注として、私はサブネットに接続されたすべてのクライアントを含む、説明されているセットアップへの完全なアクセス権を持っているので、Charlesによる自己署名証明書を受け入れることができます。理論的には、透過プロキシはすべて機能するため、ソリューションはチャールズ固有である必要はありません。

ありがとう！

編集：少し遊んだ後、特定のホストで機能させることができました。 iptablesを次のように変更すると（リバースプロキシ用にチャールズで1338を開きます）：

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

応答は得られますが、宛先ホストがありません。リバースプロキシで、1338からのすべてがヒットしたい特定のホストに行くことを指定するだけで、ハンドシェイクが適切に実行され、SSLプロキシをオンにして通信を検査できます。

1338からのすべてがそのホストに行くと想定したくないので、セットアップは理想的ではありません-宛先ホストが削除されている理由は何か？

再度、感謝します

ssliptableshttpstransparent-proxyman-in-the-middle
14
badunk

あなたが見ている問題は同じです それは単一のIPアドレス/ポートで複数の証明書の使用を妨げます（サーバー名表示を使用せずに） 。

プレーンHTTPでは、透過プロキシは、Hostヘッダーを調べることにより、クライアントが接続するホストを通知できます。

HTTPS MITM透過プロキシが要求を受け取ったとき、そもそもクライアントが要求していたホスト名を知ることができません。 （これらのルールでIPアドレスを取得できるかどうかさえわかりませんが、一般的なケースでは機能しそうにありませんが、少なくともDNSの逆引き参照を使用して推測することができた可能性があります）。

  • 予想されるホスト名を取得するために、MITMプロキシはHTTPメッセージのHostヘッダーを読み取る必要があります。これは、ハンドシェイクが成功した後にのみ発生します。
  • ハンドシェイクを成功させるために、MITMプロキシは予想されるホスト名に一致するスプーフィング証明書を生成する必要があります。

その結果、MITMプロキシは、ハンドシェイクの前に生成する証明書を認識できません。

これは、少なくともHTTP CONNECTメソッドを介して目的のホスト名を取得するため、非透過的なMITMプロキシで機能します。

10
Bruno

このトピックに関するいくつかの基本的な情報。

私が知っているこのアクションを成功裏に実行できるデバイスはごくわずかです。ただし、一般の人々は実際には利用できません。私自身は、SSLオフロードを備えたFortinet Fortigateを使用しています。

基本的には次のことを行います。ホストへのSSL接続を傍受し、ハードウェアで接続を復号化してから、目的の場所を検査し、その情報に基づいてファイアウォールの決定を行います。

その後、データを取得するためにそのホストへの独自の接続をセットアップし、ユーザーが提供するCAを使用して元の要求にクライアントに再署名します。この作業を円滑に行うには、クライアントの信頼されたルートCAにCAが存在する必要があります。

これらの種類の設定は、インターネットの使用に関する会社のポリシーを実施するために組織で使用されます。 Active Directoryを使用するので、会社のCAをクライアントに簡単にインストールできます。これは、大規模な組織では問題になりません。

SSLトラフィックIS暗号化されているため、これは手動プロキシを作成せずに行うことができる唯一の方法です。基本的にMITMであるため、法的問題をカバーすることが重要です。

3
Jochen Oonincx

あなたが見たかもしれないこの他の質問には、さらにいくつかの提案があります： 透過的なSSLプロキシの神話と事実 。そして、透明なSSLプロキシになるようにSquidを設定する方法を正確に説明するこのリンクがあります。それはあなたが探しているものではありませんが、少なくとも何が悪いのかについての洞察をあなたに与えるかもしれません。

Iptablesのルールは問題ないように見えますが、使用しているプロキシソフトウェアが目的の処理を実行できるかどうかはわかりません。ドキュメントは確かにこれが事実であると主張しています。

1
chutz

ブルーノのソリューションに追加するために、私は少し調査し、理想的ではない別のクイックフィックスを取得した方法を共有したいと思いました。

これらのiptablesを設定した後、ポート1338にリバースプロキシを配置し、ポート1337のlocalhostに転送することができます。ポート1337は透過的なhttpプロキシであり、データは復号化されているため、Hostヘッダーを取得して宛先にしますホスト。

主な欠点は、基本的にhttps接続をhttpに変換したことです。これは、すべてのサーバーで常に機能するわけではありません（ここで公開しているセキュリティホールは言うまでもありません）。

私は自分のソフトウェアの制限内で作業していました。ブルーノによるよりクリーンな解決策は、1338年からのすべてのトラフィックを復号化する必要があると想定することだと思います。復号化後、宛先ホストを検査し、SSLを使用して要求をプロキシします。

0
badunk