TLS代行受信プロキシは、ユーザーのブラウザにエンドサーバーの証明書を提示しますか？
TLS（一般的には誤ってSSLと呼ばれます）の傍受は、クライアントとサーバー間に2つの暗号化されたトンネルを確立し、傍受デバイス（プロキシ）が両方のトンネルを途中で終端することで機能することを知っています。ただし、傍受が発生していることを難読化するには、プロキシの証明書を信頼できるものとして受け入れるようにクライアントのマシンを構成する必要があるため、ユーザーはIDを確立できないことを示すポップアップメッセージを受信しません。これは、クライアントマシンがユーザーのルートディレクトリの証明書を静かにプッシュできるドメインに参加している企業環境では簡単に実行できます。
これで、TLSを介してWebサイトにアクセスすると、ブラウザーでそのサイトの証明書を表示できます。途中に代行受信プロキシがある場合、チェックすると、ブラウザのサイトの証明書が変更されますか？言い換えると、プロキシはクライアントへのTLSトンネルを確立する目的でサーバーの証明書を複製することはできませんが（サーバーにはないサーバーの秘密鍵が必要なため）、サーバーの証明書を視覚的に出力できますユーザーにとって、証明書を見ただけで傍受が発生していることに気付かないようにするには？したがって、たとえば、すべてのTLS接続を傍受する企業環境にいて、組織のプロキシ証明書がすべてのクライアントにインストールされているとします。 TLS経由で銀行口座に接続する場合はポップアップは表示されませんが、銀行のサイトでは、自宅から接続する場合と同じフィンガープリントが証明書に表示されます。このディスカッションの目的）を安全かつ直接接続していますか？
別の言い方をすると、安全なサイトの証明書をチェックして中間者を検出できるか、または企業のラップトップ上のすべての信頼できる証明書を調べて、異常なもの（つまり、企業のもの）がないかどうかを判断する必要がありますか？
クライアントに送信される証明書は、元のサーバーではなく、プロキシによって生成されたものです。エンドサーバーが使用しているキーに固有の証明書であるため、エンドサーバーの証明書を送信できません。クライアントに送信されるキーを変更し、証明書を変更しなかった場合、公開キーの計算されたハッシュが証明書のハッシュと一致しないため、検証が失敗し、無効になります。
ブラウザまたはTLSクライアントは、デフォルトでインストールされているかどうかにかかわらず、インターセプトプロキシが使用しているCAへの信頼パスを表示する必要があります（実際に十分な規模の企業の場合、これらの種類のMITMセットアップ用に実際に販売されている中間証明書があります）。ポリシー/管理を通じて組織によって。
sneakで述べたように、クライアントは元のサイト証明書ではなく、プロキシによって生成された証明書を受け取ります。その理由は、プロキシは証明書のみでサイトを偽装できないため、対応する秘密鍵が必要です。
証明書はTLSの不可欠な部分です* 設定します（つまり、「サイトシール」または同様のナンセンスではありません）。その内容（公開鍵）は、クライアントが接続の詳細を暗号化するために使用されます。一致するサーバー鍵のみがこれを復号化して、接続を正常に完了できます。プロキシが提示できるのは、キーのある類似した証明書のみです。これは、（非常に高い確率で）異なるフィンガープリントまたはハッシュを持ちます。
[* TLSのネゴシエーションには多くのオプションがあり、2つの主な機能authenticationとencryption「null」オプションがありますが、これらは通常HTTPSでは見られません。 null認証方法を使用する場合、証明書は必要ありません。 ADH]
このようなTLSインターセプトの一般的な方法は、プロキシが宛先のDNS名と一致するキーと証明書を（オンザフライで、その後キャッシュして）生成し、証明書は擬似CAによって署名され、 OS /ブラウザによって「信頼される」プロキシ。
信頼は次のように機能します（少し単純にするため）。
- サーバーは公開鍵を含む証明書を提示します。クライアントはサーバーの公開鍵を使用して対称鍵を暗号化するため、サーバーがクライアントからのメッセージを復号化できない場合、TLS設定は失敗します
- クライアントはサーバー証明書の詳細（DNS名、日付範囲、オプションで失効）を検証します
- クライアントは、既知の（ローカルコピー）トラストアンカーまでの信頼の連鎖を検証します（通常は自己署名ルートCA）
プロキシが成功する理由は、通常、デスクトップポリシー、カスタマイズされたブラウザの展開などにより、ブラウザが企業の疑似CAを「信頼」しているためです。信頼モデルの問題は明らかです。通常、すべてのCAは任意の名前の証明書に署名できます（通常、下位のCAを介しても委任できます）。
正当な証明書とプロキシ生成の証明書の間で変更される最小のフィールドは、exponentおよびsignature。ただし、実際には、生成された証明書は表面的には実際の証明書（日付とDNS名のテストに合格するのに十分なもの）に似ているだけで、会社のプロキシの疑似CAによって直接署名されます。ただし、正当な外観のCA階層を複製して、証明書チェーンの他のすべての詳細（指数と署名を除く）を複製することは完全に可能です。証明書の詳細が変更されると、計算された fingerprint （ダイジェスト）も変更されます。
要約すると、プロキシによって生成された証明書：
- 表面的には実際の証明書に類似している必要があり、DNS部分（CNおよび/またはsubjectAltNames）が一致する必要があります
- 「発行者」フィールドが提供するはずなので、おそらくすぐに明白になります
- 他の多くのフィールドが共通している可能性がありますが（シリアル番号、SKID、日付）、おそらくないでしょう（シリアル番号はCAごとに再利用してはならないため、特別な処理が必要です）。
- 失効（CRL、OCSP）の詳細は、おそらく破壊されるか、証明書から削除されます
意志するべきです商用CAによって署名されていません（過去にTrustwaveが この疑わしい慣行 に従事している）、同じではありません署名データ。同じフィンガープリントはありません
確認すると、ブラウザのサイトの証明書が変更されますか？
はい、おそらくIssuerフィールドまたは計算されたフィンガープリントを検査するだけで済みますが、entireチェーンを検証して確認する必要があります。
それでも、サーバーの証明書をユーザーに視覚的に出力するだけで、ユーザーが気づかないように、証明書を見ても傍受が行われていることに気付くことができますか？
いいえ。HTTPSサーバー（実際のWebサーバー、またはプロキシ）はこれを制御できません（ユーザーインターフェイスの問題、不正な拡張機能、偽のロケーションバーは別として）。ブラウザに表示されるのは、TLS接続のセットアップ中に使用された証明書であり、HTTP経由でフェッチされたファイルではありません。
中間者を検出するのに十分な安全なサイトの証明書をチェックしていますか、または企業のラップトップ上のすべての信頼できる証明書を調べて、それらのいずれかが異常かどうかを判断する必要がありますか？ "
それはおそらく証明書のみから明らかであり、生成された証明書はプロキシの疑似CA証明書によって直接署名される可能性が高く、これはおそらく証明書のテキストフィールド（少なくとも「発行元」）によって簡単に識別できます。完全にするために、すべての証明書のフィンガープリントを比較する必要があります。
FWIW、EV証明書を使用すると、tiny保護を少し強化できます：有能なブラウザーにはハードウェアが搭載されているため、プロキシは真のEV証明書を偽造できませんEV対応のCA証明書のコード化されたリスト。 （ただし、鶏と卵の問題は解決しません：EV証明書をいつ必要とするか、または必要とするかをどのようにして知るのですか？）
IETFのDANE は、より堅牢なソリューションとして提案されています。 信頼モデルの根本的な問題 に対処します。
TLSが依存しているパブリックCAモデルは、これらのCAのいずれかが任意のドメイン名の証明書を発行できるため、根本的に脆弱です。
DANEは実際に問題を解決するために、少し先にそれを蹴るのではなく、DNSSECを必要とします。また、クライアント証明書という簡単な対策も1つありますが、これはさまざまな理由で一般的な解決策ではありません。
その他の（部分的な）ソリューションは次のとおりです。
Convergence 、 Verikey [PDF]、 CertPatrol （Firefoxプラグイン）、 Monkeysphere （multi-プロトコル）
以下も参照してください。
使用される鍵交換に応じて、RSA鍵交換では、クライアントは基本的にセッション鍵を選択し（それよりも少し複雑ですが、この説明とは関係ありません）、サーバーの公開鍵で（証明書から）暗号化します。プロキシにはその証明書に対応する秘密鍵がないため、クライアントが選択した鍵を復号化できず、接続で通信できなくなります。
DH鍵交換では、最初の交換を完了することができますが、クライアントはプロキシにチャレンジして、証明書に関連付けられた秘密鍵があることを確認して応答し、プロキシはこのチャレンジへの応答を提供できません。
代わりに、プロキシはその場で証明書の詳細を複製し、そのサイトで使用する新しい証明書を作成する必要があります。このように、対応する秘密鍵を持ち、目的のサーバーへの独自の接続を形成できます。プロキシはサービスを提供するシステム上でルート信頼を持っているため、証明書は有効として受け入れられますが、システムがプロキシのオンとオフの両方で使用されている場合、証明書のピン留めにより、公開キーの変更によりエラーが検出される場合があります。
HTTPSまたはSSLプロキシは安全ではありません。常に代替SSL証明書を使用してユーザーのブラウザに表示されます。つまり、Webサーバーとの実際のHTTPS接続がなく、ログインページとプライベートデータがプロキシサーバーで開かれています。プロキシとダイレクトモードで https://google.com 証明書を確認するだけで、さまざまな検証が見つかります。