HTTPS と TLS ハンドシェイク

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

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

https:// は、通信を TLS (昔は SSL と呼ばれた仕組み) で包む方式です。守っているのは 3 つです。盗み見られない、途中で書き換えられない、そして相手が本物である。この 3 つはそれぞれ別の仕組みで成り立っていて、どれか 1 つが欠けても安全とは言えません。

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

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

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

同時に、包んだ中身には短い検査用の値が付きます。1 バイトでも書き換えられるとこの値が合わなくなります。書き換えたデータは検証に通らず、受け手が接続を切ります。「書き換えられない」はここから来ます。

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

鍵マークは、暗号化とつながった先のドメインしか確かめていない

相手を確かめるために使う公開鍵と秘密鍵は、対になった鍵です。図では「公開鍵で閉めて、秘密鍵で開ける」暗号化の向きを見せていますが、HTTPS で通信本体を包むのは先ほどの接続ごとの鍵で、この対の鍵は主に次の署名の確認に使います。秘密鍵は持ち主だけが保管し、それで作った電子署名を、誰でも受け取れる公開鍵で検証します。データが変わったり、別の秘密鍵で署名したりすると検証は通らないので、対応する秘密鍵で作られた署名かを確かめられます。ここで使うのが証明書です。証明書は「このドメインの持ち主の公開鍵はこれです」と書いた電子的な身分証で、発行する第三者を認証局といいます。たとえば shop.example の証明書には、そのドメインとサーバーの公開鍵の組を認める認証局の署名が付き、ブラウザは認証局の公開鍵で検証します。

発行元が中間認証局なら、その認証局の証明書も上の認証局の公開鍵で検証し、ブラウザが最初から信頼する認証局までたどります。署名の確認に加えて、証明書のドメイン名がアクセス先の shop.example と合うかも確かめます。接続時にはサーバー自身も署名を使って対応する秘密鍵を持つことを示すので、証明書をコピーしただけでは本物のふりはできません。自分で署名した証明書は、その公開鍵で署名を検証できても、最初から信頼する認証局につながらなければ、相手を信用する根拠がないため警告になります。

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

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

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

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

解説

現場の話

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