PacketProxyがTLS通信をMITMできる仕組み
PacketProxyがSSL/TLS通信をMITM（閲覧・改ざん・再送）する仕組みについて解説します。
PacketProxyは、下図のようにクライアント-サーバ間のTLS通信を傍受し、暗号データを解読しているわけではありません。
ちなみにWiresharkはこの手法を利用しています（ただし、解読をしているわけではなく、ユーザが暗号鍵を設定することで復号しています）。
PacketProxyは、下図のようにクライアント側とサーバ側で異なる2つのTLS通信を実行することでMITMしています。
ただし、このままMITMしようとすると、クライアント側のTLS通信はTLSエラーで失敗します。
理由はクライアントはTLS通信のハンドシェイク時に、通信相手が確かにサーバであること（真正）をチェックするからです。
クライアント側のTLS通信を成功させるには、実際の通信相手がPacketProxyにも関わらず、クライアントを騙して、サーバと通信しているように見せかける必要があります。
クライアントを騙すには、クライアントによるサーバの真正チェックの仕組みを知る必要があります。
クライアントは、通信相手から送られてきたサーバ証明書をチェックすることにより、通信相手が確かに通信したい相手であることを確認します。
クライアントによる、特に重要なチェック項目は、下記の2つです。
- サーバ証明書に記載されたサーバ名のチェック
- サーバ証明書に記載されたサーバ名リストに、接続しようとしているサーバ名が含まれていることをチェックします。
- サーバ証明書を署名したCA証明書のチェック
- サーバ証明書が信頼されたCA証明書で署名されていることをチェックします。
- クライアントは、トラストストアという信頼されたCA証明書データベースをあらかじめ持っており、サーバ証明書がトラストトアのいずれかのCA証明書によって署名されているかどうかをチェックします。
- サーバ証明書が信頼されたCA証明書で署名されていることをチェックします。
例として、Chromeブラウザで https://example.com/ へMITMをせずに通常アクセスした場合のサーバ証明書と署名に利用されているCA証明書を見てみます。
上図の赤矢印の通り、サーバ証明書の証明書のサブジェクトの代替名（SAN: Subject Alternative Name）に、サーバ名としてexample.comが含まれていることが分かります。
また、上図の青矢印の通り、サーバ証明書の署名についてはDegiCert Global Root CAによってDegiCert TLS RSA SHA256 2020 CA1が署名され、さらにDegiCert TLS RSA SHA256 2020 CA1によってwww.example.org(サーバ証明書)が署名されていることが分かります。
ちなみにDegiCert Global Root CAは、下図のようにOSのトラストストアに登録されているCA証明書です。つまり、信頼されたCA証明書から署名されたサーバ証明書ということになります。
それではPacketProxyでMITMした状態で、Chromeブラウザから https://example.com/ へアクセスしてみます。
すると、PacketProxyから、PacketProxyのCA証明書によって署名され、サーバ名としてexample.comを含むサーバ証明書が送られてきました。
あらかじめPacketProxyのCA証明書をOSのトラストストアに追加しておくことで、PacketProxyがChromeの通信をMITMできるようになることが分かると思います。
各OSのトラストストアにPacketProxyのCA証明書を登録する方法についてはPacketProxyのCA証明書の各OSへのインストール方法を確認してください。