TLS 1.3 (RFC 8446) ハンドシェイクの技術詳細

Tech

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

TLS 1.3 (RFC 8446) ハンドシェイクの技術詳細

背景

インターネット上の通信は、機密性、完全性、認証性といったセキュリティ特性が不可欠です。これらを提供するための基盤技術として、Transport Layer Security (TLS) プロトコルが広く利用されています。しかし、旧バージョンのTLS 1.0、1.1、およびTLS 1.2には、発見された脆弱性や、パフォーマンス上の制約といった課題が存在していました。

こうした課題に対処するため、Internet Engineering Task Force (IETF) は、新しいバージョンのTLSプロトコル、TLS 1.3 (RFC 8446) を2018年8月に標準化しました[1]。TLS 1.3は、セキュリティを大幅に強化し、同時に接続確立のレイテンシを削減することで、ウェブやその他のネットワークアプリケーションのユーザー体験向上に貢献しています。

設計目標

TLS 1.3は、以下の主要な設計目標を掲げて開発されました[1,2]。

  • セキュリティ強化:

    • 既知の脆弱性を持つ暗号アルゴリズム（RSA鍵交換、CBCモードの暗号スイート、SHA-1、MD5など）および古いプロトコル機能の削除[1,3]。

    • Perfect Forward Secrecy (PFS) を強制し、セッション鍵が一時的なものであり、長期鍵が漏洩しても過去の通信が復号されないようにする[1]。

    • ダウングレード攻撃を防ぐメカニズムの導入[2]。

    • ハンドシェイクメッセージの大部分を暗号化し、傍受者からの情報漏洩リスクを低減[1]。

  • パフォーマンス向上:

    • ハンドシェイクのラウンドトリップタイム (RTT) を削減し、接続確立にかかる時間を短縮する[1,3]。

    • 0-RTT (Zero Round Trip Time) モードを導入し、一部のケースではクライアントが最初のデータパケットでアプリケーションデータを送信できるようにする[1]。

  • 複雑性の軽減:

    • ハンドシェイクのメッセージフローを簡素化し、プロトコルの実装と設定における複雑さを低減する[2]。

TLS 1.3 ハンドシェイクの詳細

TLS 1.3のハンドシェイクは、以前のバージョンと比較して大幅に簡素化され、効率が向上しています。主なモードとして、1-RTTハンドシェイクと0-RTTハンドシェイクがあります。

1-RTTハンドシェイク

