鍵マークは、何を保証しているのか
ブラウザのアドレス欄に出る鍵マーク。 「これがあれば安全」と説明されることが多いのですが、 具体的に何が守られているのかは曖昧なままです。
逆に「HTTP は危険」とも言われます。何がどう危険なのか。 実際に流れるデータを見れば、はっきりします。
前半：HTTP と HTTPS で何が変わるかを、バイト列と経路図で見ます。
後半：暗号化しても隠れないもの、証明書が保証していないものを扱います。
HTTP で流れているもの
ログインフォームに入力して送信ボタンを押すと、 ブラウザはこういうデータをネットワークに送り出します。
POST /login HTTP/1.1 Host: example.jp User-Agent: Mozilla/5.0 (Linux; Android 16) Content-Type: application/x-www-form-urlencoded Content-Length: 38 Cookie: session=a3f9c2e1b8d4 username=tanaka&password=P%40ssw0rd123
224バイト。特別なことは何もしていません。 これがそのままケーブルや電波を通ります。
P%40ssw0rd123 は URL エンコードされているだけで、
暗号ではありません。%40 は @ です。
Cookie の session=a3f9c2e1b8d4 を盗まれれば、
パスワードを知らなくてもログイン状態を乗っ取れます。
これが読めるのは、通信の相手だけではありません。 途中を通るすべての機器が読めます。 カフェの Wi-Fi ルーター、契約している通信事業者、経路上のネットワーク機器。
デモ① 平文と暗号を、並べて見る
入力欄に何か書いて、プロトコルを切り替えてください。 ネットワークに流れるデータがどう変わるか、下に表示されます。
盗聴だけではない — 書き換えられる
平文の問題は「読まれること」だけではありません。 途中で書き換えられます。
| できること | 例 |
|---|---|
| 内容の書き換え | ページに広告やスクリプトを挿入する |
| ファイルの差し替え | ダウンロードするソフトを別物にすり替える |
| 送信先の変更 | フォームの送信先を攻撃者のサーバーに書き換える |
| なりすまし | 本物そっくりの偽ページを返す |
暗号は、改ざんも検知する
現在の TLS で使われる AES-GCM のような方式は、
暗号文と一緒に認証タグという短いデータを付けます。
// 正常な暗号文を復号 復号: 成功 → 元の平文と一致 // 暗号文の10バイト目を 1ビット反転させる 復号: 失敗 → 認証タグが一致しない // 途中で変えられたことが分かる
鍵を持たない者が書き換えると、復号の時点で失敗します。 「読めなくする」だけでなく、「変えられていないことを確かめる」—— 暗号にはこの2つの働きがあります。
デモ② 誰に、どこまで見えるか
通信は、いくつもの機器を経由して届きます。 各地点で何が見えるかを、プロトコル別に示します。
HTTPS でも、隠れないもの
| 項目 | HTTP | HTTPS |
|---|---|---|
| リクエストの中身（フォーム・Cookie） | 見える | 隠れる |
| URL のパス（/login など） | 見える | 隠れる |
| 接続先の IP アドレス | 見える | 見える |
| 接続先のドメイン名（SNI） | 見える | 見える |
| 通信のタイミングと量 | 見える | 見える |
| DNS の問い合わせ | 見える | 設定次第 |
どのサイトを見たかは、隠れません。 ページの中身は読めなくても、「いつ、どこに、どれだけ」は残ります。
なぜ SNI は平文なのか
TLS の通信は、暗号化の前に手続きがあります。
鍵を決めるためのやりとりです。その最初のメッセージが ClientHello。
ClientHello
├ 対応する TLS のバージョン
├ 対応する暗号方式の一覧
├ ランダム値（鍵の生成に使う）
└ 拡張
└ server_name: www.example.jp ← 平文
鶏と卵の問題
1つの IP アドレスで、複数のサイトを運用することがあります。 サーバーはどのサイトの証明書を返すべきかを判断しなければなりません。
証明書を返すには、どのドメインへの接続かを知る必要がある。
しかし暗号化するには、先に証明書を交換しなければならない。
→ ドメイン名を、暗号化の前に伝えるしかない。
これが SNI（Server Name Indication）です。 仕組み上こうなっているので、設定で消せるものではありません。
ECH（Encrypted Client Hello）という仕組みが標準化され、
SNI を含む ClientHello 全体を暗号化する方向へ進んでいます。
ただし対応するブラウザ・サーバー・DNS が揃う必要があり、
現時点では普及の途上です。
AH02032 というエラーを記録します。
エラーコードの記事で扱った項目のひとつです。
古いクライアントか、IPアドレスを直接叩いているか——
SNI の有無は、そういう手がかりにもなります。
証明書は、何を保証しているのか
鍵マークが出ているとき、証明書はひとつのことだけを保証しています。
接続先が、名乗っているドメインの持ち主である——それだけです。 「example.jp に接続したつもりが、別のサーバーだった」を防ぐのが役割です。
| 証明書が保証すること | 保証しないこと |
|---|---|
| 接続先が本物のドメインである | そのサイトが善良である |
| 通信が暗号化されている | 運営者が信頼できる |
| 途中で改ざんされていない | 情報が正しい |
| 相手が秘密鍵を持っている | 個人情報が適切に扱われる |
これは bot の UA が自己申告にすぎないのと 同じ構造です。名乗りを検証する仕組みがあるかどうか。 証明書は身元の証明であって、人格の証明ではありません。
まとめ
この記事のまとめ
- HTTP ではパスワードもCookieも平文で流れる。URLエンコードは暗号ではない。
- 読めるのは相手だけでなく、経路上のすべての機器。
- 問題は盗聴だけでない。書き換えもできる。公開情報しか扱わなくても影響がある。
- AES-GCM などの方式は改ざんを検知する。1ビット変われば復号に失敗する。
- HTTPS でも接続先IP・SNI・通信量は見える。「どのサイトを見たか」は隠れない。
- SNI が平文なのは順序の問題。証明書を選ぶために、暗号化前に必要。
- ECH による解決が進行中だが、普及は途上。
- 証明書が保証するのはドメインの持ち主であることだけ。安全性の保証ではない。
