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

Tech

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

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

背景

TLS (Transport Layer Security) は、インターネット上で安全な通信を確立するためのプロトコルであり、特にウェブ通信 (HTTPS) において不可欠です。TLS 1.2以前のバージョンには、パフォーマンスのボトルネック、プロトコルの複雑性、そして既知の暗号学的脆弱性といった課題が指摘されていました。具体的には、ハンドシェイクの際に複数の往復 (Round Trip Time; RTT) が必要となるため、接続確立に時間がかかり、初期通信の遅延を招いていました。また、多くのレガシーな暗号スイートや機能が残存しており、設定ミスによる脆弱性の露呈リスクがありました。

こうした課題を解決するため、IETF (Internet Engineering Task Force) は新しいバージョンのTLS、すなわちTLS 1.3 (RFC 8446) の標準化を進め、2018年8月に公開しました。TLS 1.3は、セキュリティ強化とパフォーマンス向上の両立を目指して設計されています。

設計目標

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

  • パフォーマンスの向上: ハンドシェイクのRTTを削減し、特に「0-RTT (Zero Round Trip Time) 」接続の導入により、以前のセッション情報を持つクライアントは、接続確立と同時にアプリケーションデータを送信できるようにする。

  • セキュリティの強化:

    • 前方秘匿性 (Perfect Forward Secrecy; PFS) の強制: すべての鍵交換にDiffie-Hellman (DH) または楕円曲線Diffie-Hellman (ECDH) を使用し、短期的なセッション鍵が長期鍵の漏洩から保護されるようにする。

    • 脆弱な暗号機能の削除: MD5、SHA-1、RC4、DES、3DES、AES-CBCモードなど、既知の脆弱性を持つ暗号スイートやハッシュ関数、鍵交換方式をプロトコルから完全に削除。

    • プロトコルの簡素化: ハンドシェイクメッセージの数を減らし、オプション機能を最小限に抑えることで、実装を容易にし、攻撃ベクトルを減少させる。

  • プロトコル構造の明確化: ハンドシェイクのほとんどのメッセージを早期に暗号化することで、パッシブな盗聴者による情報収集を防ぐ。

詳細

TLS 1.3のハンドシェイクは、主に「1-RTTハンドシェイク」と「0-RTTハンドシェイク」の2つのモードで動作します。

1-RTTハンドシェイク (初回接続)

