SSL/TLSとは ― SSLとTLSの違いとハンドシェイクの流れ

SSL/TLSは、通信を暗号化するプロトコルです。相手が本物かを確かめ、途中の改ざんも見つけます。SSLは昔の規格の名前で、いま実際に動いているのはTLSです。

「SSL証明書を入れてください」「サイトをSSL化しましょう」と言われたら、中身はほぼTLSの話です。取引先から「TLS 1.0/1.1は廃止するので、1.2以上に対応してください」と連絡が来ることもあります。相手が古いバージョンを止めると、対応していない機器はその日から接続できなくなります。

SSLとTLSの関係から、暗号化が始まる位置やTLS 1.2と1.3の違い、証明書エラーの原因まで順に説明します。

SSLは、Netscape社が作った暗号化のプロトコルです。SSL 3.0をもとに、IETFが標準として定めたものがTLSです。IETFは、インターネットの技術を標準化する団体です。名前が変わっただけではなく、SSLはすでに使用が禁止され、いま使えるのはTLS 1.2と1.3です。

SSLという語は、製品名や設定画面にいまも残っています。「SSL証明書」の実体は、TLSで使うサーバ証明書です。そのため「SSL」と書かれていても、SSL 3.0以前で通信しているとは限りません。

「TLS 1.2以上に対応してください」と言われたら

TLS 1.0と1.1は、2021年のRFC 8996で廃止されました。いまの強い暗号方式を選べないことと、古いハッシュ関数のSHA-1に頼っていることが理由です。

確かめる場所は、接続の両端です。片方が新しくても、共通のバージョンがなければ接続できません。古いOSやライブラリ、長年動かしている機器は、とくに確認が必要です。

サーバがTLS 1.2で接続できるかは、OpenSSLのコマンドで確かめられます。-tls1_2は、TLS 1.2だけを使う指定です。-servernameは、接続先のサイト名を渡す指定です。

$ openssl s_client \
    -connect example.com:443 \
    -servername example.com \
    -tls1_2 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer certificate: CN=example.com
Verification: OK
# 主な行だけを抜き出しています

Protocol versionの行に指定したバージョンが出れば、そのバージョンで通信できています。Verificationの行は、証明書の検証の結果です。

TLSは、通信の途中で起きる3つの被害を防ぎます。HTTPに足りないものをTLSがどう補うかは、HTTPとHTTPSの記事を読むと分かります。

TLS 1.3の暗号は、すべて認証付き暗号（AEAD）です。暗号化と同時に、データの検査用の値を作ります。この値を認証タグと呼びます。受信側は認証タグを確かめ、合わなければ接続を切ります。鍵を使って検査用の値を作る考え方は、メッセージ認証符号の記事で説明しています。

TLSが守るのは、通信の途中だけです。IPアドレスとポート番号は経路上で読めますし、データのおおよその長さも分かります。サーバに保存したデータや、端末の中のデータには別の対策が必要です。

TLSハンドシェイクは、暗号化した通信を始める前の準備です。使う暗号方式を決めること、証明書を確かめること、共通鍵を共有することの3つをします。HTTPSでは、TCPの3ウェイハンドシェイクのあとに始まります。

TLS 1.3の暗号化は、サーバの最初の返事であるServerHelloの次から始まります。最初の1往復で鍵の材料を交換し終えるからです。TLS 1.2では、ハンドシェイクの終わりのFinishedから暗号化が始まります。

鍵の共有に公開鍵暗号の仕組みを使い、本文を共通鍵暗号で送るのは、それぞれの弱点を補うためです。理由はハイブリッド暗号の説明にあります。実際のメッセージを1通ずつ追うと、次のようになります。

TLS 1.3でも、接続先のサイト名は暗号化されないまま（平文で）流れます。1つのIPアドレスで複数のサイトを動かすサーバが、返す証明書を選ぶのに使うからです。ClientHelloを暗号化するEncrypted Client Hello（ECH）は、2026年にRFC 9849になりました。使えるかどうかは、ブラウザとサーバの対応で決まります。

TLS 1.3の鍵交換と署名の確認の順序は、HTTPSの記事の図でも確かめられます。証明書をルートまでたどる手順は、証明書チェーンの説明を読むと分かります。

最初の接続の準備は、TLS 1.2が2往復、TLS 1.3が1往復です。たとえば、往復に50ミリ秒かかる回線で考えます。TCPの1往復を足すと、本文を送り始めるまでが150ミリ秒から100ミリ秒に縮みます。

RSA鍵交換が消えた理由：過去の通信を守るため

