はじめに
通信暗号化の基本 SSL / TLS プロトコルについて学習する備忘録です。
改訂履歴
- 2026/08/30 : 初版公開。
本文
1. 概要
SSL (Secure Sockets Layer) / TLS (Transport Layer Security) とは、ネットワーク上で安全にデータをやり取りするためのプロトコルです。最も身近な例では、ブラウザの https:// を使用する HTTPS 通信に利用されています。
SSL / TLS では主に以下の機能を提供します。
- 通信内容を暗号化する。
- 通信内容が改ざんされていないことを検出する。
- 通信相手が正しい相手であることを確認する。
2026 年現在、実際の通信では主に TLS 1.2 および TLS 1.3 が広く利用されています。SSL は TLS の前身にあたり、安全上の理由から現在では廃止された古いプロトコルです。
補足
今でも「SSL 証明書」や「SSL 通信」という呼び方が一般的に使われていますが、Web 通信などで実際に利用されているのは主に TLS の方です。SSL という名称そのものが TLS を含む通信暗号化技術の総称として慣用的に使われています。
1-1. 年表
| Ver | 概要 |
|---|---|
| SSL 1.0 | 開発段階で脆弱性が発見されたため、正式に公開されることはなかった。 |
| SSL 2.0 | 1994 年発表。ダウングレード攻撃やバージョンロールバック攻撃の脆弱性があり、現在は廃止されている。 |
| SSL 3.0 | 1995 年発表。長らく利用されたが 2014 年に POODLE という脆弱性が発見され、安全ではないことが明らかになった。現在は廃止されている。 |
| TLS 1.0 | 1999 年発表。SSL 3.0 をベースに IETF によって標準化された最初の TLS。BEAST などの脆弱性もあり、現在は廃止されている。 |
| TLS 1.1 | 2006 年発表。TLS 1.0 の問題を改善したバージョン。CBC モードの暗号化に関する改善などが行われたが、TLS 1.2 と比較すると利用可能な暗号方式や機能が限定されている。現在は廃止されている。 |
| TLS 1.2 | 2008 年発表。AEAD 暗号を利用できるようになり、暗号スイートの柔軟性も向上した。現在も広く利用されている。 |
| TLS 1.3 | 2018 年発表。現在利用されている最新世代の TLS。TLS 1.2 以前と比較してハンドシェイクや暗号スイートの仕様が大きく変更され、より安全かつ効率的になっている。 |
2. レイヤー
TLS は HTTP などのアプリケーションプロトコルと TCP などのトランスポートプロトコルの中間に位置して通信を保護します。TCP 上で TLS を利用する場合、各プロトコルの関係は次のようになります。
| 層 | プロトコル | 役割 |
|---|---|---|
| アプリケーション層 | HTTP | Web データ。 |
| (中間) | TLS | 通信の暗号化と認証。 |
| トランスポート層 | TCP | データの確実な転送。 |
| ネットワーク層 | IP | パケットの配送。 |
3. 通信シーケンス
TLS では、通信を開始する際にハンドシェイクを行います。ハンドシェイクでは、使用する TLS のバージョンや暗号方式などを決定し、サーバー証明書などを利用して通信相手を認証します。また暗号化通信に使用する鍵を確立します。ハンドシェイクが完了すると TLS で保護された通信を開始します。
以下では HTTPS を題材に TLS 1.2 と TLS 1.3 のハンドシェイクについて、代表的な通信シーケンスを整理します。
3-1. TLS 1.2
ECDHE を利用した代表的な TLS 1.2 のハンドシェイクです。暗号スイートや設定によって、実際のメッセージ構成は異なります。
Certificate では、サーバーが証明書をクライアントに提示します。クライアントは証明書の有効性や信頼チェーン、接続先のホスト名などを検証します。ServerKeyExchange と ClientKeyExchange では、鍵交換に必要な情報を交換します。上記では ECDHE を想定しています。
3-2. TLS 1.3
TLS 1.3 では TLS 1.2 と比較してハンドシェイクが簡略化されています。また ServerHello より後の、多くのハンドシェイクメッセージは暗号化されます。
TLS 1.3 では ClientHello に鍵交換用の情報を含めて送信します。サーバーも ServerHello で鍵交換に必要な情報を返すため、両者で共有鍵を確立できます。Certificate ではサーバー証明書を提示し、CertificateVerify では、その証明書に対応する秘密鍵をサーバーが所有していることを署名によって証明します。
4. SNI
SNI (Server Name Indication) とは、RFC6066 で定義されている SSL / TLS の拡張仕様の一つで、TLS 接続時にクライアントが「どのホスト名のサーバーに接続しようとしているか」をサーバーへ伝えるための仕組みです。
1 つの IP アドレスで複数のドメインをホスティングする際に使用されます。例えば、同じ IP アドレスで example.com と example.net の HTTPS サービスを提供している場合、クライアントは ClientHello で接続先のホスト名を SNI として通知します。
以下は SNI の通信イメージになります。
補足
1つの IP アドレスで複数のドメインを運用すること自体は TLS 固有の機能ではありません。例えば HTTP では HTTP リクエストに含まれる Host ヘッダーを利用して、同じ IP アドレス上の複数のドメインを区別できます。一方 HTTPS では TLS のハンドシェイクが HTTP より先に行われます。そのため、HTTP の Host ヘッダーを確認する前に、接続先のドメインに対応する証明書を選択する必要があります。そこで ClientHello に SNI を含め、接続先のドメインをサーバーに伝えます。
4-1. ESNI と ECH
SNI は TLS 接続時に接続先のホスト名をサーバーへ伝えるための仕組みですが、通常の SNI は ClientHello に平文で含まれます。そのため、TLS 1.3 を利用していても、ネットワーク上の第三者から接続先のホスト名を観測される可能性があります。この問題に対する方式として、まず ESNI (Encrypted Server Name Indication) が検討され、その後、より一般化された ECH (Encrypted Client Hello) が標準化されました。
ESNI は SNI を暗号化して送信するための仕組みです。ただし ESNI は最終的な標準仕様として採用された方式ではありません。SNI の暗号化について検討が進められる中で、SNI だけでなく ClientHello に含まれるその他の情報も保護する必要性が認識され、後継となる ECH の仕様へ発展しました。ECH では ClientHello に含まれる SNI 以外の情報も保護することで、より包括的なプライバシー保護を実現しています。
4-2. ドメインフロンティング
ドメインフロンティングとは、ネットワークの検閲やフィルタリングを回避するために利用されてきた技術です。具体的には SNI に回避用のドメイン、HTTP host ヘッダーには実際にアクセスしたいドメインを指定することで、TLS の検閲をすり抜けます。
この技術は通信の自由を確保する手段として利用されてきた一方、悪意のある目的で利用されることもあります。そのため 2026 年現在では、多くの大手クラウドサービス事業者において、SNI と HTTP Host ヘッダーの不一致を利用したドメインフロンティングが制限・禁止されています。
5. 脆弱性と脅威
これまでに発見された SSL / TLS の脆弱性と脅威をまとめます。
5-1. ダウングレード攻撃
通信相手に古いバージョンや脆弱な暗号方式を使用させることで、安全性の低い状態に持ち込む攻撃です。古いプロトコルの脆弱性を悪用される可能性があります。
5-2. バージョンロールバック攻撃
バージョン交渉を攻撃者が妨害し、より古いバージョンを選択させる攻撃です。ダウングレード攻撃の一種として扱われることがあります。
5-3. BEAST 攻撃
BEAST (Browser Exploit Against SSL / TLS) 攻撃は SSL 3.0 / TLS 1.0 で使用されていた CBC モードの脆弱性を悪用し、暗号化された通信内容を推測する攻撃です。TLS 1.1 では改善されています。
5-4. POODLE
POODLE (Padding Oracle On Downgraded Legacy Encryption) は SSL 3.0 の CBC モードに存在する脆弱性を悪用し、暗号化された通信内容を推測する攻撃です。SSL 3.0 の使用を無効化することで対策できます。
5-5. Heartbleed 攻撃
OpenSSL の Heartbeat 拡張に存在した脆弱性を悪用し、攻撃者がサーバーのメモリ上にある情報を不正に読み取る攻撃です。秘密鍵や認証情報などの機密情報が漏洩する可能性があり、2014 年に大きな問題となりました。
6. 参考
おわりに
気付きがあれば、追記します。