RFC 8446 TLS 1.3ハンドシェイク詳解

Tech

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

RFC 8446 TLS 1.3ハンドシェイク詳解

背景

Transport Layer Security (TLS) は、インターネット上で安全な通信を提供するためのプロトコルであり、Webブラウジング、電子メール、音声通信など、幅広いアプリケーションで利用されています。TLS 1.2は長らく広く利用されてきましたが、時間の経過とともにパフォーマンスのボトルネック、設定の複雑さ、そして潜在的なセキュリティ脆弱性が指摘されるようになりました。特に、古い暗号アルゴリズムやモードがサポートされ続けることで、ダウングレード攻撃のリスクが存在していました。

こうした課題に対応するため、Internet Engineering Task Force (IETF) はTLSプロトコルの次期メジャーバージョンであるTLS 1.3の標準化を進め、RFC 8446として2018年8月10日 JSTに発行されました [1]。TLS 1.3は、セキュリティの強化とパフォーマンスの向上を主な目標として設計されています。

設計目標

TLS 1.3の設計は、以下の主要な目標に基づいて行われました。

  • ハンドシェイクの高速化: 接続確立にかかる時間（ラウンドトリップタイム、RTT）を短縮し、特にWebパフォーマンスを向上させる。

  • 0-RTTデータのサポート: 以前のセッション情報に基づいて、最初のメッセージでアプリケーションデータを送信できるようにすることで、さらに高速な接続を可能にする。

  • セキュリティの強化:

    • 前向き秘密性（Forward Secrecy）をデフォルトで強制する。

    • 既知の脆弱性を持つ暗号アルゴリズム（MD5, SHA-1, RC4, DESなど）やモード（CBC）を廃止する。

    • プロトコルダウングレード攻撃に対する耐性を向上させる。

    • 主要な暗号スイートをよりシンプルに、かつ堅牢なものに限定する。

  • プロトコルの簡素化: 複雑な設定オプションや冗長な機能を削除し、実装と運用を容易にする。

詳細

TLS 1.3の最も顕著な変更点は、そのハンドシェイクプロセスにあります。

1-RTTハンドシェイク

TLS 1.2では、完全なハンドシェイクには通常2回のラウンドトリップが必要でしたが、TLS 1.3ではこれが1-RTTに短縮されました。これは、クライアントがClientHelloメッセージで鍵交換に必要な情報（KeyShare拡張）を提示し、サーバーが最初の応答で鍵交換を完了できるためです。これにより、サーバー証明書の検証とアプリケーションデータの送信が、より迅速に行えるようになります [2, 3]。

以下に、TLS 1.3の1-RTTフルハンドシェイクの基本的なシーケンスを示します。

sequenceDiagram
    actor Client
    actor Server
    Client ->> Server: ClientHello |KeyShare, SupportedVersions, SupportedGroups, SignatureAlgorithms, ALPN|
    Server ->> Client: ServerHello |SelectedVersion, KeyShare|
    Server ->> Client: ChangeCipherSpec
    Server ->> Client: EncryptedExtensions |ALPN, MaxEarlyDataSize|
    Server ->> Client: Certificate |Server Certificate|
    Server ->> Client: CertificateVerify |Signature over Handshake Context|
    Server ->> Client: Finished |Verify Data|
    Client ->> Server: ChangeCipherSpec
    Client ->> Server: Finished |Verify Data|
    Client ->> Server: Application Data
    Server ->> Client: Application Data

ClientHelloメッセージの構造（主要フィールド抜粋）

struct {
    ProtocolVersion legacy_version:16;    // MUST be 0x0303 for compatibility
    Random random:256;
    opaque legacy_session_id<0..32>;      // Empty in TLS 1.3, for compatibility
    CipherSuite cipher_suites<2..2^16-2>; // List of supported cipher suites
    opaque legacy_compression_methods<1..2^8-1>; // MUST contain 0
    Extension extensions<0..2^16-1>;      // Various extensions including KeyShare, SupportedVersions
} ClientHello;

// KeyShare拡張の内部構造 (一部)
struct {
    NamedGroup group;  // 例: x25519, secp256r1
    opaque key_exchange<1..2^16-1>; // クライアントの公開鍵
} KeyShareEntry;

