TLS 1.3ハンドシェイクと0-RTTの詳解 (RFC 8446に基づく)

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

TLS 1.3ハンドシェイクと0-RTTの詳解 (RFC 8446に基づく)

背景

Transport Layer Security (TLS) は、インターネット上の通信を暗号化し、データの機密性、完全性、認証性を提供するプロトコルです。TLS 1.2以前のバージョンでは、セキュリティ上の脆弱性や性能上の課題が指摘されていました。これらに対処するため、Internet Engineering Task Force (IETF) によって2018年8月にRFC 8446として「The Transport Layer Security (TLS) Protocol Version 1.3」が発行されました。TLS 1.3は、セキュリティ強化とパフォーマンス向上の両立を目指して設計されています。

設計目標

TLS 1.3の主要な設計目標は以下の通りです。

  • パフォーマンスの向上: ハンドシェイクの往復回数（RTT）を削減し、接続確立にかかる時間を短縮する。特に、0-RTT (Zero Round-Trip Time) 機能により、以前のセッション情報を持つクライアントは、初回接続時にいきなりアプリケーションデータを送信できるようにする。

  • セキュリティの強化: 既知の脆弱性を持つ暗号スイートや機能を廃止し、より堅牢な暗号化アルゴリズムと鍵交換方式のみをサポートする。前方秘匿性 (Forward Secrecy) を強制する。

  • プライバシーの向上: ハンドシェイクの一部（サーバの証明書や拡張情報）を暗号化することで、通信内容が傍受されるリスクを低減する。

  • シンプルさ: プロトコルの複雑性を減らし、実装を容易にし、設定ミスによる脆弱性の発生を防ぐ。

詳細

TLS 1.3 ハンドシェイクのフロー

TLS 1.3のフルハンドシェイクは、TLS 1.2の2-RTTに対し、1-RTTで完了します。これは、クライアントが初期メッセージで必要な鍵交換情報（鍵共有）を提示し、サーバがそれに応答することで実現されます。

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Initial 1-RTT Handshake
    C ->> S: ClientHello |Key Shares (ECDHE), Supported Cipher Suites, Other Extensions|
    S -->> C: ServerHello |Selected Key Share (ECDHE), Selected Cipher Suite, EncryptedExtensions, Certificate, CertificateVerify, Finished|
    Note over C,S: Keys derived. All subsequent messages are encrypted.
    C ->> S: [Application Data], Finished
    S -->> C: [Application Data]
    Note over C,S: Handshake complete. Application data exchanged securely.

図1: TLS 1.3 1-RTT ハンドシェイクのシーケンス

  1. ClientHello: クライアントは、サポートするTLSバージョン、暗号スイートのリスト、鍵共有情報（例: ECDHEの公開鍵）、およびその他の拡張（ALPN、SNIなど）を含むClientHelloメッセージをサーバに送信します。

  2. ServerHello: サーバは、クライアントが提示した鍵共有の中から1つを選択し、それに対応する自身の鍵共有、選択した暗号スイート、およびその他の拡張を含むServerHelloメッセージを応答します。このServerHello以降のメッセージ（EncryptedExtensions、Certificate、CertificateVerify、Finished）は、確立された共有鍵に基づき暗号化されます。

  3. Client Finished: クライアントは、サーバのFinishedメッセージを受信後、自身のFinishedメッセージを送信し、暗号化されたアプリケーションデータをすぐに送信できます。

  4. Server Finished: サーバはクライアントからのFinishedを受信後、アプリケーションデータを送信できます。

0-RTT (Zero Round-Trip Time) の仕組みとフロー

0-RTT機能は、以前に接続したことのあるサーバに対して、クライアントが最初のメッセージ（ClientHello）に続けていきなりアプリケーションデータ（Early Data）を送信できる機能です。これにより、通信開始時のレイテンシを大幅に削減できます。0-RTTは、前回のセッションで発行された事前共有鍵 (Pre-Shared Key; PSK) とそのコンテキスト（セッションチケットなど）を利用して確立されます。

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Previous Handshake (not shown) established PSK and ticket.
    Note over C,S: Subsequent 0-RTT Handshake
    C ->> S: ClientHello |PSK Identity, PSK Binder, Early Data Extension, (Application Data)|
    S -->> C: ServerHello |Selected PSK Identity, Selected Cipher Suite, EncryptedExtensions, Certificate, CertificateVerify, Finished|
    C ->> S: Finished
    S -->> C: [Application Data]
    Note over C,S: Handshake complete. Application data exchanged securely.

