HTTPSのWebサイトにアクセスするたびに、ブラウザとサーバーはTLSハンドシェイクを行います。これはサーバーを認証し、暗号化パラメータを合意し、共有秘密鍵を導出する高速なやり取りです。ページコンテンツが読み込まれる前に、1〜2回のネットワークラウンドトリップ（50〜200ms）で完了します。
TLS 1.3ハンドシェイク（現在の標準）
TLS 1.3は1回のラウンドトリップ（1-RTT）でハンドシェイクを完了します：
ステップ1 — Client Hello ブラウザが送信：対応TLSバージョン、対応暗号スイート、乱数、鍵共有パラメータ（Diffie-Hellman鍵交換用）。
ステップ2 — Server Hello + Certificate + Finished サーバーが応答：選択した暗号スイート、証明書（IDの証明）、鍵共有、「Finished」メッセージ。TLS 1.3では証明書が暗号化されているため、受動的な観察者はどのサイトに接続しているか見えません。
ステップ3 — Client Finished ブラウザは信頼するCAリストに対して証明書を検証し、Diffie-Hellman交換から共有セッション鍵を計算し、「Finished」メッセージを送信します。暗号化されたアプリケーションデータが流れ始めます。
合計：1ラウンドトリップ。 再開接続（クライアントが以前接続したことがある場合）は0-RTTを使用できます — 最初のメッセージで暗号化データを送信します。
TLS 1.2ハンドシェイク（まだ広く使用されている）
TLS 1.2は2回のラウンドトリップが必要です：
- Client Hello → 対応バージョン、暗号、乱数
- Server Hello → 選択した暗号、証明書、サーバー鍵交換
- Client Key Exchange → プリマスターシークレット（サーバーの公開鍵で暗号化またはDiffie-Hellman経由）
- Change Cipher Spec + Finished（両側）
TLS 1.2はより多くの暗号スイートをサポートしています — 一部は弱いものを含みます。TLS 1.3よりも適切な設定が重要です。
暗号化された接続内で起こること
ハンドシェイク後、すべてのデータは対称暗号（通常AES-256-GCMまたはChaCha20-Poly1305）を使用してネゴシエートされたセッション鍵で暗号化されます：
- 機密性 — データが暗号化され、2つのエンドポイントのみが読める
- 完全性 — 各メッセージにMAC（メッセージ認証コード）が含まれ、改ざんが検出される
- 認証 — サーバーの証明書がそのIDを証明する（オプションでクライアントのIDも）
すべてのHTTPリクエストとレスポンス — ヘッダー、本文、Cookie、URL — がこの暗号化チャネルを通じて送信されます。
前方秘匿性
最新のTLSは一時的なDiffie-Hellman鍵交換を使用しており、すべての接続が固有のセッション鍵を生成します。サーバーの秘密鍵が後で侵害されても、過去の通信は復号できません。
TLS 1.3は前方秘匿性を必須にしています。TLS 1.2はサポートしていますが、RSA鍵交換も許可しています（前方秘匿性を提供しません）。これがTLS 1.3が推奨される理由です。
証明書の役割
TLSハンドシェイクは、サーバーが有効なSSL/TLS証明書を持っていることに依存しています。証明書は以下を提供します：
- サーバーの公開鍵 — 鍵交換中に使用
- ドメイン名 — ブラウザがURLと一致するか確認
- CA署名 — 信頼された認証局がこの証明書を保証していることの証明
- 有効期限 — ブラウザは期限切れの証明書を拒否
有効な証明書がなければ、ハンドシェイクは失敗し、ブラウザはセキュリティ警告を表示します。無料証明書を取得 →
パフォーマンス
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| フルハンドシェイク | 2ラウンドトリップ | 1ラウンドトリップ |
| セッション再開 | 1ラウンドトリップ | 0-RTT（最初のメッセージでデータ） |
| 追加遅延 | 20-80ms | 10-40ms |
| 暗号ネゴシエーション | 複雑（37暗号スイート） | シンプル（5暗号スイート） |
最新のハードウェアでは、暗号化のCPUコストはごくわずかです — AES-NI命令がハードウェアで処理します。主なコストは追加のラウンドトリップであり、TLS 1.3はこれを最小化します。
ネットワーク上で見えるもの
HTTPSなし（HTTP）
ネットワーク上の観察者はすべてを見ることができます：
GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123
username=admin&password=secret123ユーザー名、パスワード、Cookie、ページコンテンツ — すべて平文です。
HTTPSあり（TLS）
同じ観察者が見えるのは：
[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]宛先IPアドレスとSNIホスト名（TLS 1.2では可視、TLS 1.3ではECHで暗号化）を見ることができます。URLパス、ヘッダー、本文、Cookieは見えません。
証明書の位置づけ
TLSハンドシェイクは、サーバーが有効なSSL/TLS証明書を持っていることに依存しています：
- サーバーの公開鍵 — 鍵交換中に使用
- ドメイン名 — ブラウザがURLと一致するか確認
- CA署名 — 信頼された認証局がこの証明書を保証していることの証明
- 有効期限 — ブラウザは期限切れの証明書を拒否
有効な証明書がなければ、ハンドシェイクは失敗し、ブラウザはセキュリティ警告を表示します。無料証明書を取得 →
2026年の一般的なTLS暗号スイート
TLS 1.3（5つの暗号スイートのみ — すべて安全）
TLS_AES_256_GCM_SHA384 ← 最も一般的
TLS_AES_128_GCM_SHA256 ← 広く使用
TLS_CHACHA20_POLY1305_SHA256 ← モバイル/ARMに最適
TLS_AES_128_CCM_SHA256 ← IoT/組み込み
TLS_AES_128_CCM_8_SHA256 ← IoT/組み込み（短いタグ）TLS 1.2（AEADスイートのみ使用）
ECDHE-ECDSA-AES256-GCM-SHA384 ← ECC証明書で最適
ECDHE-RSA-AES256-GCM-SHA384 ← RSA証明書で最適
ECDHE-ECDSA-CHACHA20-POLY1305 ← モバイル最適化TLS 1.2の非AEADスイート（CBCモード）は避けてください — BEASTやLucky13などの攻撃に対して脆弱です。
よくある質問
HTTPSはWebサイトを遅くしますか？
TLSハンドシェイクは最初の接続で1ラウンドトリップ（TLS 1.3）または2ラウンドトリップ（TLS 1.2）を追加します。セッション再開により、再訪問者にはこれがなくなります。HTTPSがHTTP/2（多重化、ヘッダー圧縮）を有効にするため、HTTPSサイトは全体的にHTTPサイトより高速であることが多いです。
暗号スイートとは何ですか？
暗号スイートは、鍵交換、暗号化、メッセージ認証に使用されるアルゴリズムの組み合わせです。例：TLS_AES_256_GCM_SHA384はAES-256-GCM暗号化とSHA-384メッセージ完全性のTLSを意味します。TLS 1.3は5つの暗号スイートのみ — すべて安全です。TLS 1.2は37あり、一部は弱いです。
後で誰かがHTTPSトラフィックを復号できますか？
前方秘匿性（一時的な鍵交換）があれば、できません。各セッションはDiffie-Hellman交換から導出された固有の鍵を使用します。サーバーの長期秘密鍵が侵害されても、過去のセッション鍵は復元できません。TLS 1.3はこれを強制し、TLS 1.2は正しく設定すればサポートします。
GetHTTPSはこれとどう関係しますか？
GetHTTPSはTLSハンドシェイクを可能にする証明書を生成します。証明書には、鍵交換中にサーバーが使用する公開鍵が含まれています。GetHTTPSはWeb Crypto APIを使用してブラウザ内でこの鍵ペアを作成し、Let’s EncryptのACME APIに直接接続して署名を取得します。GetHTTPSの仕組み →