TLSの仕組み｜図で追うHTTPSの裏側

アドレスバーの鍵マークの裏で、1往復のやりとりが走っています。

その1往復で、相手が本物か確かめ、盗み見されない鍵を作り、書き換えを検知する準備まで終わります。

言葉で読むと難しいので、1手ずつ動く図にしました。

盗聴者から何が見えて何が見えないかも、同時に出しています。

TLSが同時にやっている3つのこと

TLSは暗号化だけの技術ではありません。

次の3つを同時に満たして、はじめて「安全な通信」になります。

• 盗み見されない（暗号化）：途中の回線を見ても中身が読めない
• 書き換えられない（改ざん検知）：1ビットでも変われば、受け取った側で分かる
• 相手が本物である（認証）：証明書で、そのドメインの持ち主であることを確かめる

3つのうち1つでも欠けると、通信は安全とは言えません。

暗号化だけでは、偽サイトと暗号化通信をしているだけになります。

「SSL」と呼ばれているもの

先に名前の話をしておきます。いま動いている技術は、すべてTLSです。

SSLはその前身で、現在はすべてのバージョンが安全性の問題で使われていません。

それでも「SSL証明書」「SSL化」という呼び名だけが、商習慣として残っています。

仕組みを手紙にたとえると、こうなります。

• HTTP：ハガキ。配達の途中で、誰でも中身を読める
• HTTPS：鍵のかかった箱。鍵を持つ相手しか中身を読めない
• サーバー証明書：宛先に添えられた身分証明書。「この住所はそのお店で間違いない」と第三者が保証する

TLSは、この「鍵のかかった箱」と「身分証明書」を同時に用意する仕組みです。

鍵は「送らずに作る」

TLSの一番おもしろいところは、共通鍵を回線に流さないことです。

ブラウザとサーバーは、それぞれ秘密の値を持ったまま、公開してよい値だけを交換します。

受け取った相手の公開値と自分の秘密を混ぜると、両者だけが同じ答えにたどり着きます。

これが楕円曲線を使ったディフィー・ヘルマン鍵交換（ECDHE）です。

順番を入れ替えても同じ答えになる計算だから成り立ちます。

途中で全部を記録していた人は、公開値を2つ持っていても、そこから同じ答えを計算できません。

さらにこの秘密は接続ごとに作り捨てます。

あとからサーバーの秘密鍵が漏れても、過去の通信はさかのぼって解読できません。

これを前方秘匿性と呼びます。

証明書が証明しているのは「持ち主」だけ

サーバー証明書は、認証局（CA）が「このドメインの持ち主は、この公開鍵を使っている」と署名した書類です。

ブラウザは次の4点を確認します。

• 署名が正しいか（そして証明書の連鎖が、端末が信頼する認証局まで届くか）
• 有効期限の中か
• アクセス先のドメイン名と一致しているか
• 失効させられていないか

ここで確かめているのは「このサーバーがそのドメインの持ち主である」ことだけです。

中の人が善人かどうかも、サイトの内容が正しいかどうかも、証明書は何も言っていません。

偽サイトでも、自分のドメインの証明書なら取れます。

鍵マークが付いていても、それだけでは安心にはなりません。

証明書には3つの種類がある

証明書は、認証局（CA）と呼ばれる発行元から受け取ります。確認の厳しさで3種類に分かれます。

Let's Encryptのように、DV証明書を無料で発行するサービスも普及しています。

自分のブラウザで確かめてみる

いま見ているページがどの証明書を使っているかは、その場で確認できます。

• パソコン：アドレスバー左の鍵マーク（Chromeでは2023年のChrome 117以降、調整アイコンに変わっています）をクリックし、接続の詳細から証明書を開く
• スマートフォン：アドレスバーの鍵アイコンをタップすると、同じ情報が出る
• 発行者（認証局）・有効期限・対象のドメイン名の3つを見れば、図の「確かめている中身」と一致する

有効期限は短くなり続けている

証明書には有効期限があり、その期限は年々短くなっています。