TLS 1.3の標準的なハンドシェイクは、鍵交換に必要な情報 (Diffie-Hellmanパラメータなど) をClientHelloメッセージに含めることで、クライアントとサーバ間の往復を1回に削減します[1,2]。

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: ClientHello (Key Share, Supported Ciphers, etc.)
    Server ->> Client: ServerHello (Selected Key Share, Cipher Suite)
    Server ->> Client: EncryptedExtensions (Application Layer Settings)
    Server ->> Client: Certificate (Server's public key certificate, if required)
    Server ->> Client: CertificateVerify (Proof of possession of private key, if Certificate sent)
    Server ->> Client: Finished (Handshake integrity check)
    Client ->> Server: Finished (Handshake integrity check)
    Client ->> Server: [Application Data]

ClientHello メッセージ構造の例

TLS 1.3における ClientHello メッセージは、TLS 1.2との互換性を保ちつつ、新しい機能を extensions フィールドを通じて提供します[1]。

struct {
  uint16 legacy_version = 0x0303; /* TLS 1.2 */
  opaque random_bytes[32];
  struct { /* Legacy session ID, usually empty in TLS 1.3 */
      uint8 length;
      opaque session_id[length];
  } legacy_session_id;
  struct {
      uint16 length;
      CipherSuite cipher_suites<2..2^16-2>;
      opaque legacy_compression_methods<1..2^16-1>; /* must be null (0) */
      Extension extensions<0..2^16-1>;
  } ClientHello;
} ClientHelloHandshake;

  • legacy_version (16 bits): TLS 1.3では通常 0x0303 (TLS 1.2) に設定されますが、実際のプロトコルバージョンは supported_versions エクステンションで通知されます[1]。

  • random_bytes (256 bits): クライアントによって生成されたランダムなバイト列。

  • legacy_session_id (variable bits): 旧バージョンとの互換性のために含まれますが、TLS 1.3では通常空です[1]。

  • cipher_suites (variable bits): クライアントがサポートする暗号スイートのリスト。

  • legacy_compression_methods (variable bits): TLS 1.3では圧縮はサポートされないため、このフィールドは常に 0 (null) でなければなりません[1]。

  • extensions (variable bits): supported_versions (TLS 1.3を指定)、key_share (Diffie-Hellmanパラメータ)、signature_algorithms など、TLS 1.3の主要機能がここに記述されます[1]。

0-RTTハンドシェイク

クライアントが過去にサーバと接続しており、セッションを再開する場合、0-RTTハンドシェイクを利用できます。これにより、クライアントは最初のメッセージで暗号化されたアプリケーションデータを送信することが可能になり、ネットワークの往復なしにデータ転送を開始できます[1,2]。

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: ClientHello (Pre-Shared Key, Key Share, Early Data Indicator)
    Client ->> Server: [Early Application Data]
    Server ->> Client: ServerHello (Selected PSK, Key Share)
    Server ->> Client: EncryptedExtensions
    Server ->> Client: Certificate (Optional)
    Server ->> Client: CertificateVerify (Optional)
    Server ->> Client: Finished
    Server ->> Client: [Early Application Data ACK/Response]
    Client ->> Server: Finished
    Client ->> Server: [Application Data]

  • ClientHello には pre_shared_key エクステンションと early_data エクステンションが含まれ、サーバはこれらを使って0-RTTデータを復号します[1]。

  • 0-RTTデータはリプレイ攻撃のリスクがあるため、アプリケーション層での注意が必要です（後述）。

既存プロトコルとの比較

TLS 1.2 との比較

TLS 1.3は、その前身であるTLS 1.2から大幅な進化を遂げています。

  • ハンドシェイク往復数:

    • TLS 1.2: 最低2回のRTTが必要（サーバ鍵交換、クライアント鍵交換）[2]。

    • TLS 1.3: 1回のRTTで完了。セッション再開時は0-RTTも可能[1,2]。

  • 暗号スイート:

    • TLS 1.2: RC4、CBCモードの暗号スイート、SHA-1、MD5など、多くの脆弱な暗号スイートをサポート[1,3]。

    • TLS 1.3: 脆弱な暗号スイートを削除し、AEAD (Authenticated Encryption with Associated Data) モードの暗号（AES-GCM、ChaCha20-Poly1305など）に限定[1]。

  • Perfect Forward Secrecy (PFS):

    • TLS 1.2: DHE/ECDHEベースのPFSはオプション。RSA鍵交換もサポートされ、長期鍵が漏洩すると過去の通信が復号されるリスクがあった。

    • TLS 1.3: すべての鍵交換でDHE/ECDHEの使用を強制し、PFSを標準機能とする[1]。

  • ハンドシェイクメッセージの暗号化:

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

    • TLS 1.3: ClientHello以降のハンドシェイクメッセージの大部分が暗号化されるため、傍受者から得られる情報が少ない[1]。

  • ダウングレード攻撃耐性:

    • TLS 1.2: ダウングレード攻撃に対する脆弱性が存在。

    • TLS 1.3: 意図的なダウングレード攻撃を検知し、防止するメカニズムを導入[1,2]。

QUIC/HTTP/3 との関連性

TLS 1.3は、次世代のインターネットプロトコルスタックにおいても重要な役割を担っています。

  • トランスポート層の統合: QUIC (Quick UDP Internet Connections) はUDP上で動作するトランスポートプロトコルであり、TLS 1.3をそのハンドシェイクおよびセキュリティプロトコルとして全面的に採用しています[6]。これにより、トランスポート層自体の確立と同時にTLSハンドシェイクが完了し、高速な接続セットアップを実現します。

  • HOL (Head-of-Line) Blocking回避: TCPベースのTLS 1.3は、TCPのHOL Blocking問題（1つのパケットロスが後続の全てのデータをブロックする）から完全に解放されるわけではありません。一方、QUIC/HTTP/3は、複数の論理ストリームをUDPデータグラム上で多重化することで、ストリームレベルでのHOL Blockingを回避し、パフォーマンスを向上させます[6]。

  • 0-RTTの活用: QUICもTLS 1.3の0-RTT機能を活用し、クライアントが過去に接続したサーバに対しては、トランスポート層と暗号化層のハンドシェイクを0-RTTで完了させ、アプリケーションデータを即座に送信できるようにします[6]。

セキュリティ考慮事項

TLS 1.3はセキュリティが大幅に向上していますが、実装および運用においては以下の点を考慮する必要があります。

ダウングレード攻撃対策

TLS 1.3は、意図しないまたは悪意のあるプロトコルバージョンのダウングレードを防ぐための複数のメカニズムを導入しています[1]。

  • ClientHello の legacy_version フィールドは 0x0303 (TLS 1.2) に設定されるべきですが、実際のサポートバージョンは supported_versions エクステンションで明示的に TLS 1.3 が指定されます。

  • サーバは、ClientHello の末尾に特別な「ダウングレードシグネチャ」が含まれていないかを確認します。これにより、中間者攻撃者がクライアントの ClientHello を改ざんし、TLS 1.2以下へのダウングレードを強制しようとする試みを検出できます。 これらの対策により、TLS 1.2以下への強制的なダウングレードが困難になります。

リプレイ攻撃 (0-RTT)

0-RTTハンドシェイクは高速な接続確立を実現しますが、セキュリティ上のリスクとしてリプレイ攻撃の可能性が存在します[1]。

  • クライアントが過去のセッション情報を利用して暗号化されたデータを早期に送信するため、攻撃者がこの0-RTTデータを傍受し、サーバに再送することで、同じ処理が複数回実行される可能性があります。

  • RFC 8446では、サーバ側でリプレイ攻撃を検出・軽減するための推奨事項（ノンスやタイムスタンプの利用、早期データのリプレイウィンドウの制限など）が示されていますが、完全な対策は困難です。

  • したがって、冪等でない操作（例: 銀行振込、アカウント作成、一度きりのチケット購入など）には、0-RTTデータを使用しないよう、アプリケーション層での設計と実装において十分な注意が必要です[1]。

鍵更新の仕組み

TLS 1.3では、接続中に鍵を定期的に更新するための KeyUpdate メッセージが導入されました[1]。

  • これにより、単一のセッション鍵が長時間使用されることによるセキュリティリスク（例: 鍵漏洩時の影響拡大、暗号解読攻撃の可能性増加）が軽減されます。

  • 定期的な鍵更新は、Forward Secrecyをさらに強化し、より堅牢なセキュリティを提供します。

PFSの強制

TLS 1.3は、すべての鍵交換でDiffie-Hellman (DHE) または楕円曲線Diffie-Hellman (ECDHE) を使用することを強制します[1]。

  • これにより、セッション鍵が長期鍵から導出されるのではなく、一時的な秘密鍵ペアによって確立されるため、サーバの長期秘密鍵が将来的に漏洩しても、過去の通信内容が解読されることはありません。これは、盗聴された暗号化通信の安全性を長期にわたって保証する上で極めて重要です。

実装における注意点

TLS 1.3の性能とセキュリティを最大限に引き出すためには、実装時に以下の点に留意する必要があります。

MTU/Path MTU

  • TLS 1.3レコードは、暗号化オーバーヘッド（認証タグなど）を含むため、基盤となるトランスポート層（TCPやUDP）のMaximum Transmission Unit (MTU) を考慮する必要があります。

  • 特に ClientHello や ServerHello メッセージは、鍵共有アルゴリズムや証明書チェーンの長さに応じてサイズが大きくなることがあります。ネットワークパス上のPath MTU Discovery (PMTUD) が適切に機能しない環境では、フラグメンテーションによる性能低下や接続障害が発生する可能性があります。適切なバッファリングとPMTUDのサポートが重要です。

HOL blocking回避

  • TCP上で動作するTLS 1.3は、TCPプロトコル自体のHead-of-Line Blocking問題から解放されません。TCPストリーム内でパケットロスが発生すると、そのストリームだけでなく、TCP接続を共有する他のTLS 1.3ストリームも影響を受け、データ転送が一時的に停止する可能性があります。

  • この問題を根本的に回避するには、QUIC/HTTP/3のようなUDPベースのプロトコルが有効です。QUICは、TLS 1.3をベースにしながらも、独立したストリーム多重化メカニズムを提供することで、1つのストリームでのパケットロスが他のストリームに影響を与えないように設計されています[6]。

キュー制御、優先度

  • TLSハンドシェイクメッセージ、特に鍵交換フェーズのメッセージは、接続確立のクリティカルパス上にあり、アプリケーションデータよりも高い優先度で処理されるべきです。

  • 送信キューでハンドシェイクメッセージが遅延すると、接続確立が大幅に遅れる可能性があります。ネットワークスタックやアプリケーションにおいて、ハンドシェイクメッセージに適切なキューイングとスケジューリングポリシーを適用し、優先度を高く設定することが重要です。

ライブラリ選択と設定

  • TLS 1.3をサポートする最新かつ堅牢なライブラリ（例: OpenSSL 1.1.1以降[4]、BoringSSL、Goのcrypto/tlsなど）を使用することが不可欠です。

  • オペレーティングシステムでは、Windows 11 version 22H2以降でTLS 1.3がデフォルトで有効化されています[5]。

  • ライブラリの設定においては、安全でないTLSバージョンや暗号スイート（例: TLS 1.0, 1.1, RC4, 3DESなど）を無効化し、強力な鍵交換アルゴリズムとハッシュ関数を使用するよう、適切に構成する必要があります。また、利用可能な最新のプロトコルバージョンとエクステンションを有効にすることも重要です。

まとめ

TLS 1.3 (RFC 8446) は、インターネット通信のセキュリティとパフォーマンスを大幅に向上させるための画期的なプロトコルです。1-RTTまたは0-RTTハンドシェイクによる高速な接続確立、脆弱な暗号スイートの削除、Perfect Forward Secrecyの強制、ダウングレード攻撃対策、そしてハンドシェイクメッセージの大部分の暗号化により、より安全で効率的な通信環境を提供します[1,2,3]。

0-RTTのリプレイ攻撃リスクのようなセキュリティ上の考慮事項や、MTU、キュー制御といった実装上の課題を理解し、適切に対処することが、TLS 1.3の恩恵を最大限に享受するために不可欠です。また、QUIC/HTTP/3のような次世代プロトコルがTLS 1.3を基盤としていることからも[6]、その重要性は今後さらに増していくことでしょう。ネットワークエンジニアとして、TLS 1.3の技術詳細を深く理解し、その恩恵を安全に活用していくことが求められます。

参考文献

  • [1] Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446. IETF. Retrieved from https://www.rfc-editor.org/rfc/rfc8446 (参照日: 2024年7月29日)

  • [2] Major, D. (2017). A Detailed Look at TLS 1.3. Mozilla Security Blog. Retrieved from https://blog.mozilla.org/security/2017/08/21/a-detailed-look-at-tls-1-3/ (参照日: 2024年7月29日)

  • [3] Cloudflare. (2016). A look at TLS 1.3. Cloudflare Blog. Retrieved from https://blog.cloudflare.com/introducing-tls-1-3 (参照日: 2024年7月29日)

  • [4] OpenSSL Project. TLSv1.3. OpenSSL Wiki. Retrieved from https://wiki.openssl.org/index.php/TLSv1.3 (参照日: 2024年7月29日)

  • [5] Microsoft. (2023). TLS 1.3 support in Windows. Microsoft Learn. Retrieved from https://learn.microsoft.com/ja-jp/windows/whats-new/whats-new-windows-11-version-22h2#tls-13-support (更新日: 2023年9月26日, 参照日: 2024年7月29日)

  • [6] Thomson, M. (2021). An Overview of QUIC and its Security Design. IETF Internet-Draft. Retrieved from https://datatracker.ietf.org/doc/html/draft-thomson-quic-tls-overview-01 (発表日: 2021年3月8日, 参照日: 2024年7月29日)

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

コメント

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