私の職場では、httpsサイトの場合でも、プロキシを使用してインターネットに接続しています。
これが機能するためには、プロキシはMITMと見なされ、提示される証明書はプロキシからのものであることが私の理解でした。
この証明書のこのルートは信頼されている必要があります。これは、企業環境のグループポリシーで簡単に達成できます。
しかし、これは私が見ているものではありません。
ターゲットWebサイトからの正規の証明書チェーンが表示されていますが、wiresharkはプロキシにアクセスしただけであることを示しています。
何ができますか?
バージョン1.1以降、HTTPは特別なメソッドCONNECTをサポートしています。これにより、コンピュータが直接プロキシに接続するだけでも、プロキシを介してTLSトンネルが設定されます。 HTTPSは、プロキシ経由でもTLSハンドシェイクをトンネルする方法を知っています。
Wikipedia を参照してください:
CONNECTメソッドは、要求の接続を透過的なTCP/IPトンネルに変換し、通常、暗号化されていないHTTPプロキシを介したSSL暗号化通信(HTTPS)を容易にします。
詳細はこちら :
HTTPプロキシサーバーの背後にあるHTTPトンネリングのバリエーションは、 "CONNECT" HTTPメソッドを使用することです。
このメカニズムでは、クライアントはHTTPプロキシサーバーにTCP接続を目的の宛先に転送するように要求します。サーバーはその後、クライアントに代わって接続を確立します。サーバーによって接続が確立された場合、Proxyサーバーは引き続きクライアントとの間でTCPストリームをプロキシします。最初の接続要求のみがHTTPであることに注意してください-その後、サーバーは単にプロキシします確立されたTCP接続。
このメカニズムは、HTTPプロキシの背後にあるクライアントがSSL(つまりHTTPS)を使用してWebサイトにアクセスする方法です。
ただし、次の点に注意してください。
すべてのHTTPプロキシサーバーがこの機能をサポートしているわけではなく、サポートしている場合でも、動作が制限される場合があります(たとえば、デフォルトのHTTPSポート443への接続のみを許可するか、SSLとは思えないトラフィックをブロックします)。
通常、HTTPSがプロキシ経由で行われる場合、これは [〜#〜] connect [〜#〜] メカニズムで行われます。クライアントはプロキシと通信し、双方向のトンネルを提供するように要求しますターゲットシステムとのバイト。その場合、クライアントに表示される証明書は、実際にはサーバーからのものであり、プロキシからのものではありません。その状況では、プロキシはSSL/TLSセッションの外側に保持されます-一部のSSL/TLSが行われていることがわかりますが、暗号化キーにアクセスできません。
一部の組織は、ターゲットサーバーの偽の証明書をオンザフライで生成することにより、完全な中間者を実装します。プロキシがクリアテキストデータを確認してスキャンし、組織のポリシーに準拠するようにスキャンする(自動アンチウイルススキャンなど)ために、これらは正確に行われます。これは、クライアント(ブラウザ)が偽の証明書を正規のものとして受け入れる場合にのみ機能します。これにより、特別な組織制御のルートCAがクライアントマシン(およびWindows/Active Directoryの世界では、GPOはそれを行うことができます)。
ファイアウォール/プロキシアプライアンスのすべての主要ベンダーについて、そのメカニズムをオプションとして提供しています。
次のようないくつかの理由により、すべての組織がこのようなMitMシステムを配備するわけではありません。
自動MitMは高価になる可能性があります。多くのユーザーがいる場合、プロキシアプライアンスは計算能力が高い必要があります。そして、製品ライセンスは高くなることができます。
MitMは証明書ベースのクライアント認証を破壊します。
MitMを実行することは、実際にデータを検査する場合にのみ意味があり、計算コストも増加します。
ルートCAの自動プッシュは [〜#〜] byod [〜#〜] では機能しません。
原則として、ユーザーはそのようなMitMを本当に嫌います。