TLS/HTTPS通信の仕組みとハンドシェイク｜暗号スイート・Forward Secrecy・HSTS

WebブラウザとWebサーバ間の通信を暗号化し、盗聴・改ざん・なりすましを防止するインターネット標準プロトコルが「TLS（Transport Layer Security）」です（歴史的にSSLと呼ばれていたプロトコルの後継規格）。

情報セキュリティマネジメント試験（SG）では、HTTPS通信開始時に行われる「TLSハンドシェイク」の手順、暗号スイートの構成要素、過去の通信を守る「Forward Secrecy（前方秘匿性）」、そして常時SSL化を強制する「HSTS」の役割が頻出します。

1. TLSハンドシェイクの基本ステップ（TLS 1.2 / 1.3）

クライアント（ブラウザ）とサーバが暗号化通信を開始する前に、暗号方式の合意、サーバ認証、および共通鍵（セッション鍵）の安全な共有を行う対話処理を「ハンドシェイク」と呼びます。

1. ClientHello：クライアントが対応しているTLSバージョン、利用可能な「暗号スイート一覧」、ランダム値をサーバへ送信する。

2. ServerHello：サーバがクライアントの一覧から採用する「暗号スイート」を1つ選び、自らのランダム値とともに返信する。

3. サーバ証明書の送信：サーバが自らの「ディジタル証明書（公開鍵を含む）」をクライアントへ提示する。

4. 証明書の検証と鍵交換：クライアントはルート証明書をたどってサーバ証明書を検証し、真正性を確認する。続いてディフィー・ヘルマン鍵交換（DHE/ECDHE）等を用いて、両者で共有する「セッション鍵（共通鍵）」を安全に生成する。

5. Finished（完了通知）：以降の通信を合意した共通鍵で暗号化して通信を開始する。

2. 暗号スイート（Cipher Suite）の読み解き方

暗号スイートとは、TLS通信で使用する4つのセキュリティアルゴリズムの組み合わせを指定した文字列です。

3. Forward Secrecy（前方秘匿性）の重要性

【Forward Secrecy（前方秘匿性）とは】

万一、将来サーバの「秘密鍵」が外部へ漏えい・盗難されたとしても、

過去に暗号化されて記録されていた通信パケットを遡って復号できない特性

のこと。 従来のRSA鍵交換では、秘密鍵がバレると過去の全通信が復号されてしまいましたが、ECDHEなどの一時的な使い捨て鍵（エフェメラル鍵）を用いた鍵交換を採用することで、前方秘匿性が保証されます。TLS 1.3では前方秘匿性のないRSA鍵交換は完全に廃止されました。

4. HSTS（HTTP Strict Transport Security）による常時SSL化の強制

WebサイトをHTTPS化しても、利用者がブラウザのアドレスバーに `http://...` と入力したり、メール内の平文リンクをクリックした場合、最初の1回は平文のHTTPで接続されてしまい、中間者攻撃（SSL Strip攻撃等）によって平文通信を傍受されるリスクがあります。

• HSTSの動作：サーバが `Strict-Transport-Security` レスポンスヘッダーを送信すると、ブラウザは以降一定期間、そのドメインへのアクセスを「無条件で内部的にHTTPS（443番）へ自動変換」する。

• 証明書警告時のブロック：HSTS有効時は、証明書エラー画面で利用者が「安全でないサイトへ進む」ボタンを押して無視することがブラウザ側で禁止される。

5. 科目B形式実戦シナリオ演習

演習1：TLS通信におけるサーバの真正性確認手順

〔背景〕G社では社内業務システムをWeb化し、TLS 1.3による暗号化通信を導入した。社員が自宅のPCから業務Webサーバに接続した際、ブラウザに「この接続ではプライバシーが保護されません（証明書が無効）」という警告が表示された。

〔設問〕この警告が表示される原因として、ブラウザがTLSハンドシェイク時に実施した検証処理の結果として最も適切なものはどれか。

• ア：Webサーバが提示した証明書を発行した認証局（CA）が、クライアントPCのルート証明書ストアに信頼されたCAとして存在しなかったか、または証明書の有効期限が切れていた。

• イ：WebサーバのIPアドレスがIPv4ではなくIPv6であった。

• ウ：クライアントPCのメモリが不足し、共通鍵の暗号化計算に失敗した。

• エ：Webサーバのファイアウォールでポート443が遮断されていた。

【解答と解説】

正解：ア

解説：ブラウザはTLSハンドシェイクにおいて、サーバから提示されたディジタル証明書が「信頼されたルート認証局（OSやブラウザが保持する信頼リスト）によって署名されているか」「有効期間内であるか」「アクセス先のホスト名（FQDN）と証明書のコモンネーム（CN/SAN）が一致しているか」を厳格に検証します。この検証に1つでも失敗した場合、なりすましサーバへの接続を防ぐためにブラウザが警告画面を表示します。

演習2：前方秘匿性（Forward Secrecy）を満たす暗号スイートの選定

〔背景〕ネット証券H社では、機密性の極めて高い金融取引データを送受信するため、Webサーバの暗号化設定を見直すことになった。CISOから「将来サーバの秘密鍵が万一流出するような事態が生じても、攻撃者が過去に盗聴・蓄積していた暗号化通信データを復号できない構成にすること」と指示された。

〔設問〕CISOの指示（前方秘匿性の確保）を満たすために採用すべき鍵交換方式として、最も適切なものはどれか。

• ア：固定のサーバ秘密鍵を用いてセッション鍵を直接復号する静的RSA方式

• イ：通信ごとに使い捨ての一時的な鍵ペアを生成して鍵交換を行うECDHE（楕円曲線ディフィー・ヘルマン）方式

• ウ：DESアルゴリズムによる3重暗号化方式

• エ：ハッシュ関数MD5を用いた事前共有鍵方式

【解答と解説】

正解：イ

解説：過去に蓄積された暗号化通信パケットが将来の秘密鍵漏えいによって復号されない特性を「Forward Secrecy（前方秘匿性）」と呼びます。セッションごとに一時的な鍵ペア（エフェメラル鍵）を生成して鍵交換を行う「ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）」やDHEを採用することで、通信終了後に使い捨ての秘密鍵が破棄されるため、後からサーバの証明書秘密鍵を入手しても過去の通信を復号することは計算量的に不可能です。

6. まとめと試験直前チェックリスト

• TLSハンドシェイク：暗号スイートの合意 → サーバ証明書による真正性検証 → セッション鍵（共通鍵）の安全な共有

• 暗号スイートの4要素：鍵交換、認証（署名）、共通鍵暗号、メッセージ認証コード（MAC）

• Forward Secrecy（前方秘匿性）：将来秘密鍵が盗まれても過去の通信が守られる（ECDHEの採用）

• HSTS：ブラウザに対してHTTPS接続を恒久的に強制し、平文HTTP接続による中間者攻撃を遮断

• TLS 1.3：安全性の低いRSA鍵交換を廃止し、1-RTT（1往復）での高速ハンドシェイクを実現