TLS 1.2のRSA鍵交換では、共通鍵のもとをサーバの公開鍵で暗号化して送ります。サーバの秘密鍵が後で漏れると、記録されていた過去の通信まで復号されてしまいます。

ECDHEは、接続ごとに使い捨ての鍵の組を作ります。証明書の秘密鍵は署名に使うだけです。そのため、秘密鍵が後で漏れても、過去の通信の共通鍵は計算できません。この性質を前方秘匿性と呼びます。TLS 1.3では、公開鍵暗号を使う鍵交換のすべてがこの性質を持ちます。2026年のRFC 10015は、TLS 1.2でもRSA鍵交換を使わないよう定めました。

0-RTTは再接続を速くするが、再送に弱い

TLS 1.3では、前に接続したサーバが対応していれば、最初の送信に本文を載せられます。この機能を0-RTTと呼びます。ただし、この本文は攻撃者に記録され、別の接続で送り直されることがあります。TLSの仕様は、接続をまたいだ再送を防ぐ保証をしていません。注文のように2回実行されると困る処理には向きません。

TLS 1.2はまだ使えるのか

TLS 1.2は使えます。2022年のRFC 9325は、推奨どおりに設定すれば、すぐにTLS 1.3だけへ移る必要はないとしています。対応している場合はTLS 1.3を優先します。

一方で、TLS 1.2の機能の追加は止まりました。2026年のRFC 9851は、緊急のセキュリティ修正などを除いて変更を認めないと定めています。同じ年のRFC 9852は、TLSを使う新しいプロトコルにTLS 1.3を必須としました。新しく作るシステムは、TLS 1.3を使える構成にしておくと、この先の移行で困りません。

証明書の検証に失敗すると、ブラウザは接続を止めて警告を出します。設定ミスでも、中間者攻撃でも、同じような警告になります。利用者の側からは区別できないので、自分が管理していないサイトでは先へ進まないでください。

Chromeは、警告の画面にエラーの名前を出します。Firefoxなど別のブラウザでは、名前が異なります。

ドメイン名の不一致で多いのは、wwwの有無です。ブラウザは、証明書の subjectAltName という欄に書かれた名前と、開いたドメイン名を比べます。www.example.comだけの証明書でexample.comを開くと、別の名前として不一致になります。

中間CA証明書の不足は、サーバの設定で起きます。サーバは、サーバ証明書と一緒に中間CA証明書も送る必要があります。Chromeには、証明書に書かれた取得先から足りない証明書を取りに行く処理があります。そのため、Chromeでは開けるのに、この処理を持たない別のプログラムでは失敗することがあります。

TLS 1.1以下にしか対応していないサーバをChromeで開くと、証明書の警告ではなく接続エラーになります。表の最後の行の表示です。

TLSは、上で動くプロトコルを選びません。そのため、HTTPのほかにメールやVPN、DNSの通信も暗号化できます。

始め方は2通りあります。1つは、接続した直後からTLSを使う方式です。もう1つは、平文で始めてからSTARTTLSというコマンドで暗号化に切り替える方式です。メールの方式の違いは、メールが届く仕組みの記事にあります。

• RFC 8446（TLS 1.3。ハンドシェイクの流れ、TLS 1.2との違い）
• RFC 9846（RFC 8446を置き換えたTLS 1.3の改訂版。バージョン番号は同じ）
• RFC 8996（TLS 1.0と1.1の廃止）
• RFC 5246（TLS 1.2。文書はRFC 8446と9846に置き換えられたが、TLS 1.2の使用を禁じたものではない）
• RFC 2246（TLS 1.0。SSL 3.0との関係）
• RFC 6101（SSL 3.0の記録）
• RFC 6176・RFC 7568（SSL 2.0とSSL 3.0の禁止）
• RFC 9325（TLSの安全な使い方の推奨）
• RFC 9851・RFC 9852（TLS 1.2の機能追加の停止、新しいプロトコルのTLS 1.3必須化）
• RFC 10015（TLS 1.2のRSA鍵交換などの廃止）
• RFC 6066・RFC 9849（SNIとEncrypted Client Hello）
• RFC 9525（証明書の名前の確認）
• RFC 8314（メールでのTLS）・RFC 7858（DNS over TLS）・RFC 9001（QUICでのTLS）・RFC 9114（HTTP/3）
• Chromium net_error_list.h（Chromeのエラーの意味）
• Chromium cert_verify_proc_builtin.cc（Chromeが中間CA証明書を取りに行く処理）
• OpenSSL openssl-s_client（接続を確かめるコマンド）