HTTPSを介して通信する2つの閉じたアプライアンス間に完全に制御された環境(ルーティング、DNS、CA、秘密鍵、証明書)があります。トラフィックは、サーバー名表示と楕円曲線キーを使用して、相互TLS認証チャネルを経由します。
既存のクライアントとサーバーの秘密キーと証明書を使用でき、SNIを実行してサーバーをクライアントに「偽装」し、復号化されたトラフィックをコピー/ダンプしてからリレーできるツール(またはツールセット)が必要ですクライアントからのトラフィックのように、逆もまた同様です。
アプライアンス自体に対して多くのことを行うことはできませんが(EC/DHキーを除外して、後の段階でトラフィックを簡単に復号化できるようにするなど)、すべての証明書と秘密キーを持っているので、トラフィックを必要な場所に手動で送信できます。特定のプロキシトリックは必要ありません。
Openssl s_client/s_server + teeをパイプに接続することで、ある程度の成功を収めましたが、これは1つの接続だけで壊れるようです。
私が試した他のツールは、SNIを処理できないか、証明書を "偽造"することを強く要求しますが、これは本当に必要または望まないものであり(特に、偽の証明書がmy/appの要件を満たしていない場合)、通常は私よりも一般的な目的ですニーズ。
商用グレードのアプライアンスやソフトウェアを探していません。証明書を生成するための可能な解決策は必要ありません。私はそれらと秘密鍵を持っています。
私は何かが必要です。これは、提供されたPK/cert/chainを使用してtcp/443をリッスンし、TLSセッションを確立し、暗号化されていないデータを保存/ダンプしてから、クライアントから受信したコンテンツをサーバーに向けて再生します。 SNIと提供されたクライアントのPK /証明書/チェーンを使用する別のTLSセッションで、可能な限り元のセッションと厳密に一致します。同じTLSセッションだけでなく、複数(並列ではなく直列)の接続で応答データを処理および中継できる必要があります。 2つの有名なボックス間のトラフィックを厳密にキャプチャする必要があります。
ああ、問題ありません。1.7.8以降、Nginxは proxy_ssl_certificate [_key] ディレクティブをサポートし、必要なものを正確に実行します。 ssl_certificate
ディレクティブとssl_certificate_key
ディレクティブにそれぞれサーバー証明書とキーパスを入力してリバースプロキシを設定し、proxy_ssl_certificate
とproxy_ssl_certificate_key
を介して同様の方法でクライアント証明書とキーを追加します。
ssl_client_certificate
ディレクティブを介してクライアント証明書認証を有効にすることを忘れないでください。そのためには、クライアントCA証明書を使用する必要があります。 これが1つの簡単なチュートリアルです 。
SNIは、クライアント側で異なるserver
ディレクティブを指定し、プロキシ側で対応する proxy_ssl_server_name ディレクティブを追加することでサポートされます。
追伸この質問と この質問の複製と考えた質問 の違いは、クライアント証明書をオンザフライで生成したくない(それはNginxとにかくあなたのために行うことはできません)。