struct {
    KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;

// SupportedVersions拡張
struct {
    ProtocolVersion versions<2..2^8-2>; // 例: { 0x0304 } for TLS 1.3
} SupportedVersions;

legacy_version はTLS 1.2との互換性のため 0x0303 となり、実際のプロトコルバージョンは extensions フィールド内の SupportedVersions で示されます。

0-RTTハンドシェイク

0-RTT (Zero Round Trip Time) ハンドシェイクは、TLS 1.3の重要なパフォーマンス向上機能です。これは、クライアントが以前に接続したサーバーとの間で確立されたセッション情報を（Pre-Shared Key; PSKとして）利用し、最初のClientHelloメッセージにアプリケーションデータを同梱して送信できるようにするものです [1, 2]。これにより、初回接続時と比較して、待ち時間をさらに削減できます。

以下に、0-RTTハンドシェイクのシーケンスを示します。

sequenceDiagram
    actor Client
    actor Server
    Client ->> Server: ClientHello |KeyShare, PSK Identity, Early Data Indicator| + Early Application Data
    Server ->> Client: ServerHello |SelectedVersion, KeyShare, PSK Identity|
    Server ->> Client: ChangeCipherSpec
    Server ->> Client: EncryptedExtensions |ALPN, MaxEarlyDataSize|
    Server ->> Client: Certificate |Server Certificate|
    Server ->> Client: CertificateVerify |Signature over Handshake Context|
    Server ->> Client: Finished |Verify Data|
    Client ->> Server: ChangeCipherSpec
    Client ->> Server: Finished |Verify Data|
    Client ->> Server: Application Data
    Server ->> Client: Application Data

0-RTTハンドシェイクは、以前のセッションから派生したPSKと、クライアントのKeyShareを用いて鍵を導出します。

キー派生

TLS 1.3では、HKDF (HMAC-based Key Derivation Function) を用いた鍵導出が中心となります。ClientHelloとServerHelloで交換される鍵共有情報 (ECDHE/DHE) から導出される共有秘密（shared_secret）と、オプションでPSKから得られる共有秘密 (psk) を組み合わせて、一連の鍵（ハンドシェイク鍵、アプリケーション鍵など）が段階的に導出されます。これにより、各メッセージは適切な鍵で暗号化・認証され、前向き秘密性が確保されます [1]。

相互運用性

既存プロトコルとの比較

TLS 1.3は、以前のTLSバージョンや他のネットワークプロトコルとの間で顕著な違いと関連性を持っています。

  • TLS 1.2との比較:

    • ハンドシェイクRTT: TLS 1.2は2-RTT、TLS 1.3は1-RTT (フルハンドシェイク) および0-RTTをサポート。

    • 暗号スイート: TLS 1.2は多数の暗号スイートをサポートし、古いものが残存。TLS 1.3は安全なAEAD暗号 (AES-GCM, ChaCha20-Poly1305) と前方秘匿性を持つ鍵交換 (ECDHE/DHE) のみに限定。

    • 前向き秘密性: TLS 1.2はオプションだが、TLS 1.3ではデフォルトで必須。

    • ハンドシェイク構造: TLS 1.2ではClientKeyExchange後にChangeCipherSpecが送信されるが、TLS 1.3ではServerHello直後に暗号化されたハンドシェイクメッセージが続き、ChangeCipherSpecは互換性目的で送信される。

    • セッション再開: TLS 1.2はセッションIDやチケットを使用。TLS 1.3はPSK (Pre-Shared Key) を使用し、0-RTTにも利用される。

    • ダウングレード保護: TLS 1.2には限定的。TLS 1.3は専用のメカニズムを導入。

  • HTTP/2およびHTTP/3 (QUIC) との関連:

    • HTTP/2: HTTP/2はTLS 1.2以降のTLSバージョン上で動作し、ストリーム多重化やヘッダ圧縮によりパフォーマンスを向上させます。TLS 1.3はHTTP/2の基盤となるセキュリティ層をさらに高速化し、全体的なWebパフォーマンスを改善します。

    • HTTP/3 (QUIC): HTTP/3はQUICプロトコル上で動作し、QUICは内部でTLS 1.3をセキュリティプロトコルとして利用しています。QUICはTCPのHOL (Head-of-Line) Blocking問題を解決するためにUDP上でストリーム多重化を実現し、TLS 1.3の0-RTT機能を活用することで、接続確立を非常に高速化します [1]。QUICとTLS 1.3は密接に連携し、次世代のインターネット通信を支えています。

セキュリティ考慮

TLS 1.3はセキュリティを大幅に強化していますが、特定の機能には注意が必要です。

  • リプレイ攻撃 (0-RTT): 0-RTTデータは、リプレイ攻撃の脆弱性を持つ可能性があります。攻撃者が0-RTTデータを傍受し、サーバーに再送信することで、意図しない操作を引き起こす可能性があります。

    • 対策: サーバー側で早期データのリプレイを検出・防止するメカニズム (例: ワンタイムチケット、タイムスタンプ、Nonceの利用) が必須です。また、0-RTTで送信されるアプリケーションデータは、冪等であるべき（複数回実行しても副作用がない）とRFC 8446で強く推奨されています [1]。

