セキュリティ ── TLS ハンドシェイクと PKI

学習目標

本講を終えると、以下の問いに答えられるようになります。

• TLS が 機密性・完全性・サーバ認証 の3つを同時に提供するプロトコルであることを説明できる
• TLS 1.2 のハンドシェイク(ClientHello → ServerHello+証明書 → 鍵交換 → Finished)の流れを順に説明できる
• TLS 1.3 で ハンドシェイクが 1-RTT に短縮された理由と、RSA 鍵交換が廃止された理由を述べられる
• RSA 鍵交換と (EC)DHE 鍵交換の違い、そして 前方秘匿性(PFS) が何を守るかを説明できる
• 共通鍵+公開鍵の ハイブリッド暗号 がなぜ採用されているかを説明できる
• X.509 証明書の主要フィールド(Subject / Issuer / Validity / Public Key / Signature / SAN)を読める
• エンドエンティティ証明書 → 中間 CA → ルート CA の 証明書チェーン と ルートストア の役割を説明できる
• 証明書失効の3方式(CRL / OCSP / OCSP Stapling)を比較できる
• Let's Encrypt の自動発行(ACME)、HSTS、Certificate Transparency が解決した課題を説明できる

このレッスンの目次

TLS は何を守るプロトコルか

TLS の位置づけ ── どの層に挟まるのか

TLS は アプリケーション層とトランスポート層の間 で動きます。アプリ側(ブラウザなど)から見ると、TCP に直接書き込んでいたバイト列が、TLS の層で暗号化・MAC 付与されてから TCP に渡されます。受信側はその逆です。アプリケーション層のプロトコルはほとんど書き換えずに、ポート番号を変える(HTTPS なら 443、SMTPS なら 587)だけで TLS の保護を受けられます。

図の見方:TLS 自体はアプリ層プロトコルではなく、TCP の上に乗る薄いセキュリティ層。アプリは TLS のソケットに書き込むだけで、暗号化・整合性チェック・サーバ認証が透過的に行われる。

考えてみよう: URL が http:// から始まるサイトでパスワードを入力すると、ネットワーク途中の機器が Wireshark のようなパケット解析ツールでそのパスワードをそのまま読めてしまいます。https:// では同じパケットが暗号化された乱数の塊になり、たとえ取られても中身は分かりません。これは TLS の 機密性 が効いている証拠です。

TLS 1.2 のハンドシェイク

順を追って観察する(ステップ実行)

図の見方:ステップ送りで TLS 1.2 のメッセージ往復を観察できる。最終的に両者が同じ マスタ秘密 → 共通鍵 を持つに至り、以後はそれで対称暗号通信を行う。証明書はサーバから一方的に提示され、クライアントはそれを検証して公開鍵を取り出す。

暗号スイートの読み方

TLS 1.2 で使われる「暗号スイート」は、鍵交換 / 署名 / 共通鍵暗号 / ハッシュ関数 の組み合わせを 1 つの ID で表したものです。たとえば TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 は次のように読みます。

TLS 1.2 では何百種類もの暗号スイートが定義されており、サーバとクライアントが「両者ともサポートしている中で最強のもの」を選ぶ仕組みです。

TLS 1.3 でなにが変わったか

TLS 1.2 と TLS 1.3 を並べて比較する

ハンドシェイク往復数

TLS 1.3 ではサーバが ServerHello と一緒に DH 公開値・証明書・Finished までまとめて送る ため、初回でも 1-RTT で暗号通信に入れます。再接続(再開)では 0-RTT(初回パケットに早くもアプリデータを乗せる)も可能です。

つながる知識: 0-RTT は「以前確立した鍵で初回パケットから暗号化する」ため、リプレイ攻撃に弱い面があります。POST のような副作用のあるリクエストには使わないのが原則です。

鍵交換

TLS 1.2 では RSA を鍵交換に使う暗号スイートが残っていましたが、TLS 1.3 では (EC)DHE のみ になりました。理由は 前方秘匿性(PFS) を全接続で強制するためです(次節で詳述)。

