TLS/HTTPS通信の仕組みとハンドシェイク|暗号スイート・Forward Secrecy・HSTS
HTTPSの安全な通信では、TLSの認証・鍵確立・通信保護を分け、バージョンの違いを確認します。用語を覚えるだけでなく、事例の条件に合う対策を選べるように整理しましょう。
科目Aで基本的な意味を確認し、科目Bでは「守る情報・起きた事象・組織のルール・担当者の権限」を読み取ります。本文の確認問題は、考え方を練習するためのオリジナル問題です。
1. TLSハンドシェイクの基本ステップ(TLS 1.2 / 1.3)
クライアント(ブラウザ)とサーバが暗号化通信を開始する前に、暗号方式の合意、サーバ認証、および共通鍵(セッション鍵)の安全な共有を行う対話処理を「ハンドシェイク」と呼びます。
ClientHello:クライアントが対応しているTLSバージョン、利用可能な「暗号スイート一覧」、ランダム値をサーバへ送信する。
ServerHello:サーバがクライアントの一覧から採用する「暗号スイート」を1つ選び、自らのランダム値とともに返信する。
サーバ証明書の送信:サーバが自らの「ディジタル証明書(公開鍵を含む)」をクライアントへ提示する。
証明書の検証と鍵交換:クライアントはルート証明書をたどってサーバ証明書を検証し、真正性を確認する。続いてディフィー・ヘルマン鍵交換(DHE/ECDHE)等を用いて、両者で共有する「セッション鍵(共通鍵)」を安全に生成する。
Finished(完了通知):以降の通信を合意した共通鍵で暗号化して通信を開始する。
2. 暗号スイート(Cipher Suite)の読み解き方
暗号スイートとは、TLS通信で使用する4つのセキュリティアルゴリズムの組み合わせを指定した文字列です。
要素 | 役割 | バージョン上の注意 |
|---|---|---|
鍵確立 | 通信で使う鍵を確立する | TLS 1.3では鍵交換等を別に合意し、静的RSA鍵交換を使わない |
認証・署名 | 相手が証明書等に対応する鍵を持つことを確認する | 署名アルゴリズムはTLS 1.3の暗号スイート名に含めない |
AEAD | データの暗号化と完全性保護 | AES-GCM、ChaCha20-Poly1305など |
ハッシュ | 鍵導出等に使う | TLS 1.3の暗号スイートは主にAEADとハッシュを指定する。SHA-256を単純にMACと呼ばない |
3. Forward Secrecy(前方秘匿性)の重要性
前方秘匿性:適切に一時鍵を使って破棄する等の前提で、将来の証明書の秘密鍵漏えいから、記録された過去の通信を保護する性質です。
ECDHE等の一時的な鍵交換で実現します。TLS 1.3は静的RSA鍵交換を使いませんが、RSA署名まで禁止したという意味ではありません。
4. HSTS(HTTP Strict Transport Security)による常時SSL化の強制
WebサイトをHTTPS化しても、利用者がブラウザのアドレスバーに `http://...` と入力したり、メール内の平文リンクをクリックした場合、最初の1回は平文のHTTPで接続されてしまい、中間者攻撃(SSL Strip攻撃等)によって平文通信を傍受されるリスクがあります。
HSTSは、ブラウザが安全なHTTPS経由で受け取った方針を、有効期間中のアクセスに適用する。
通常は最初のHTTPアクセスには方針がまだない。対応するプリロード等とは区別する。
HSTSは証明書の検証エラーを無視する接続を制限する。更新・解除条件があり、恒久的に全攻撃を防ぐ仕組みではない。
5. 科目B形式実戦シナリオ演習
演習1:TLS通信におけるサーバの真正性確認手順
〔背景〕G社では社内業務システムをWeb化し、TLS 1.3による暗号化通信を導入した。社員が自宅のPCから業務Webサーバに接続した際、ブラウザに「この接続ではプライバシーが保護されません(証明書が無効)」という警告が表示された。
〔設問〕この警告が表示される原因として、ブラウザがTLSハンドシェイク時に実施した検証処理の結果として最も適切なものはどれか。
ア:Webサーバが提示した証明書を発行した認証局(CA)が、クライアントPCのルート証明書ストアに信頼されたCAとして存在しなかったか、または証明書の有効期限が切れていた。
イ:WebサーバのIPアドレスがIPv4ではなくIPv6であった。
ウ:クライアントPCのメモリが不足し、共通鍵の暗号化計算に失敗した。
エ:Webサーバのファイアウォールでポート443が遮断されていた。
【解答と解説】
正解:ア
アが正解です。信頼する認証局への連鎖、有効期間、アクセス先のホスト名とSAN等との対応を確認します。署名や鍵の所持も検証します。証明書を検証できたことは、相手のWebページ内容が安全であるという保証とは異なります。
演習2:前方秘匿性(Forward Secrecy)を満たす暗号スイートの選定
〔背景〕ネット証券H社では、機密性の極めて高い金融取引データを送受信するため、Webサーバの暗号化設定を見直すことになった。CISOから「将来サーバの秘密鍵が万一流出するような事態が生じても、攻撃者が過去に盗聴・蓄積していた暗号化通信データを復号できない構成にすること」と指示された。
〔設問〕CISOの指示(前方秘匿性の確保)を満たすために採用すべき鍵交換方式として、最も適切なものはどれか。
ア:固定のサーバ秘密鍵を用いてセッション鍵を直接復号する静的RSA方式
イ:通信ごとに使い捨ての一時的な鍵ペアを生成して鍵交換を行うECDHE(楕円曲線ディフィー・ヘルマン)方式
ウ:DESアルゴリズムによる3重暗号化方式
エ:ハッシュ関数MD5を用いた事前共有鍵方式
【解答と解説】
正解:イ
解説:過去に蓄積された暗号化通信パケットが将来の秘密鍵漏えいによって復号されない特性を「Forward Secrecy(前方秘匿性)」と呼びます。セッションごとに一時的な鍵ペア(エフェメラル鍵)を生成して鍵交換を行う「ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)」やDHEを採用することで、通信終了後に使い捨ての秘密鍵が破棄されるため、後からサーバの証明書秘密鍵を入手しても過去の通信を復号することは計算量的に不可能です。
6. まとめと試験直前チェックリスト
TLSは相手の認証、鍵の確立、暗号化と完全性保護を組み合わせる。
TLS 1.2と1.3で暗号スイートが指定する要素は異なる。
前方秘匿性は、適切な一時鍵の管理等を前提に、証明書の秘密鍵漏えいから過去の通信を保護する性質。
HSTSは有効期間中のHTTPS接続を要求する。初回アクセスやプリロードの条件も確認する。
出典と仕様を確認する
IPA:情報セキュリティマネジメント試験 シラバス Ver.4.1
RFC 8446:TLS 1.3
次におすすめの学習
編集・検証について
編集・検証:IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る