総合演習 — ケースで仕上げる
実務の場面を模した 8 つのケースで、全 6 章の知識を横断して使う。つまずいた問題は対応する章へ戻って復習する。
仕上げの 8 問 — ケースに 3 つの問いを当てる
最終章は解説なしの総合演習です。実務で出会う場面を模した 8 つのケースに、全 6 章の知識を横断して答えます。迷ったら、この講座の合言葉に立ち返ってください — いま欠けているのは、相手の確認か？ 秘密か？ 改ざん検知か？
| つまずいたら | 戻る章 |
|---|---|
| 鍵マークの守備範囲・3 つの保証 | 第 1 章 |
| 4 つの道具の使い分け・鍵の向き | 第 2 章 |
| mod の手計算・前方秘匿性 | 第 3 章 |
| 証明書チェーン・3 チェック・秘密鍵の扱い | 第 4 章 |
| ハンドシェイクの流れ・SNI・0-RTT | 第 5 章 |
| openssl の読み方・エラーの切り分け | 第 6 章 |
ケース 7-1 — 何が守られていて、何が守られていないか
第 1〜3 章の範囲です。「3 つの問い」に立ち返って考えてください。
Q1. ケース: 利用者から「鍵マークの付いたサイトだったのに、偽サイトでカード番号を入力してしまった」と相談されました。正しい説明はどれですか。
第 1 章の線引きです。攻撃者も『自分の』ドメイン（例: examp1e-support.com）の証明書は正規に取得でき、鍵マークを表示できます。鍵マークが本物でも、そのドメイン自体が偽物なら守られません。「アドレスバーのドメイン名を確認する」ことが利用者側の防御の要である理由がここにあります。
Q2. ケース: 講座の復習として、p = 23, g = 5 の Diffie–Hellman で秘密の値 a = 4 を選びました。相手に送る公開値 A = 54 mod 23 はいくつですか。
5² = 25 ≡ 2、5⁴ = (5²)² ≡ 2² = 4。答えは 4 です（625 = 23 × 27 + 4 と直接割っても同じです)。第 3 章の型 — 2 乗を繰り返してそのつど mod を取る — が身についていれば 10 秒の計算です。
Q3. ケース: 攻撃者があるサーバの HTTPS 通信を 1 年分すべて記録していました。その後、サーバの長期秘密鍵（証明書に対応する鍵）が漏えいしました。TLS 1.3 で行われていた過去の通信はどうなりますか。
前方秘匿性（第 3 章）のケースそのものです。TLS 1.3 の長期秘密鍵の役割は署名（なりすまし防止）であって、セッション鍵の材料ではありません。漏えいした鍵で今後なりすましをされる恐れには失効・再発行で対処が必要ですが、記録済みの過去の暗号文は守られたままです。
ケース 7-2 — エラーと攻撃を切り分ける
第 4〜6 章の範囲です。「3 チェックのどれが失敗したか」への翻訳を使ってください。
Q4. ケース: 検証環境で意図的に中間者攻撃を再現したところ、攻撃者の機器は自己署名の証明書を提示しました。ブラウザの挙動として正しいものはどれですか。
自己署名証明書は「自分で自分に署名した」証明書で、ルートストアのどの CA にも繋がりません。3 チェックのうち署名チェーンの検証が失敗し、警告が出ます。これこそが第 4 章の設計の成果です — 中間者攻撃は『暗号化を破る』のではなく『証明書検証で発覚する』形で防がれます。警告を『無視して進む』ことの意味も、この構図から説明できます。
Q5. ケース: RTT が 80 ミリ秒の回線で、TLS 1.2（ハンドシェイクに 2 往復）から TLS 1.3（1 往復）へ移行しました。TCP 接続確立後、暗号化データを送り始められるまでの時間は何ミリ秒短くなりますか。
2 往復 × 80 = 160 ミリ秒が 1 往復 × 80 = 80 ミリ秒になるので、差は 80 ミリ秒です。接続のたびに発生する短縮なので、接続数の多いモバイルアプリや API では体感に効きます。セッション再開（PSK）や 0-RTT を使えばさらに縮みますが、0-RTT にはリプレイの注意が付くのでした（第 5 章）。
Q6. ケース: 新しい API クライアントを本番サーバに向けたところ、証明書検証エラーになりました。同じ URL はブラウザでは問題なく開けます。openssl s_client でサーバの応答を見たとき、確認すべき仮説として最も有力なのはどれですか。
「ブラウザは通るが、それ以外は落ちる」は中間証明書の設定漏れの典型です（第 6 章）。期限切れならブラウザでも落ちます。s_client の Certificate chain に leaf 1 枚しか出てこなければ確定で、対処はサーバに中間証明書を設定することです。クライアント側で検証を切る（-k 相当）のは対処ではありません。
ケース 7-3 — 運用の判断
最後は運用者としての判断です。「何が秘密で、何が公開か」の構造から答えが導けます。
Q7. ケース: サーバの構成ミスで、TLS の秘密鍵ファイルが一時的に外部から取得できる状態になっていたと判明しました。適切な対応はどれですか。
秘密鍵を握った攻撃者は、そのドメインへのなりすまし（CertificateVerify の署名の偽造）が可能になります。有効期限を待つのは、その間なりすましを許すことと同じです。失効（第 4 章）+ 新しい鍵ペアでの再発行が正解で、「証明書は公開・秘密鍵は厳守」という第 4 章の線引きが判断の根拠になります。
Q8. ケース: 社内システムの証明書が期限切れになり、利用者から「エラー画面に『詳細設定から進む』ボタンすら出ない」と報告がありました。原因として正しいものはどれですか。
HSTS（第 6 章）を宣言したサイトでは、ブラウザは HTTPS を強制し、証明書エラーの『無視して進む』を提供しません。故障ではなく、サイト自身が指定した安全装置が働いています。正しい復旧は証明書の更新であって、利用者にエラー回避の手順を探させることではありません。期限監視（残り日数のアラート）を仕込む動機もここにあります。
講座の終わりに — 3 つの問いを持ち歩く
お疲れさまでした。この講座で覚えるべき暗号アルゴリズムの詳細は、実はほとんどありませんでした。代わりに持ち帰ってほしいのは、どんな場面でも通用する 3 つの問いです。
- 相手は本物か — 証明書チェーンはルートストアまで繋がるか。名前は一致するか。秘密鍵の所持は証明されたか
- 内容は秘密か — 鍵合意はされたか。前方秘匿性はあるか。SNI のようにそれでも見えるものは何か
- 途中で変わっていないか — AEAD による改ざん検知。Finished によるハンドシェイク全体の照合
証明書エラーの画面でも、セキュリティ設計のレビューでも、この 3 つを順に確認すれば、原因と対処は自ずと絞り込めます。エラーを黙らせるのではなく、どの問いが「いいえ」になっているかを探す — それがこの講座で身につけた読み方です。