• TLS 1.2:RSA / DHE / ECDHE などから選択(RSA は PFS なし)
• TLS 1.3:ECDHE / DHE のみ。RSA 鍵交換は仕様から削除

暗号スイート

TLS 1.3 で実装が必須/推奨される暗号スイートはわずか 5 個。すべて AEAD(認証付き暗号) に統一されています。

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256(モバイル向けに高速)
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

暗号スイート名から「鍵交換」「署名」が消えたのは、それらがハンドシェイクの別パラメータとして独立に交渉されるようになったためです。

廃止された機能

TLS 1.3 では次のような旧アルゴリズム / 機能が 削除 されました。脆弱性が見つかったり、もはや必要ないものを切り捨てた形です。

• RSA 鍵交換(PFS が無いため)
• 静的 DH 鍵交換
• CBC モード対称暗号(POODLE / Lucky13 攻撃の懸念)
• RC4(統計的偏りで解読された)
• MD5 / SHA-1 ベースの署名
• 圧縮機能(CRIME 攻撃に悪用された)
• 再ネゴシエーション(設計簡素化のため)

鍵交換アルゴリズムと前方秘匿性

RSA 鍵交換 と DHE 鍵交換のちがい

図の見方:RSA 鍵交換は「サーバの長期秘密鍵」が共通鍵生成のすべてを握っているため、その鍵が将来漏れた瞬間にすべての過去通信が読めてしまう。DHE は接続ごとに使い捨ての鍵ペアを作るので、長期鍵が漏れても過去通信は守られる。

ハイブリッド構造 ── なぜ公開鍵だけで通信しないのか

公開鍵暗号は「鍵配送問題を解く」点で画期的ですが、実は処理がとても遅い(数百〜数千倍のオーダ)。だから TLS は次のように 役割を分けて 使います。

• 公開鍵暗号 / DH:ハンドシェイク時の 鍵共有(セッションごとに 1 回)
• 共通鍵暗号(AES-GCM など):本データの 大量の暗号化(以後ずっと)
• 署名(RSA / ECDSA):証明書の信頼確認のみ
• ハッシュ関数(SHA-256 / SHA-384):鍵導出と完全性チェック

これを ハイブリッド暗号 と呼びます。「鍵を運ぶ箱は公開鍵で、運んだあとの会話は共通鍵で」と覚えるとよいです。

X.509 公開鍵証明書のフィールド

主要フィールド一覧

重要な拡張フィールド

• Subject Alternative Name(SAN):証明書が有効な FQDN を列挙(例:example.com, www.example.com, *.api.example.com)。現代のブラウザは SAN のみ を見て CN は無視する
• Key Usage / Extended Key Usage:この鍵の用途(署名 / 鍵暗号化、サーバ認証 / クライアント認証)
• Basic Constraints:CA: TRUE なら他の証明書を発行できる中間 CA、CA: FALSE ならエンドエンティティ
• CRL Distribution Points / Authority Information Access:失効情報(CRL / OCSP)の取得先 URL
• SCT(Signed Certificate Timestamp):Certificate Transparency ログへ登録された証拠

図の見方:X.509 証明書は中央の「本体」と末尾の「CA 署名」に大別される。本体には Subject(誰の)・Issuer(誰が発行した)・Validity(いつまで)・公開鍵・拡張(SAN ほか)が並ぶ。CA はこの本体全体のハッシュに対して秘密鍵で署名するので、1 ビットでも改ざんすると署名検証が必ず失敗する。

証明書チェーンと PKI の階層

チェーン検証のアニメーション

図の見方:再生ボタンで「下から上へ署名検証が伝播していく」様子を観察できる。① エンドエンティティ証明書の署名を中間 CA の公開鍵で検証 → ② 中間 CA 証明書の署名をルート CA の公開鍵で検証。ルートはあらかじめ OS / ブラウザに入っているので、そこに到達した時点でチェーン全体が信頼される。

ルートストア ── ブラウザ / OS が「最初から信頼している」リスト

