TLS — 盗聴・改ざん・なりすましを同時に防ぐ
HTTPS の鍵マークが保証しているのは3つ。何を保証していて、何を保証していないのかを分けて理解する。
先に読んでおくとよい記事
この記事の進み方
What — 鍵を交換してから話し始める
TLS が最初にやることは「この2者だけが知る共通の鍵を作る」ことです。しかし経路は盗聴されている前提なので、鍵そのものを送ることはできません。
鍵そのものは一度も経路を流れない。両者が別々の材料を送り合い、それぞれが手元で同じ鍵を計算する。盗聴者は送られた材料を全部見ても、鍵を再現できない。
証明書が保証しているのは「この公開鍵の持ち主は確かにこのドメインの管理者である」という一点だけです。中身が安全かどうか、運営者が善良かどうかは何も保証しません。
- 共通鍵暗号
- 同じ鍵で暗号化と復号を行う。速いが、鍵を相手にどう渡すかという問題がある。実際のデータ転送はこちらを使う。
- 公開鍵暗号
- 公開鍵で暗号化し、対になる秘密鍵でしか復号できない。鍵を渡す問題は解けるが遅い。ハンドシェイクだけに使う。
- 証明書
- 「この公開鍵はこのドメインのものだ」と認証局が署名した書類。有効期限がある。
- 認証局(CA)
- 証明書に署名する第三者。ブラウザや OS が「この CA は信頼する」というリストを最初から持っている。
- ルート証明書
- 信頼の出発点。ブラウザに同梱されている。これを辿れない証明書は信頼できないと判定される。
TLS が防ぐ3つと、防がない3つ
経路上の第三者に対する3つの保証。通信路そのものの安全は、これで完結する。
- 盗聴
- 暗号化により防ぐ
- 改ざん
- 検知して接続を切る
- なりすまし
- 証明書の検証で防ぐ
- サーバー内の脆弱性
- —
- フィッシング
- —
- 接続先の身元以外
- —
- –カフェの Wi-Fi で通信を覗かれても、中身は読めない。
- –経路上で1バイトでも書き換えられると、検知して通信を中断する。
- –偽の example.com を立てても、正規の証明書がなければブラウザが警告を出す。
「HTTPS だから安全」は、3つの脅威に対してだけ正しい。フィッシングサイトも正規の証明書を取得できるので、鍵マークはサイトの善良さを意味しない。
HTTPS の鍵マークが保証していないものはどれですか?
Why — なぜ共通鍵と公開鍵を組み合わせたのか
暗号の方式は大きく2つあり、それぞれに致命的な弱点があります。
共通鍵暗号は速いが、鍵を渡せない。 同じ鍵で暗号化と復号をするので、通信を始める前に相手に鍵を届ける必要があります。しかし経路は盗聴されている前提なので、鍵を送った時点で盗まれます。
公開鍵暗号は鍵を渡せるが、遅い。 公開鍵は誰に見られてもよいので配布の問題が消えます。しかし計算量が共通鍵の数百倍から数千倍かかり、通信の全データに使うのは現実的ではありません。
TLS はこの2つを役割で分けました。最初の鍵合わせだけ公開鍵暗号（の考え方）を使い、実データは共通鍵で流す。 遅い処理を最初の一度きりに閉じ込めるという判断です。
なぜ証明書に有効期限があるのか
暗号化だけなら、証明書は不要です。鍵を交換すれば盗聴は防げます。しかし相手が本物かどうかは分かりません。攻撃者が間に入って自分の鍵を渡せば、暗号化された通信を攻撃者が読める状態が完成します。中間者攻撃です。
証明書はこれを防ぐために、「この公開鍵は example.com のものだ」と第三者に保証させる仕組みです。そして有効期限があるのは、次の理由からです。
- 秘密鍵が漏洩したときの被害を時間で区切る。 失効の仕組み（CRL / OCSP）は存在するものの、確実に行き渡るとは限らない。期限があれば、最悪でもその時点で無効になる。
- 暗号方式の世代交代を強制する。 期限がなければ、20年前の弱い方式の証明書が使われ続ける。
期限は年々短くなっており、以前の2年から現在は最長13か月、さらに短縮が進んでいます。手動更新は前提から外れつつあるということでもあります。
証明書の有効期限切れが、他の障害と違う点はどこですか?
演習 — まず自分で判断する
解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。
この指摘のうち、TLS で解決するものはどれですか?
- 社内の管理画面についてセキュリティ診断を受け、5件の指摘が出た
- ① 社内ネットワーク内の通信が HTTP のままで、認証情報が平文で流れている
- ② 検索フォームの入力値がそのまま HTML に出力されており、スクリプトが実行できる
- ③ 他人の ID を URL に指定すると、その人のデータが見えてしまう
- ④ ログイン画面の URL に酷似したドメインから、偽のログインページが配信されている
- ⑤ データベースのバックアップファイルが、暗号化されずに S3 に置かれている
- · その脅威は「経路の上」で起きているか、それとも経路の外か
- · TLS が保証する3つ（盗聴・改ざん・なりすまし）のどれに当たるか
- · TLS で緩和はできるが解決はできない、という中間があるか
「HTTPS にしたからセキュリティ対策は済んだ」と言う同僚に、足りていない部分を説明してください
- 相手は鍵マークが出ていることを根拠にしている
- 対象は会員登録のあるサービス
- 相手を否定するのではなく、次に何をすべきかを示したい
読み終わりましたか?
読了にすると、これを前提とする記事がロードマップで開放されます。