透過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による自己署名証明書を受け入れることができます。理論的には、透過的なプロキシが行うため、ソリューションはCharles固有である必要はありません。

ありがとう！

編集：少し遊んだ後、特定のホストで動作するようになりました。iptablesを次のように変更すると（およびリバースプロキシ用にcharlesで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からのすべてがそのホストに送られるとは思わないので、セットアップは理想的とは言えません。

再度、感謝します

表示されている問題は、単一のIPアドレス/ポートで（サーバー名表示を使用せずに）複数の証明書を使用できないことと同じです。

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

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

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

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

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

このトピックに関する基本的な情報だけです。

私が知っているデバイスのうち、このアクションを成功させることができるデバイスはわずかです。しかし、それらは一般の人々には実際には利用できません。私自身は、Fortinet FortigateでSSLオフロードを使用しています。

基本的にそれがすることは; ホストに対して行われたSSL接続をインターセプトし、ハードウェアで接続を解読し、次に行きたい場所を検査し、その情報に基づいてファイアウォールの決定を行います。

その後、そのホストへの独自の接続を設定してデータを取得し、ユーザーが提供したCAを使用して元の要求をクライアントに再署名します。これを円滑に機能させるには、クライアントの信頼されたルートCAにCAが必要です。

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

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

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

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

ブルーノのソリューションに追加するために、私は少し調べて、さらに理想的ではない迅速な修正がどのように得られたかを共有したいと考えました。

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

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

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