図2: TLS 1.3 0-RTT ハンドシェイクのシーケンス

  1. ClientHello with Early Data: クライアントは、以前のセッションで取得したPSK識別子、PSKバインダー（PSKの真正性を証明するためのMAC）、およびearly_data拡張を含んだClientHelloを送信します。同時に、確立されたPSKから導出された鍵で暗号化されたアプリケーションデータ（Early Data）をClientHelloに続けて送信します。

  2. ServerHello: サーバはPSKを検証し、正しければServerHelloに応答します。以降のシーケンスは1-RTTハンドシェイクと同様ですが、すでにアプリケーションデータが一部送信済みである点が異なります。

TLS 1.3 のヘッダ/フレーム/パケット構造

TLSプロトコルは、レコードプロトコル、ハンドシェイクプロトコル、アラートプロトコル、アプリケーションデータプロトコルなどの複数のレイヤーで構成されます。ここでは主要なレコードプロトコルとハンドシェイクプロトコルの構造を示します。

TLSレコードプロトコル (RFC 8446, Section 5.1)

struct {
    TLSPlaintext.ContentType type;
    ProtocolVersion legacy_record_version; // Always 0x0301 (TLS 1.0) for TLS 1.3 client, 0x0303 (TLS 1.2) for TLS 1.3 server
    uint16 length;
    opaque encrypted_record[TLSPlaintext.length];
} TLSCiphertext;

  • type: 1バイト。レコードの内容の種類を示します。TLS 1.3では主にhandshake(22)、application_data(23)、alert(21)が使われます。change_cipher_spec(20)はTLS 1.3では非推奨です。

  • legacy_record_version: 2バイト。TLS 1.3では後方互換性のために利用され、クライアントは0x0301（TLS 1.0）を送信し、サーバは0x0303（TLS 1.2）を送信します。実際のプロトコルバージョンはClientHelloの拡張で合意されます。

  • length: 2バイト。encrypted_recordフィールドの長さをバイト単位で示します。

  • encrypted_record: 可変長。暗号化されたコンテンツです。

ハンドシェイクプロトコルメッセージ (RFC 8446, Section 4)

struct {
    HandshakeType msg_type;
    uint24 length;
    opaque body[length];
} Handshake;

  • msg_type: 1バイト。ハンドシェイクメッセージの種類を示します。例:client_hello(1)、server_hello(2)、new_session_ticket(4)、finished(20)など。

  • length: 3バイト。bodyフィールドの長さをバイト単位で示します。

  • body: 可変長。メッセージの種類に応じた内容が含まれます。

既存プロトコルとの比較

TLS 1.3は、TLS 1.2と比較して、以下のような重要な変更点があります。

  • ハンドシェイクの往復回数 (RTT):

    • TLS 1.2: フルハンドシェイクで2 RTTが必要。セッション再開でも1 RTT。

    • TLS 1.3: フルハンドシェイクで1 RTT。0-RTT再開が可能。

  • 鍵交換方式:

    • TLS 1.2: RSA、DH、ECDHなど、一部で前方秘匿性のない方式も利用可能。

    • TLS 1.3: ECDHE (Ephemeral Diffie-Hellman) またはDHE (Diffie-Hellman Ephemeral) のみ。前方秘匿性 (Forward Secrecy) がデフォルトで保証される。

  • 暗号スイート:

    • TLS 1.2: RC4、MD5、SHA-1、CBCモード、3DESなど、現在では脆弱とされる多くの暗号スイートをサポート。

    • TLS 1.3: AES-GCM、ChaCha20-Poly1305などのAEAD (Authenticated Encryption with Associated Data) 暗号と、ハッシュ関数としてSHA256、SHA384のみをサポート。脆弱なアルゴリズムを廃止。

  • ハンドシェイクの暗号化:

    • TLS 1.2: 多くのハンドシェイクメッセージ（証明書など）が平文で送信される。

    • TLS 1.3: ServerHello以降のほとんどのハンドシェイクメッセージが暗号化される。これにより、ネットワークを傍受する攻撃者からの情報漏洩を防ぎ、プライバシーを向上。

  • プロトコルバージョンネゴシエーション:

    • TLS 1.2: ダウングレード攻撃のリスクがあった。

    • TLS 1.3: ClientHelloにlegacy_versionフィールドを導入し、Randomフィールドに特定の値を埋め込むことで、TLS 1.2へのダウングレード攻撃を防ぐ仕組みが追加された (SCSV – Signaling Cipher Suite Value)。

セキュリティ考慮