  • ダウングレード攻撃の防止: TLS 1.3では、ClientHelloとServerHelloに特定のランダムなバイト値を挿入することで、プロトコルのダウングレード攻撃を検出・防止します。これにより、攻撃者が接続を古い、脆弱なTLSバージョンに強制することを困難にします [1]。

  • 前向き秘密性 (Forward Secrecy): TLS 1.3では、すべてのセッションでDHEまたはECDHE鍵交換が強制されるため、前向き秘密性がデフォルトで確保されます。これにより、将来的にサーバーの長期秘密鍵が漏洩しても、過去の通信内容が解読されることを防ぎます [1]。

  • キー更新 (Key Update): 長時間続くセッションにおいて、定期的に鍵を更新するメカニズムが導入されています。これにより、単一の鍵が長期間使用されることによるセキュリティリスクを低減します [1]。

  • ポストハンドシェイク認証: クライアントやサーバーが、ハンドシェイク完了後に必要に応じて追加の認証（例: サーバー証明書の変更）を行うメカニズムが導入されています。

実装メモ

TLS 1.3の実装には、ネットワークエンジニアとして以下の点に留意する必要があります。

  • MTU/Path MTU: TLSレコードはネットワークのMTU (Maximum Transmission Unit) を考慮してフラグメンテーションされる必要があります。Path MTU Discovery (PMTUD) は、ネットワークパス上の最小MTUを特定し、不必要なIPフラグメンテーションを回避するために重要です。TLS 1.3レコードはPMTUDによって発見された経路MTUに適合するように調整されるべきです。

  • HOL (Head-of-Line) blocking回避: TCPベースのTLS 1.3では、TLSレコード層でのパケットロスが、上位プロトコル（例: HTTP/2の複数のストリーム）にHOL Blockingを引き起こす可能性があります。HTTP/3がQUIC（UDPベース）上でTLS 1.3を利用する主な理由の一つは、このHOL Blockingをプロトコルレベルで回避するためです。実装では、この問題を意識し、適切なバッファリングや再送メカニズムを検討する必要があります。

  • キュー制御と優先度: サーバー側では、受信したTLSレコードの処理キューを適切に管理し、異なる種類のデータ（ハンドシェイクメッセージ、アプリケーションデータ）や異なる接続からのデータに優先度を付けることが重要です。例えば、ハンドシェイクメッセージは接続確立に不可欠であるため、アプリケーションデータよりも優先して処理されるべきです。

  • ライブラリの利用: TLS 1.3の実装は複雑であるため、OpenSSL、BoringSSL、rustlsなどの信頼性の高い既存のTLSライブラリを利用することが強く推奨されます。これらのライブラリは、RFC 8446の仕様に準拠しており、多くのセキュリティベストプラクティスを組み込んでいます。

  • 0-RTTデータの利用方針: 0-RTTはパフォーマンスを大幅に向上させますが、リプレイ攻撃のリスクを伴います。実装者は、0-RTTで送信されるアプリケーションデータが冪等であることを厳密に保証するか、リプレイ検出メカニズムを確実に実装する必要があります。HTTP GETリクエストのように副作用のない操作に適しています。

まとめ

RFC 8446で定義されるTLS 1.3は、現代のインターネット通信のセキュリティとパフォーマンスの要件を満たすために設計された、重要なプロトコルアップデートです。1-RTTハンドシェイクと0-RTTデータによる高速化はユーザーエクスペリエンスを向上させ、強化されたセキュリティ機能はデータ通信の安全性を高めます。特に、前向き秘密性のデフォルト化や旧式暗号の廃止は、プロトコルの堅牢性を飛躍的に向上させました。

TLS 1.3の普及は、HTTP/3とQUICの登場とも相まって、Web全体の高速化とセキュリティ強化に大きく貢献しています。ネットワークエンジニアとしては、その詳細なハンドシェイクフロー、セキュリティ上の考慮事項、そして実装時の注意点を深く理解することが、安全で高性能なシステムを構築する上で不可欠です。

[1] IETF, RFC 8446, “The Transport Layer Security (TLS) Protocol Version 1.3”, 2018年8月10日 JST. https://www.rfc-editor.org/rfc/rfc8446.html [2] Google Developers, “An introduction to TLS 1.3”, 2023年10月27日 JST. https://developers.google.com/speed/docs/insights/tls-1.3 [3] Cloudflare, “A Detailed Look at TLS 1.3”, 2017年9月15日 JST. https://blog.cloudflare.com/introducing-tls-1-3/ [4] Mozilla Security Blog, “What’s new in TLS 1.3”, 2017年8月21日 JST. https://security.mozilla.org/blog/2017/08/21/whats-new-in-tls-1-3/

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

コメント

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