[4] 素のHTTPを転送するプロキシは、
原理的に要求と応答を好きに傍聴、改竄でき、
かつクライアントはそのことを判断する手段を有しませんから、
HTTPプロキシはその存在自体が MITM です。
[5] HTTPS の場合、クライアントは CONNECT
要求をプロキシに送信してきます。
要求対象と Host:
にサーバーの hostport
が指定されます。
通常プロキシは指定されたサーバーに TCP
で接続し、以後送受信データをそのまま中継することが期待されていますが、
MITM proxy は CONNECT
トンネルの送受信データを処理するサーバーとして振る舞い、
自身がクライアントがあるかのように別の接続で本来のサーバーに接続し、
両接続の送受信データを傍聴、改竄しながら中継します。
[6] 一見 HTTPS の場合でもクライアントは傍聴や改竄を検出できなそうに思えますが、 プロキシはサーバーの証明書に対応する秘密鍵を持っていませんから、 偽の証明書と秘密鍵を使ってクライアントと通信することになります。 偽の証明書のルート証明書はクライアントの証明書データベースに含まれないため、 クライアントは不正の可能性を検知できます。
[8] クライアントの利用者の同意の元正当な目的でやむを得ず使われる MITM proxy の場合、利用者がルート証明書を予め何らかの方法でクライアントの証明書データベースに追加しておく必要があります。
[9]
MITM proxy は、HTTPS サーバーとしてクライアントに返すサーバー証明書を用意する必要があります。
対象となるサーバーが固定されていれば事前に用意することも出来ますが、
不特定多数のサーバーに擬態する可能性があるなら、
動的に生成する必要があります。
証明書の生成や選択には、
TLS の開始時にクライアントから送信されてくるSNIを使うこともできますが、
CONNECT
要求の要求対象や Host:
を使うことも出来ます。
生成や選択にかかる時間を考慮すると、後者に基づき用意するのが良いかもしれません。
[7] Chrome は、ネットワークエラーの画面において、
証明書が MITM proxy のものと判断されるとき、
専用のエラー画面を表示します。
[3] 次のHTTPヘッダーは証明書に関する事項を扱うもので、 MITM proxy と干渉するため、 MITM proxy により削除される可能性があります。
[10] JVNTA#96603741: HTTPS 通信監視機器によるセキュリティ強度低下の問題 () http://jvn.jp/ta/JVNTA96603741/
[12] 1523701 - SEC_ERROR_UNKNOWN_ISSUER since updating to Firefox 65 () https://bugzilla.mozilla.org/show_bug.cgi?id=1523701