• Let's Encryptの証明書は90日
• 2026年3月15日以降に発行される証明書は、最長200日
• 2027年には100日、2029年には47日まで短縮される予定（CA/Browser Forumの決定）

手で更新し続けるのは現実的ではありません。ACMEなどによる自動更新が前提になります。

TLS 1.3で変わったこと

TLS 1.3は2018年にRFC 8446として標準化されました。

1.2からの変更は、速さと安全の両方に効いています。

再訪時の0-RTTは速い代わりに、同じデータを再送される攻撃（リプレイ）を許す余地があります。

そのため、注文や送金のような「繰り返されると困る操作」には使いません。

なおJavaでTLS 1.3が使えるようになったのはJDK 11からです（JDK 8は8u261以降で対応）。

古いJDKのままだと、接続先が1.3限定になったときに失敗します。

よくある誤解

• 鍵マーク＝安全なサイト：違います。通信路が暗号化されているだけで、相手が善良かは別の話です
• HTTPSなら何を見ているか分からない：ECHを使っていなければ、接続先のドメイン名（SNI）は平文で流れます。通信量やタイミングも残ります
• 証明書を買えば強い暗号になる：暗号の強さは証明書の値段ではなく、選ばれた暗号方式と鍵の長さで決まります

よくある質問

TLSについてよく聞かれることを、6つに絞ってまとめました。用語の違い、見えるもの・見えないもの、証明書の期限、速さ、社内プロキシの話までを扱います。細かい規格の話は省いて、実際に困る場面から書いています。

Q1. TLSとSSLは何が違うのですか？

A1. SSLはTLSの前身で、現在使われているのはすべてTLSです。SSL 3.0までが「SSL」、その後継がTLS 1.0以降にあたります。「SSL証明書」という呼び名だけが商習慣として残っていますが、中身はTLSで使う証明書です。

Q2. HTTPSにすると通信は完全に見えなくなりますか？

A2. 中身は見えなくなりますが、接続先は隠れません。ClientHelloに入るホスト名（SNI）は平文で流れ、DNSの問い合わせ、通信量、タイミングも観測できます。ホスト名を隠すECHは2026年3月にRFC 9849として標準化され、FirefoxはVersion 119以降、ChromeもVersion 117以降で既定で有効です（サーバー側がDNSにECHの設定を公開している場合に使われます）。

Q3. 共通鍵を送っていないのに、なぜ両者が同じ鍵を持てるのですか？

A3. 鍵そのものではなく「鍵のもと」だけを交換しているからです。自分の秘密と相手の公開値を混ぜる計算は、順番を入れ替えても同じ答えになります。この性質のおかげで、盗聴者が公開値を両方見ていても同じ答えには届きません。

Q4. 証明書の有効期限が切れると何が起きますか？

A4. ブラウザが警告を出し、通常は接続できなくなります。暗号化の強さが落ちるわけではなく、「持ち主の確認ができない」と判断されるためです。自動更新（ACME/Let's Encryptなど）を入れておくのが現実的な対策です。

Q5. TLS 1.3にすると何が速くなるのですか？

A5. 接続確立に必要な往復が2回から1回に減ります。距離が遠いサーバーほど往復の待ち時間が効くため、体感の差が出やすくなります。再訪時に0-RTTを使えばさらに短縮できますが、再送の危険があるため用途は選びます。

Q6. 社内のプロキシでHTTPSの中身が見えるのはなぜですか？

A6. 端末に社内用の認証局を信頼させ、プロキシが通信を一度終端して中身を見てから、改めて外へつなぎ直しているためです。端末が信頼する認証局を足せるという前提そのものが、TLSの安全性の土台になっています。

Q7. SSL化（https化）はSEOに有利になりますか？

A7. Googleは検索順位を決める要素の1つとしてhttps化を挙げています。ただし効果は小さく、順位を大きく動かす要因ではありません。それよりも、httpのままだとブラウザに「保護されていない通信」と表示され、読者が離れる影響のほうが大きいです。