TLSは、利用者の端末とサーバの両端だけで中身を読めるように暗号化する仕組みです。だから途中の装置は中身を見られません。ところが実務では、間に立つ装置が通信を一度ほどいて中身を見ることがあります。これがTLSの傍受（復号）で、正規の可視化（社内プロキシ）も中間者攻撃（MITM）も、まったく同じ仕組みで起きます。違いは目的と、端末にどの証明書を信頼させたかだけです。
TLSは接続のはじめに、サーバがサーバ証明書を提示します。端末は「その証明書が自分の信頼する認証局（CA）に署名されているか」を確かめて、正しければ鍵を交換し、以後の通信を暗号化します。信頼の起点は端末が持つCAの一覧――ここが傍受のすべての鍵になります。
正規のTLSは「端から端まで1本」
暗号鍵は端末とサーバの2者だけが持ちます。途中の装置は暗号文を運ぶだけで、中身は読めません。これがTLSの前提です。
動きで見る
検査プロキシがTLSを2本に割って中身を復号・検査し、問題なければ再暗号化して転送する流れが追えます。（図は横スクロールできます）
傍受は「トンネルを2本に割る」
＝ここで一度ほどける
間の装置は、端末に対してはサーバのふりをして自分の証明書を出し、サーバに対しては利用者のふりをして接続します。トンネルが端末↔装置と装置↔サーバの2本に割れるので、装置の内側では中身が平文で見えます。社内プロキシによる可視化も、攻撃者のMITMも、この形は同じです。
成否を分けるのは「証明書を信頼させられるか」
端末は接続のたびに証明書を検証します。だから間の装置が出す証明書を端末が信頼していなければ、警告が出て止まる。傍受が成立するのは装置のCAを端末に信頼させたときだけです。正規の可視化は、会社が管理端末に自社のCAをあらかじめ配布して成立させます。攻撃は、偽CAを何らかの手で端末に入れる／証明書警告を利用者に無視させる、といった信頼の差し込みが要る――ここが攻防の分かれ目です。
「暗号化されているから安全」ではありません。TLSが守るのは途中で読まれないこと。守れないのはそもそも誰と鍵を交換したかです。信頼する証明書の管理が甘い端末は、暗号化されていても中身を覗かれ得ます。要は暗号の強さではなく証明書の検証が急所。
攻撃側の傍受を無力化する方向
だから対策は「もっと強く暗号化する」ではなく、差し込まれた偽の証明書を受け入れない方向になります。
証明書を厳密に検証する
- 発行元（CA）・宛先ドメイン・有効期限を確認
- 警告を利用者任せにしない（自動で拒否）
証明書ピンニング
- アプリが特定の正しい証明書だけを受け付ける
- 偽CAを信頼させても、ピンに一致しなければ拒否
※スマホアプリの診断では、まず端末に検査用CAを入れて傍受し中身を見る。ピンニングされたアプリはこれを拒むので、傍受できるか否か自体が「守りの強さ」の指標になる。