標準的なTLS 1.3のハンドシェイクは、初回接続時にクライアントとサーバー間で1回の往復で暗号化された通信を確立します。

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: ClientHello (Supported Versions, Key Share, Cipher Suites, ALPN)
    Server ->> Client: ServerHello (Selected Version, Key Share, Selected Cipher Suite, Selected ALPN)
    Server ->> Client: EncryptedExtensions (Supported Application-Layer Protocols, etc.)
    Server ->> Client: Certificate (Server's public key certificate)
    Server ->> Client: CertificateVerify (Digital signature over handshake messages)
    Server ->> Client: Finished (Handshake message authentication code)
    Client ->> Server: Finished (Handshake message authentication code)
    Client ->> Server: [Application Data]
    Server ->> Client: [Application Data]

  1. ClientHello: クライアントは、サポートするTLSバージョン (TLS 1.3)、鍵共有アルゴリズム (例: X25519、P-256)、利用可能な暗号スイート、Application-Layer Protocol Negotiation (ALPN) リストなどを含むClientHelloメッセージを送信します。ここで鍵共有の初回部分 (Client’s Key Share) も含める点がTLS 1.2からの大きな変更点です。

  2. ServerHello: サーバーは、クライアントが提示したオプションの中から選択を行い、選択されたTLSバージョン、鍵共有アルゴリズム、暗号スイートなどをServerHelloで返します。同時に、サーバー自身の鍵共有部分 (Server’s Key Share) も含めます。

  3. EncryptedExtensions: サーバーは、追加の拡張情報 (ALPNで選択されたアプリケーションプロトコルなど) をEncryptedExtensionsとして送信します。これはServerHello以降の最初の暗号化されたメッセージです。

  4. Certificate & CertificateVerify: サーバーは、自身の公開鍵証明書をCertificateで提示し、その証明書と過去のハンドシェイクメッセージに対するデジタル署名をCertificateVerifyで送信して自身の所有権を証明します。

  5. Finished (Server): サーバーは、ハンドシェイクの完全性と認証を検証するためのMAC (Message Authentication Code) を含むFinishedメッセージを送信します。

  6. Finished (Client): クライアントも同様にFinishedメッセージを送信します。

  7. Application Data: これでセキュアな通信路が確立され、クライアントとサーバーはアプリケーションデータの交換を開始できます。

0-RTTハンドシェイク (再接続)

0-RTTハンドシェイクは、クライアントが過去にサーバーとの間で確立したセッション情報 (PSK: Pre-Shared Key) を利用して、最初のRTTなしにアプリケーションデータを送信することを可能にします。これにより、実質的な接続確立時間が大幅に短縮されます。

sequenceDiagram
    participant Client
    participant Server

    note over Client,Server: Prior session and PSK establishment needed
    Client ->> Server: ClientHello (PSK Identity, EarlyData indicated) + EarlyData (Application Data)
    alt Server accepts EarlyData
        Server ->> Client: ServerHello (Selected PSK, EarlyData accepted)
        Server ->> Client: EncryptedExtensions
        Server ->> Client: Certificate (Optional)
        Server ->> Client: CertificateVerify (Optional)
        Server ->> Client: Finished
        Client ->> Server: Finished
        Client ->> Server: [Application Data]
    else Server rejects EarlyData
        Server ->> Client: ServerHello (No PSK selected, or EarlyData rejected)
        Server ->> Client: EncryptedExtensions
        Server ->> Client: Certificate
        Server ->> Client: CertificateVerify
        Server ->> Client: Finished
        Client ->> Server: Finished
        Client ->> Server: [Application Data]
    end

  1. 事前準備: 0-RTTを使用するには、以前のセッションでサーバーがクライアントにNewSessionTicketメッセージを送信し、クライアントがこれを保存している必要があります。このチケットには、将来のセッション再開に利用されるPSKやその他のパラメータが含まれます。

  2. ClientHello + EarlyData: クライアントは、保存しているPSK識別子 (PSK Identity) を含むClientHelloを送信し、同時に暗号化されたアプリケーションデータ (EarlyData) を送信します。

  3. ServerHello: サーバーはPSKを検証し、EarlyDataを受け入れるか否かを決定します。

    • 受け入れた場合: ServerHelloでPSK選択を通知し、続く通常の1-RTTハンドシェイク (ただし鍵交換はPSKベース) に移行します。

    • 拒否した場合: ServerHelloでPSKを使用しないことを通知し、通常の1-RTTハンドシェイク (DH/ECDH鍵交換) にフォールバックします。この場合、クライアントはEarlyDataを再送する必要があります。

鍵導出プロセス

TLS 1.3では、HKDF (HMAC-based Key Derivation Function) を用いてセッション鍵を導出します。ClientHelloとServerHelloで交換されるDH/ECDH鍵共有の値 (shared secret) を基に、複数の鍵 (handshake traffic secret, application traffic secret) が段階的に導出されます。これにより、各メッセージの暗号化に使用される鍵は特定の段階でのみ有効となり、前方秘匿性を強化します。

Record Layer構造

TLS 1.3では、メッセージの多重化や効率化のためにRecord Layerが簡素化されています。

TLSPlaintext:
  type:8              # ContentType (handshake, application_data, etc.)
  legacy_record_version:16 # Always 0x0301 (TLS 1.0/1.1/1.2) for compatibility
  length:16           # Length of the fragment (max 2^14 bytes)
  fragment:length     # The actual data

TLSCiphertext:
  opaque_type:8       # Always 0x17 (application_data)
  legacy_record_version:16 # Always 0x0301
  length:16           # Length of the encrypted_record
  encrypted_record:length # Encrypted data including content type and padding

TLSCiphertextのopaque_typeが常にapplication_data (0x17)に設定されることで、Record Layerレベルでのパケットの内容判別が困難になり、トラフィック解析に対する耐性が向上しています。実際のコンテンツタイプは暗号化されたencrypted_record内に含まれます。

相互運用性

TLS 1.3は、古いTLSバージョンとの後方互換性を意図的に制限しています。これにより、プロトコルのクリーンアップとセキュリティ強化が実現されました。

  • ALPN (Application-Layer Protocol Negotiation): クライアントとサーバー間でどのアプリケーションプロトコル (例: HTTP/1.1, HTTP/2, h3/QUIC) を使用するかをハンドシェイク時にネゴシエートするのに不可欠です。TLS 1.3では、EncryptedExtensions内で暗号化されて行われます。

  • ダウングレード保護: TLS 1.3は、意図しない、または悪意のあるTLS 1.2以下のバージョンへのダウングレード攻撃を防ぐメカニズムを組み込んでいます。ServerHello.Randomフィールドの末尾8バイトに特定のパターン (RFC 8446 Section 4.1.3に定義されたDFLとDFL2) を含めることで、クライアントはサーバーがTLS 1.3をサポートしているにもかかわらず、TLS 1.2で応答しているダウングレード試行を検出できます。

セキュリティ考慮事項

TLS 1.3は、プロトコルレベルでセキュリティを大幅に強化していますが、実装上注意すべき点も存在します。

  • 前方秘匿性 (PFS) の強制: TLS 1.3では、すべての鍵交換に一時的なDiffie-Hellman鍵 ( ephemeral Diffie-Hellman; EDH) が使用されるため、PFSがデフォルトで保証されます。これにより、長期的な秘密鍵が将来漏洩しても、過去のセッションの盗聴データが復号されるリスクがなくなります。

  • ダウングレード攻撃保護: 前述の通り、ServerHello.Randomフィールドに特定のダウングレード検出メカニズムを組み込むことで、プロトコルレベルでのダウングレード攻撃が困難になります。

  • 0-RTTの再送リスク: 0-RTTモードで送信されたEarlyDataは、セッション確立前に送信されるため、サーバーはクライアントの真正性を完全に確認する前にデータを受け取ることになります。この特性は、攻撃者がEarlyDataを傍受して複数回サーバーに送信する「再送攻撃 (Replay Attack)」のリスクを伴います。

    • 対策: サーバー側は、EarlyDataに含まれるノンスやチケットの状態を追跡し、重複したデータを受け入れないような対策を講じる必要があります。また、冪等性 (idempotent) な操作 (複数回実行しても結果が変わらない操作、例: HTTP GETリクエスト) のみに0-RTTを許可することが推奨されます。

  • キー更新 (Key Update): アクティブなTLSセッション中に、クライアントまたはサーバーはKeyUpdateメッセージを送信して、新しいアプリケーションデータ暗号鍵を確立できます。これは、長時間のセッションにおける単一の鍵によるデータ露出量を制限し、セキュリティを向上させます。

  • ポストハンドシェイク認証: 初期ハンドシェイク後に、サーバーはクライアントにCertificateRequestメッセージを送信してクライアント証明書を要求し、認証を後から行うことができます。

  • トラフィック解析への対策: TLSPlaintextのContentTypeフィールドを暗号化されたメッセージ内に移動させ、常にapplication_data (0x17)をopaque_typeに設定することで、通信内容の推測を困難にします。また、パディングを任意に追加できるため、メッセージ長の均一化によりトラフィック量からの推測を妨げます。

既存プロトコルとの比較

TLS 1.3は、その前身や他の上位プロトコルとの関連において重要な位置を占めます。

TLS 1.2 と TLS 1.3 の比較

特徴 TLS 1.2 TLS 1.3 (RFC 8446)
ハンドシェイクRRT 2-RTT (初回接続) 1-RTT (初回接続) / 0-RTT (再接続)
鍵交換 DH/ECDHはオプション、RSA鍵交換も存在 DH/ECDHのみ、PFSを強制
暗号スイート 多くのレガシーな暗号スイートが存在 脆弱なものを削除、AEAD (AES-GCM, ChaCha20) のみ
メッセージ暗号化 ハンドシェイクの一部は平文 ServerHello以降のほとんどが暗号化される
セッション再開 Session ID / Session Ticket ベース NewSessionTicketによるPSKベース (0-RTTを可能に)
ダウングレード保護 限定的 強化されたメカニズムを導入
プロトコル構造 複雑 簡素化、攻撃ベクトルの削減

HTTP/2 と HTTP/3 (QUIC) との比較

TLS 1.3は、特に次世代のWebプロトコルであるHTTP/3 (QUIC) の基盤技術として不可欠です。

  • HTTP/2 (TLS 1.2/1.3 上で動作): HTTP/2はTLS 1.2またはTLS 1.3のいずれでも動作可能ですが、基盤がTCPであるため、TCPレベルのヘッドオブラインブロッキング (HOL blocking) の問題を抱えています。TLS 1.3の1-RTTハンドシェイクは接続確立を高速化しますが、TCPのオーバーヘッドは残ります。

  • HTTP/3 (QUIC + TLS 1.3): HTTP/3はトランスポート層にQUICを使用し、そのセキュリティ層としてTLS 1.3を組み込んでいます。

    • 1-RTTの統合: QUICのハンドシェイクとTLS 1.3のハンドシェイクが統合されており、初回接続からデータ転送までを1-RTTで完了させます。これは、TLS 1.3が提供する鍵共有の効率性と、QUICがトランスポート層でコネクションIDを用いて接続移行をサポートする能力によるものです。

    • 0-RTTの活用: QUICはTLS 1.3の0-RTT機能を最大限に活用し、セッション再開時のレイテンシをさらに短縮します。これにより、Webページの読み込み速度が大幅に向上します。

    • HOL blocking回避: QUICはUDPベースであり、ストリーム多重化を独自に実装しているため、TCPで発生するアプリケーションレベルのHOL blockingとは異なる、トランスポートレベルでのHOL blocking問題を回避できます。TLS 1.3の高速ハンドシェイクは、このQUICの利点をさらに引き出します。

実装注意

ネットワークエンジニアとしてTLS 1.3を実装・運用する際には、以下の点に注意が必要です。

  • MTU/Path MTU: TLS Record Layerは最大2^14バイト (16KB) のフラグメントをサポートしますが、基礎となるネットワークのMTU (Maximum Transmission Unit) を考慮する必要があります。特にPath MTU Discovery (PMTUD) が機能しない環境では、大きなTLSレコードがIPフラグメント化され、性能劣化やパケットロスを引き起こす可能性があります。0-RTTのEarlyDataを送信する際も、MTUを超過しないように注意が必要です。

  • HOL blocking回避 (QUIC/HTTP/3): TLS 1.3自体はトランスポートプロトコルではありませんが、その0-RTTおよび1-RTTハンドシェイクは、QUIC/HTTP/3におけるHOL blocking回避に大きく貢献します。TCPベースのTLS 1.3実装でも、ハンドシェイクの高速化は初期データの交換を早めますが、TCP自体のHOL blockingは解決されません。QUIC+TLS 1.3のスタックを適切に設計・実装することで、HOL blockingの影響を最小限に抑えられます。

  • キュー制御と優先度: サーバー側では、複数の0-RTT EarlyDataリクエストが同時に到着した場合の処理順序や、リソース枯渇攻撃に対する保護のため、適切なキュー制御と優先度付けが必要です。特に、再送リスクのあるリクエストに対する慎重な処理が求められます。

  • NewSessionTicketの管理: 0-RTTを効果的に活用するためには、NewSessionTicketの発行とクライアント側でのPSKの安全な管理が重要です。サーバーは、各チケットに一意のノンスを含め、かつその寿命を適切に設定し、再送攻撃のウィンドウを最小限に抑える必要があります。

  • CPU負荷: TLS 1.3は、古いバージョンと比較して暗号スイートが限定され、効率的な鍵導出プロセスを採用していますが、ECDH鍵交換やAEAD暗号の計算負荷は無視できません。ハードウェアアクセラレーション (例: AES-NI) の活用は、大規模なTLSトラフィックを処理する上で重要です。

まとめ

TLS 1.3 (RFC 8446) は、これまでのTLSプロトコルの進化において最も重要な改善の一つです。1-RTTおよび0-RTTハンドシェイクによる大幅なパフォーマンス向上と、前方秘匿性 (PFS) の強制、脆弱な機能の排除によるセキュリティの大幅な強化を実現しています。特にHTTP/3 (QUIC) の基盤技術として、インターネット通信全体の高速化と安全性の向上に貢献しています。

プロトコルを実装・運用するネットワークエンジニアは、0-RTTの再送リスクに対する適切な対策、MTUやキュー制御といったトランスポート層との連携、そしてNewSessionTicketの適切な管理に細心の注意を払う必要があります。これにより、TLS 1.3の持つ最大限のメリットを享受し、安全かつ高速な通信環境を構築できます。

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

コメント

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