TLS 1.3はセキュリティ強化が最優先されましたが、特に0-RTT機能には注意すべき点があります。

  • リプレイ攻撃 (0-RTT):

    • 0-RTTで送信されるEarly Dataは、サーバがクライアントからの要求が新しいものか、あるいは過去のセッションの再送（リプレイ）であるかを区別できない可能性があります。これにより、攻撃者が0-RTTデータを傍受し、サーバに再送することで、意図しない操作を引き起こす可能性があります。

    • 対策: RFC 8446 (2018年8月発行) は、サーバ側での厳格なアンチリプレイメカニズムの実装を義務付けています。これは、使い捨てのセッションチケット (Nonces) や、以前に処理された0-RTTリクエストを追跡するメカニズムによって実現されます。アプリケーション層では、冪等な (idempotent) リクエスト（何度実行しても結果が変わらない操作、例: GETリクエスト）にのみ0-RTTを適用するか、リプレイに対する耐性を持つように設計する必要があります。POSTのような状態を変更するリクエストには、0-RTTの使用を避けるべきです。

  • ダウングレード攻撃:

    • 攻撃者が意図的に古いTLSバージョンへの接続を強制しようとする攻撃です。TLS 1.3は、ClientHello内のrandomフィールドに特定の0x0D0A...バイトパターンを含ませることで、古いTLSバージョンへの意図的なダウングレードを防ぐメカニズムを導入しています (RFC 8446 Section 4.1.3)。

  • キー更新 (Post-Handshake Key Update):

    • TLS 1.3では、ハンドシェイク完了後も、KeyUpdateメッセージを送信することで安全にセッションキーを更新できます。これは、長期間にわたる接続において、単一の鍵が大量のデータを暗号化し続けることによる鍵漏洩のリスクを軽減するために重要です。

  • サイドチャネル攻撃:

    • 実装の不備により、処理時間や消費電力、エラーメッセージの形式などから秘密情報が漏洩する可能性があります。例えば、パディングオラクル攻撃などが考えられます。実装者は、タイミング攻撃やエラーメッセージの内容に注意を払い、可能な限り定数時間操作を心がける必要があります。

実装メモ

TLS 1.3の実装には、性能とセキュリティを最大限に引き出すためにいくつかの注意点があります。

  • MTU (Maximum Transmission Unit) / Path MTU:

    • TLSレコードサイズは、下位レイヤーのMTU、特にPath MTUを考慮して最適化すべきです。UDPベースのQUIC (HTTP/3) と組み合わせる場合、IPフラグメンテーションを避けるためにMTU内に収まるようにTLSレコードを調整することが特に重要です。TCP上でも、大きすぎるレコードはTCPセグメンテーションを引き起こし、効率を低下させる可能性があります。通常、1500バイトのイーサネットMTUを考慮し、IP/TCPヘッダを差し引いた約1400バイト程度を上限として調整されます。

  • HOL (Head-of-Line) blocking 回避:

    • TLS 1.3自体はHOL blockingを直接引き起こしませんが、TLSがTCP上で動作する場合、TCPの特性としてHOL blockingが発生する可能性があります。TLS 1.3の性能メリットを最大限に活かすには、TCP Fast Open (TFO) の利用や、HOL blockingに強いQUIC (HTTP/3) などの新しいトランスポート層プロトコルとの組み合わせが有効です。

  • キュー制御と優先度:

    • サーバ側で多くのTLSセッションを同時に処理する場合、ハンドシェイクメッセージやアプリケーションデータのキューイング、スケジューリングが重要になります。特に、0-RTTデータは通常のアプリケーションデータよりも低優先度で処理されるべきか、あるいは適切なレート制限を設けることで、リプレイ攻撃の影響を最小限に抑えることが推奨されます。

  • 乱数生成と鍵導出:

    • TLS 1.3のセキュリティは、高品質な乱数生成器に強く依存しています。OSが提供する安全な乱数生成器 (/dev/urandom や CryptGenRandom など) を利用し、予測不可能な乱数を確保することが必須です。鍵導出関数 (HKDF) の正しい実装も同様に重要です。

まとめ

TLS 1.3 (RFC 8446) は、インターネットセキュリティのランドマークとなるアップデートであり、その1-RTTハンドシェイクと0-RTT機能はウェブの高速化に大きく貢献しています。同時に、古い脆弱な機能の廃止、前方秘匿性の強制、ハンドシェイクの暗号化によって、セキュリティレベルも飛躍的に向上しました。しかし、0-RTT機能が持つリプレイ攻撃のリスクには十分な理解と、サーバ・アプリケーション層での適切な対策が不可欠です。ネットワークエンジニアとしては、これらのプロトコルの詳細、セキュリティ考慮事項、そして効率的な実装のための注意点を深く理解し、安全で高性能な通信環境の構築に役立てることが重要です。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました