HTTPS と TLS ハンドシェイク

カフェの Wi-Fi で、ログインボタンを押す前に一瞬ためらう

同じ電波を使っている誰かに、入力したパスワードが読まれないでしょうか。http:// で始まるページなら、読まれます。中身をそのままの文字で流しているので、経路の途中にいる人はそれを拾えます。

https:// が守っているのは 3 つです。盗み見られない、途中で書き換えられない、そして相手が本物である。この 3 つはそれぞれ別の仕組みで成り立っていて、どれか 1 つが欠けても安全とは言えません。

守っているのはパスワードだけではありません。暗号化されていない経路では、途中の誰かが返ってきたページに広告や別のスクリプトを差し込むこともできます。読まれる心配が無いページだから平文でよい、とはならないのはこのためです。

盗み見と書き換えは、同じ 1 つの箱で防ぐ

やりとりを始める前に、ブラウザとサーバーは 2 人だけが知っている鍵を作ります。以降の通信はその鍵で包まれるので、途中で拾っても意味のない数値の列にしか見えません。これが「盗み見られない」です。

同時に、包んだ中身には短い検査用の値が付きます。1 バイトでも書き換えられるとこの値が合わなくなり、受け取った側はその場で通信を捨てます。攻撃者は中身を読めないので、意味の通る改ざんもできません。「書き換えられない」はここから来ます。

鍵をどうやって 2 人だけで共有するのかは数学の話になるので、ここでは踏み込みません。押さえておくのは、鍵が接続のたびに作り直されることです。通信を丸ごと録音しておいて後から鍵を手に入れても、それだけでは読めません。

鍵マークは「暗号化されている」としか言っていない

残る 1 つ、「相手が本物か」を担うのがサーバー証明書です。証明書にはドメイン名と公開鍵と発行元が書かれていて、発行元である認証局の署名が付いています。

ブラウザは信頼している認証局の一覧を最初から持っていて、届いた証明書がその一覧のどれかまで署名の連鎖でたどり着けるかを確かめます。たどり着けなければ警告を出して先に進ませません。

ここで注意が要ります。証明書が保証しているのは「そのドメインの持ち主が用意したサーバーにつながっている」ことだけです。ドメイン自体が偽サイトなら、鍵マークは普通に付きます。無料で証明書を取れるようになった今、偽サイト側もこれを用意しています。鍵マークは、URL を読まなくてよい理由にはなりません。

3 つが別々に成り立っていることは、自分で証明書を作って試すとよく分かります。認証局を通さずに自分で署名した証明書でも、暗号化と改ざん検知はそのまま働きます。それでもブラウザが警告を出すのは、3 つ目の「相手が本物か」だけが確かめられないからです。開発中はこの警告を押し通して進めますが、そこで確認を省いているのが何なのかは、意識しておく価値があります。

解説

現場の話

証明書には有効期限があります。切れると、全ユーザーが警告画面で止まります。しかも昨日まで動いていたので、原因にたどり着くまでが遅れがちです。取得は自動化されていることがほとんどですが、その更新の仕組み自体が止まっていないかを、切れる前に一度は確かめておく価値があります。