各 OS / ブラウザには ルートストア(信頼アンカー集合) が組み込まれており、その中のルート証明書は 無条件で信頼されます。代表的なものは Mozilla NSS(Firefox / Linux)、Microsoft Trusted Root Program(Windows / Edge)、Apple Root Program(macOS / iOS)、Chrome Root Store などです。それぞれ厳格な監査(WebTrust)を経た CA だけが収録されます。

考えてみよう: なぜルート CA の証明書は「自己署名」(Subject = Issuer)なのに信頼されるのでしょうか。答えは「署名で信頼しているのではなく、ルートストアに入っていることで信頼している」から。ルートストアに入る = OS / ブラウザの監査を通った、という社会的・運用的な信頼が根拠です。

認証局の責任 ── 不正発行が起きると何が壊れるか

CA は「インターネットの公証人」として絶大な権限を持ちます。もし CA が不正な証明書(例:他人のドメインに対する証明書)を発行してしまうと、攻撃者がその証明書を使って 本物そっくりの偽サイト を立ち上げ、ブラウザの鍵マークを偽装できます。実際、2011 年の DigiNotar 事件では大規模な不正発行が起き、その CA はルートストアから追放されました。CA の信頼は「失った瞬間に終わる」のです。

証明書の失効と現代の運用

3つの失効確認方式の比較

Let's Encrypt と無料・自動化された TLS

2010 年代までサーバ証明書は 有償(年額数千〜数万円)で、申請から発行まで人手の認証作業が必要でした。Let's Encrypt(2015 年開始、ISRG が運営)は、これを 無料 + 完全自動 + 短期(90 日) に変革し、HTTPS 普及を爆発的に加速させました。

HSTS:HTTP に落とさせない仕組み

HSTS(HTTP Strict Transport Security、RFC 6797) は、サーバが HTTPS で次のような応答ヘッダを返すと、ブラウザが 以後そのドメインへの HTTP アクセスを自動で HTTPS に書き換える 仕組みです。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

これにより、ユーザが http://bank.example と打ち込んでも HTTPS に強制リダイレクトされ、最初の 1 回目の通信から平文に落ちません。HPKP(HTTP Public Key Pinning) という関連仕様もありましたが、運用ミスでサイトが復旧不能になる事故が多く 廃止 され、現在は Certificate Transparency に役割が移っています。

Certificate Transparency:不正発行を「見える化」する

Certificate Transparency(CT、RFC 6962) は、すべての公的な証明書発行を 公開ログ に記録する仕組みです。Chrome では 2018 年以降、CT ログに登録されていない証明書は警告/エラーになります。

• CA は新しい証明書を発行するたびに、複数の CT ログサーバに登録する
• 登録の証拠(SCT:Signed Certificate Timestamp)が証明書の拡張に含まれる
• 誰でも CT ログを監視でき、自分のドメインに不正な証明書が発行されたら気づける

CT は「CA を信頼する」モデルに 監視と説明責任 を加えるもので、PKI の弱点を補完する重要な仕組みです。

TLS への攻撃と現代の対策

TLS 検査(企業 MITM)の是非

企業ネットワークでは、社内の DLP(情報漏洩防止)/ アンチウイルス装置のために、意図的な MITM を行うことがあります。仕組みは:① 社内端末に 会社専用のルート CA 証明書 を強制インストール、② 出口装置がリアルタイムで偽の証明書を生成して TLS を 復号→検査→再暗号化 する。これにより HTTPS の中身を社内で検査できますが、利用者から見ると会社が すべての通信を読める状態 になります。教育機関 / 医療機関 / 銀行サイトを通すと法的問題が発生しうるため、近年は 除外リスト(検査をバイパスするドメインリスト)を必ず併用する運用が一般的です。

考えてみよう: もしあなたの大学が「すべての TLS 通信を復号して内容をチェックしている」と仮定したら、ブラウザの鍵マークはどう見えるでしょうか。実は 普通の鍵マークのまま(ただし発行元 CA が大学の名前になっている)のが多いです。鍵マークは「途中で読まれていない」ことを保証するわけではなく、「証明書チェーンが あなたの端末のルートストア に到達している」ことを保証するに過ぎない、という限界を理解しておきましょう。

まとめと用語チェック

用語チェック

確認問題