導入 — HTTPS は何を守っているか
盗聴・改ざん・なりすましの 3 つの脅威と、それに答える機密性・完全性・真正性の対応関係をつかみ、鍵マークの守備範囲を線引きする。
「鍵マークが付いていれば安全」…と言い切れるか
証明書の警告が出たとき、無視して進んでよいか判断できない。お客様に「HTTPS だから安全です」と説明した直後に、「何がどう安全なんですか」と聞かれて言葉に詰まる。— HTTPS は毎日使っているのに、内側の仕組みは意外と説明しづらいものです。
出発点は、HTTPS ではない通信、つまり平文の HTTP で何が起きるかを正しく想像することです。ブラウザとサーバの間には、同じ Wi-Fi にいる他人、ルータ、プロバイダ、途中のネットワーク機器など、たくさんの「中継者」がいます。平文の HTTP では、この経路上のどこからでも通信の中身がそのまま読めて、しかも書き換えられます。
TLS（Transport Layer Security）は、この 3 つの脅威にそれぞれ別の道具で答える仕組みの組み合わせです。1 つの魔法で全部を解決しているのではない、という見方が、この講座の出発点です。
3 つの脅威と 3 つの保証はきれいに 1 対 1 で対応します。以降の章では、それぞれの保証を実現する道具（暗号・ハッシュ・証明書）を 1 つずつ開けていきます。
3 つの脅威に、3 つの保証
| 脅威 | 保証 | 実現する道具 | 扱う章 |
|---|---|---|---|
| 盗聴 | 機密性 — 読まれない | 鍵合意 + 共通鍵暗号 | 第 2〜3 章 |
| 改ざん | 完全性 — 変えられたら分かる | ハッシュ + 認証付き暗号 | 第 2 章・第 5 章 |
| なりすまし | 真正性 — 相手が本物 | 証明書 + デジタル署名 | 第 2 章・第 4 章 |
大事なのは、この 3 つが独立に成り立ったり欠けたりすることです。たとえば暗号化だけして相手の確認をしなければ、「偽物と秘密の会話をする」ことになります（第 4 章で実際にこの穴を突く攻撃を見ます）。逆に、相手は本物でも暗号化がなければ盗聴されます。3 つの問い — 相手は本物か・内容は秘密か・途中で変わっていないか — を毎回すべて確認する、というのがこの講座の型です。
小問 1-1 — 脅威と保証を対応づける
3 つの脅威と 3 つの保証の対応関係を、具体的な場面で確認します。
Q1. カフェの公衆 Wi-Fi で、HTTP（HTTPS ではない）のサイトのログインフォームにパスワードを入力しました。まず心配すべき脅威はどれですか。
HTTP は平文で流れるため、同じ Wi-Fi にいる第三者や経路上の機器からパケットの中身がそのまま読めます。パスワード強度やブラウザ更新も大切ですが、それらは「平文が経路上で読める」というこの場面の主役の脅威には答えません。
Q2. 3 つの保証のうち、「受け取った内容が途中で書き換えられていないこと」に対応するものはどれですか。
完全性（integrity）は「内容が途中で変わっていないこと」の保証です。機密性は「読まれないこと」、真正性は「相手が本物であること」。この 3 つを混ぜずに言い分けられることが、この講座全体の土台になります。
HTTPS は「HTTP over TLS」— 層で考える
HTTPS は HTTP を置き換えた別物ではありません。ブラウザとサーバの会話（HTTP）はそのままに、その下に TLS という層が 1 枚入った構造です。
層が分かれているおかげで、TLS は HTTP 専用ではなく、メール（SMTPS）や独自の API 通信にもそのまま使えます。逆に言うと、TLS が守るのは「輸送中」だけです。サーバに届いた後のデータの扱いや、サイト運営者が善良かどうかは、TLS の守備範囲の外にあります。
この講座の合言葉: 鍵マークや証明書エラーを見たら問いかけてください — いま欠けているのは、相手の確認か？ 秘密か？ 改ざん検知か？
小問 1-2 — 鍵マークの守備範囲
鍵マークが「何を保証し、何を保証しないか」を線引きします。ここを誤解したまま実務の説明をすると事故になります。
Q3. ブラウザのアドレスバーに鍵マークが表示されているとき、正しく言えるものはどれですか。
鍵マークが示すのは「通信経路が暗号化されていて、相手がそのドメインの証明書を持っている」ことまでです。運営者の善良さやサーバ内部での管理は守備範囲外で、フィッシングサイトも自分のドメインの証明書を取得して鍵マークを表示できます。
Q4. HTTPS で通信しているとき、経路上の第三者にそれでも見えてしまう情報はどれですか。
TLS が暗号化するのは通信の中身です。どの IP アドレスと通信しているか、接続先のドメイン名（ClientHello の SNI。第 5 章で扱います）、パケットのタイミングや量といったメタデータは経路上から観測できます。「HTTPS = 何も分からない」ではない、という線引きも大切です。
Q5. HTTPS の構造の説明として正しいものはどれですか。
HTTPS は「HTTP over TLS」— HTTP そのものは変わらず、TCP との間に TLS の層が入り、HTTP メッセージ全体（ヘッダも本文も）が暗号化されて運ばれます。層が分かれているからこそ、TLS は HTTP 以外（メールや API など）にもそのまま使えます。
この章で持ち帰ること
- 脅威は盗聴・改ざん・なりすましの 3 つ。それぞれ機密性・完全性・真正性の保証が対応する
- 鍵マークが示すのは「そのドメインの持ち主と暗号化された経路で話している」ことまで。運営者の善良さは保証しない
- HTTPS は HTTP over TLS。TLS が守るのは輸送中だけで、接続先ドメイン名などのメタデータは経路上からも見える
次章では、3 つの保証を実現する道具 — 共通鍵・公開鍵・ハッシュ・署名 — を「何を解決する道具か」という視点で 1 つずつ開けていきます。