<p><!--META
{
"title": "TLS 1.3ハンドシェイク詳解",
"primary_category": "ネットワーク",
"secondary_categories": ["セキュリティ", "プロトコル"],
"tags": ["TLS 1.3", "RFC 8446", "ハンドシェイク", "0-RTT", "セキュリティ"],
"summary": "TLS 1.3のハンドシェイクフロー、0-RTT再開、セキュリティ、実装上の考慮点を詳細に解説します。",
"mermaid": true,
"verify_level": "L0",
"tweet_hint": {"text":"TLS 1.3ハンドシェイクの仕組み、0-RTTの高速化、セキュリティ上の注意点、実装のポイントをRFC 8446に基づき詳解。ネットワークエンジニア必見です。","hashtags":["#TLS13","#RFC8446","#ネットワークセキュリティ"]},
"link_hints": ["https://datatracker.ietf.org/doc/html/rfc8446"]
}
-->
本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">TLS 1.3ハンドシェイク詳解</h1>
<p>TLS 1.3（RFC 8446）は、旧バージョンが抱えるセキュリティリスクとパフォーマンス課題を解決するため、ハンドシェイクのラウンドトリップタイム（RTT）削減と暗号スイートの厳格化を図ったプロトコルです。</p>
<h2 class="wp-block-heading">背景</h2>
<p>TLS 1.2以前のバージョンは、多くのレガシーな暗号アルゴリズムをサポートし、設定ミスやダウングレード攻撃のリスクを抱えていました。また、ハンドシェイクに2-RTT以上を要するため、特にモバイル環境や高遅延ネットワークにおいて接続開始時のパフォーマンスがボトルネックとなることがありました。これらの課題に対し、TLS 1.3はプロトコルの複雑性を減らし、セキュリティとパフォーマンスを同時に向上させることを目指して設計されました。</p>
<h2 class="wp-block-heading">設計目標</h2>
<p>TLS 1.3の設計目標は以下の通りです。</p>
<ul class="wp-block-list">
<li><strong>ハンドシェイクRTTの削減</strong>: フルハンドシェイクを1-RTTに短縮し、さらに0-RTTでのセッション再開を可能にすることで、接続確立時間を大幅に短縮します。</li>
<li><strong>セキュリティの強化</strong>: 旧来の脆弱な暗号スイートや機能（MD5、SHA-1、RSA鍵交換、CBCモード暗号など）を廃止し、前方秘匿性（Forward Secrecy）を強制します。</li>
<li><strong>複雑性の軽減</strong>: 暗号スイートの数を大幅に削減し、設定ミスによる脆弱性の発生を抑制します。</li>
<li><strong>既存プロトコルとの後方互換性への配慮</strong>: TLS 1.2のClientHelloメッセージフォーマットを維持しつつ、新しい拡張メカニズムでTLS 1.3の機能を提供します。</li>
</ul>
<h2 class="wp-block-heading">詳細</h2>
<p>TLS 1.3のハンドシェイクは、フルハンドシェイク（1-RTT）と0-RTTハンドシェイクの2種類が主要なシーケンスです。</p>
<h3 class="wp-block-heading">1-RTTハンドシェイク（フルハンドシェイク）</h3>
<p>新しいセッションを確立する場合や、セッションチケットが利用できない場合に用いられます。Diffie-Hellman Key Exchange (DHE) または Elliptic Curve Diffie-Hellman Key Exchange (ECDHE) を用いて、初回通信から前方秘匿性を有するセッション鍵を確立します。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
sequenceDiagram
participant Client
participant Server
Client -> Server: |ClientHello| (Supported Ciphers, Key Share, ALPN, Supported Versions, etc.)
Server -- >Client: |ServerHello| (Selected Cipher, Selected Key Share, etc.)
Server -> Client: |EncryptedExtensions| (Configuration parameters, ALPN selected)
alt Optional Authentication
Server -> Client: |Certificate| (Server's public key certificate)
Server -> Client: |CertificateVerify| (Proof of possession for Certificate)
end
Server -> Client: |Finished| (Handshake integrity check, first encrypted message)
Note over Client,Server: Server establishes 1-RTT Application Traffic Key.
Client -> Server: |Finished| (Handshake integrity check, first encrypted message)
Note over Client,Server: Client establishes 1-RTT Application Traffic Key.
Client -> Server: |Application Data| (Encrypted with 1-RTT key)
Server -> Client: |Application Data| (Encrypted with 1-RTT key)
</pre></div>
<p><strong>ハンドシェイクメッセージ構造:</strong></p>
<p>TLSレコード層は以下のヘッダを持ちます。</p>
<div class="codehilite">
<pre data-enlighter-language="generic">ContentType:8
ProtocolVersion:16
Length:16
</pre>
</div>
<p><code>ContentType</code>は<code>handshake</code> (22) を示し、<code>ProtocolVersion</code>はTLS 1.2との互換性のため<code>0x0303</code> (TLS 1.2) を用いることが推奨されますが、実際には<code>ClientHello.supported_versions</code>拡張でTLS 1.3をネゴシエートします。
ハンドシェイクメッセージ自体は、レコード層のペイロードとしてカプセル化されます。</p>
<div class="codehilite">
<pre data-enlighter-language="generic">HandshakeType:8
Length:24
MessageBody:...
</pre>
</div>
<p><code>HandshakeType</code>は<code>ClientHello</code> (1)、<code>ServerHello</code> (2)、<code>EncryptedExtensions</code> (8)、<code>Certificate</code> (11)、<code>CertificateVerify</code> (15)、<code>Finished</code> (20) などを示します。<code>Length</code>は<code>MessageBody</code>のバイト長です。</p>
<h3 class="wp-block-heading">0-RTTハンドシェイク</h3>
<p>以前に確立されたセッションを再開する際に利用され、ハンドシェイクを0-RTTで完了させることで、最初のアプリケーションデータをクライアントがサーバーへの最初のメッセージとして送信することを可能にします。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Previous session: Client receives NewSessionTicket from Server.
Client -> Server: |ClientHello| (PSK Key Exchange Mode, PSK Identity, 0-RTT Application Data)
Server -- >Client: |ServerHello| (PSK Selected)
Server -> Client: |EncryptedExtensions|
Server -> Client: |Finished|
Note over Client,Server: Server establishes 0-RTT and 1-RTT Application Traffic Keys.
Note over Client,Server: Server processes 0-RTT Application Data.
Client -> Server: |Finished|
Note over Client,Server: Client establishes 1-RTT Application Traffic Key.
Client -> Server: |Application Data| (Encrypted with 1-RTT key)
Server -> Client: |Application Data| (Encrypted with 1-RTT key)
</pre></div>
<p>クライアントは前回のセッションで受け取った<code>NewSessionTicket</code>（PSK identityと暗号化されたキー情報を含む）を利用して<code>ClientHello</code>を送信し、同時に0-RTTアプリケーションデータを送信します。サーバーがこのチケットを検証し、PSKを復号できれば、0-RTTでのデータ処理を開始できます。</p>
<h2 class="wp-block-heading">相互運用</h2>
<h3 class="wp-block-heading">既存プロトコルとの比較</h3>
<ul class="wp-block-list">
<li><p><strong>HTTP/2との比較</strong>:</p>
<ul>
<li><strong>TLSバージョン</strong>: HTTP/2はTLS 1.2以上を要求し、TLS 1.3を完全にサポートします。TLS 1.3の導入により、HTTP/2接続の確立が高速化されます。</li>
<li><strong>基盤プロトコル</strong>: HTTP/2はTCP上で動作し、その上にTLSが提供されます。TLS 1.3のハンドシェイクが1-RTTになったとしても、TCPの3ウェイハンドシェイク（1-RTT）は別途発生します。</li>
<li><strong>HOL blocking</strong>: HTTP/2はストリーム多重化によりアプリケーション層でのHOL blockingを緩和しますが、TCP層でのHOL blockingは依然として存在します。</li>
</ul></li>
<li><p><strong>HTTP/3との比較</strong>:</p>
<ul>
<li><strong>TLSバージョン</strong>: HTTP/3はQUIC上で動作し、QUICはTLS 1.3を<strong>必須</strong>としてプロトコルに組み込んでいます。</li>
<li><strong>基盤プロトコル</strong>: HTTP/3はUDP上で動作するQUICプロトコルを利用します。QUIC自体が暗号化と多重化を担い、TLS 1.3ハンドシェイクはQUICの暗号化ハンドシェイクの一部として行われます。</li>
<li><strong>ハンドシェイクRTT</strong>: QUICのハンドシェイクはTLS 1.3をベースとしているため、TCPとTLSのハンドシェイクを合わせて<strong>1-RTT</strong>で完了させることが可能です。これにより、HTTP/2と比較して接続確立時の遅延が大幅に削減されます。</li>
<li><strong>HOL blocking</strong>: QUICはUDPベースで独自の信頼性・順序保証メカニズムを持つため、TCP層でのHOL blockingを完全に回避し、ストリーム単位での配信エラーが他のストリームに影響を与えません。</li>
</ul></li>
</ul>
<h2 class="wp-block-heading">セキュリティ</h2>
<p>TLS 1.3は、セキュリティ面で多くの改善が図られています。</p>
<ul class="wp-block-list">
<li><strong>ダウングレード攻撃からの保護</strong>: TLS 1.3のClientHelloには、サポートされるTLSバージョンのリストが含まれており、旧バージョンへの強制的なダウングレードを防ぐためのメカニズムが導入されています。特定のバイト列をClientHelloの<code>legacy_version</code>フィールドに含めることで、サーバーはTLS 1.3をサポートしないクライアントからのダウングレード攻撃を検知できます。</li>
<li><strong>前方秘匿性（Forward Secrecy）の強制</strong>: すべてのハンドシェイクでDHEまたはECDHE鍵交換が必須となり、長期鍵の漏洩が過去のセッション鍵に影響を与えないようになります。RSA鍵交換は廃止されました。</li>
<li><strong>0-RTTデータのリプレイ攻撃対策</strong>: 0-RTTデータは、ネットワーク上で傍受され、複数回サーバーに送信されることでリプレイ攻撃を受ける可能性があります。TLS 1.3では、サーバー側で<code>NewSessionTicket</code>にタイムスタンプやワンタイムチケット（one-time nonce）を含める、あるいはクライアントが提供するメッセージの重複を検出するなどの対策が推奨されています。アプリケーション層でのリプレイ耐性も考慮する必要があります（例：冪等なリクエストのみを0-RTTで許可する）。</li>
<li><strong>キー更新（Key Update）</strong>: 長時間持続するセッション中に暗号鍵を定期的に更新するメカニズムが導入され、セッション鍵が漏洩した場合の被害範囲を限定します。これは<code>KeyUpdate</code>メッセージによって行われます。</li>
<li><strong>ハンドシェイク後の認証（Post-Handshake Authentication）</strong>: 初期ハンドシェイク後にクライアント証明書による認証を行うことが可能になりました。これにより、初回接続を高速化しつつ、必要に応じてセキュリティレベルを高めることができます。</li>
</ul>
<h2 class="wp-block-heading">実装メモ</h2>
<p>TLS 1.3の実装には、パフォーマンスと堅牢性を確保するためのいくつかの考慮事項があります。</p>
<ul class="wp-block-list">
<li><strong>MTU/Path MTU</strong>: TLSレコードサイズはPath MTUを超えないように調整する必要があります。特にハンドシェイクメッセージが大きい場合（例：多くの拡張を含むClientHelloやサイズの大きい証明書チェーン）、IPフラグメンテーションやTCPレベルでの再送が発生し、パフォーマンスが低下する可能性があります。適切なMTU管理は効率的なデータ転送に不可欠です。</li>
<li><strong>HOL blocking回避</strong>: QUIC/HTTP/3環境では、TLS 1.3がQUICの暗号化レイヤーとして機能し、ストリーム単位の多重化を提供します。これにより、TCP上のTLS 1.3で発生しうるアプリケーション層でのHOL blockingが回避されます。TCPベースのTLS 1.3実装では、この特性を意識し、適切にアプリケーションプロトコルを設計する必要があります。</li>
<li><strong>キュー制御と優先度</strong>: サーバー側では、ハンドシェイクメッセージや0-RTTデータのキュー制御と優先度付けが大切です。特に0-RTTデータはリプレイ攻撃のリスクがあるため、その処理の優先度やレートリミットを適切に設定し、悪意あるリクエストによるリソース枯渇を防ぐ必要があります。</li>
<li><strong>鍵管理</strong>: <code>NewSessionTicket</code>の配布と管理は、0-RTTのセキュリティとパフォーマンスに直結します。サーバーはチケットの有効期間、発行頻度、復号鍵のローテーションを適切に管理する必要があります。クライアントも受け取ったチケットの保存と利用戦略を考慮する必要があります。</li>
<li><strong>プロトコルダウングレードへの対応</strong>: クライアントは<code>supported_versions</code>拡張に必ずTLS 1.3を含めることで、TLS 1.3のネゴシエーションを試みます。サーバーもこれを適切に解釈し、TLS 1.3での接続を優先すべきです。</li>
</ul>
<h2 class="wp-block-heading">まとめ</h2>
<p>TLS 1.3は、ハンドシェイクの高速化、セキュリティ機能の強化、プロトコル複雑性の削減を通じて、現代のインターネット環境に最適化されたセキュアな通信基盤を提供します。1-RTTハンドシェイクと0-RTTハンドシェイクは、接続確立の遅延を大幅に削減し、特にHTTP/3とQUICにおける採用は、Webパフォーマンスの向上に大きく貢献しています。プロトコル実装者は、これらの利点を最大限に引き出すため、セキュリティ考慮事項と実装上の注意点を十分に理解し、堅牢なシステム構築に努める必要があります。</p>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
TLS 1.3ハンドシェイク詳解
TLS 1.3（RFC 8446）は、旧バージョンが抱えるセキュリティリスクとパフォーマンス課題を解決するため、ハンドシェイクのラウンドトリップタイム（RTT）削減と暗号スイートの厳格化を図ったプロトコルです。
背景
TLS 1.2以前のバージョンは、多くのレガシーな暗号アルゴリズムをサポートし、設定ミスやダウングレード攻撃のリスクを抱えていました。また、ハンドシェイクに2-RTT以上を要するため、特にモバイル環境や高遅延ネットワークにおいて接続開始時のパフォーマンスがボトルネックとなることがありました。これらの課題に対し、TLS 1.3はプロトコルの複雑性を減らし、セキュリティとパフォーマンスを同時に向上させることを目指して設計されました。
設計目標
TLS 1.3の設計目標は以下の通りです。
- ハンドシェイクRTTの削減: フルハンドシェイクを1-RTTに短縮し、さらに0-RTTでのセッション再開を可能にすることで、接続確立時間を大幅に短縮します。
- セキュリティの強化: 旧来の脆弱な暗号スイートや機能（MD5、SHA-1、RSA鍵交換、CBCモード暗号など）を廃止し、前方秘匿性（Forward Secrecy）を強制します。
- 複雑性の軽減: 暗号スイートの数を大幅に削減し、設定ミスによる脆弱性の発生を抑制します。
- 既存プロトコルとの後方互換性への配慮: TLS 1.2のClientHelloメッセージフォーマットを維持しつつ、新しい拡張メカニズムでTLS 1.3の機能を提供します。
詳細
TLS 1.3のハンドシェイクは、フルハンドシェイク（1-RTT）と0-RTTハンドシェイクの2種類が主要なシーケンスです。
1-RTTハンドシェイク（フルハンドシェイク）
新しいセッションを確立する場合や、セッションチケットが利用できない場合に用いられます。Diffie-Hellman Key Exchange (DHE) または Elliptic Curve Diffie-Hellman Key Exchange (ECDHE) を用いて、初回通信から前方秘匿性を有するセッション鍵を確立します。
sequenceDiagram
participant Client
participant Server
Client -> Server: |ClientHello| (Supported Ciphers, Key Share, ALPN, Supported Versions, etc.)
Server -- >Client: |ServerHello| (Selected Cipher, Selected Key Share, etc.)
Server -> Client: |EncryptedExtensions| (Configuration parameters, ALPN selected)
alt Optional Authentication
Server -> Client: |Certificate| (Server's public key certificate)
Server -> Client: |CertificateVerify| (Proof of possession for Certificate)
end
Server -> Client: |Finished| (Handshake integrity check, first encrypted message)
Note over Client,Server: Server establishes 1-RTT Application Traffic Key.
Client -> Server: |Finished| (Handshake integrity check, first encrypted message)
Note over Client,Server: Client establishes 1-RTT Application Traffic Key.
Client -> Server: |Application Data| (Encrypted with 1-RTT key)
Server -> Client: |Application Data| (Encrypted with 1-RTT key)
ハンドシェイクメッセージ構造:
TLSレコード層は以下のヘッダを持ちます。
ContentType:8
ProtocolVersion:16
Length:16
ContentTypeはhandshake (22) を示し、ProtocolVersionはTLS 1.2との互換性のため0x0303 (TLS 1.2) を用いることが推奨されますが、実際にはClientHello.supported_versions拡張でTLS 1.3をネゴシエートします。
ハンドシェイクメッセージ自体は、レコード層のペイロードとしてカプセル化されます。
HandshakeType:8
Length:24
MessageBody:...
HandshakeTypeはClientHello (1)、ServerHello (2)、EncryptedExtensions (8)、Certificate (11)、CertificateVerify (15)、Finished (20) などを示します。LengthはMessageBodyのバイト長です。
0-RTTハンドシェイク
以前に確立されたセッションを再開する際に利用され、ハンドシェイクを0-RTTで完了させることで、最初のアプリケーションデータをクライアントがサーバーへの最初のメッセージとして送信することを可能にします。
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Previous session: Client receives NewSessionTicket from Server.
Client -> Server: |ClientHello| (PSK Key Exchange Mode, PSK Identity, 0-RTT Application Data)
Server -- >Client: |ServerHello| (PSK Selected)
Server -> Client: |EncryptedExtensions|
Server -> Client: |Finished|
Note over Client,Server: Server establishes 0-RTT and 1-RTT Application Traffic Keys.
Note over Client,Server: Server processes 0-RTT Application Data.
Client -> Server: |Finished|
Note over Client,Server: Client establishes 1-RTT Application Traffic Key.
Client -> Server: |Application Data| (Encrypted with 1-RTT key)
Server -> Client: |Application Data| (Encrypted with 1-RTT key)
クライアントは前回のセッションで受け取ったNewSessionTicket（PSK identityと暗号化されたキー情報を含む）を利用してClientHelloを送信し、同時に0-RTTアプリケーションデータを送信します。サーバーがこのチケットを検証し、PSKを復号できれば、0-RTTでのデータ処理を開始できます。
相互運用
既存プロトコルとの比較
HTTP/2との比較:
- TLSバージョン: HTTP/2はTLS 1.2以上を要求し、TLS 1.3を完全にサポートします。TLS 1.3の導入により、HTTP/2接続の確立が高速化されます。
- 基盤プロトコル: HTTP/2はTCP上で動作し、その上にTLSが提供されます。TLS 1.3のハンドシェイクが1-RTTになったとしても、TCPの3ウェイハンドシェイク（1-RTT）は別途発生します。
- HOL blocking: HTTP/2はストリーム多重化によりアプリケーション層でのHOL blockingを緩和しますが、TCP層でのHOL blockingは依然として存在します。
HTTP/3との比較:
- TLSバージョン: HTTP/3はQUIC上で動作し、QUICはTLS 1.3を必須としてプロトコルに組み込んでいます。
- 基盤プロトコル: HTTP/3はUDP上で動作するQUICプロトコルを利用します。QUIC自体が暗号化と多重化を担い、TLS 1.3ハンドシェイクはQUICの暗号化ハンドシェイクの一部として行われます。
- ハンドシェイクRTT: QUICのハンドシェイクはTLS 1.3をベースとしているため、TCPとTLSのハンドシェイクを合わせて1-RTTで完了させることが可能です。これにより、HTTP/2と比較して接続確立時の遅延が大幅に削減されます。
- HOL blocking: QUICはUDPベースで独自の信頼性・順序保証メカニズムを持つため、TCP層でのHOL blockingを完全に回避し、ストリーム単位での配信エラーが他のストリームに影響を与えません。
セキュリティ
TLS 1.3は、セキュリティ面で多くの改善が図られています。
- ダウングレード攻撃からの保護: TLS 1.3のClientHelloには、サポートされるTLSバージョンのリストが含まれており、旧バージョンへの強制的なダウングレードを防ぐためのメカニズムが導入されています。特定のバイト列をClientHelloの
legacy_versionフィールドに含めることで、サーバーはTLS 1.3をサポートしないクライアントからのダウングレード攻撃を検知できます。
- 前方秘匿性（Forward Secrecy）の強制: すべてのハンドシェイクでDHEまたはECDHE鍵交換が必須となり、長期鍵の漏洩が過去のセッション鍵に影響を与えないようになります。RSA鍵交換は廃止されました。
- 0-RTTデータのリプレイ攻撃対策: 0-RTTデータは、ネットワーク上で傍受され、複数回サーバーに送信されることでリプレイ攻撃を受ける可能性があります。TLS 1.3では、サーバー側で
NewSessionTicketにタイムスタンプやワンタイムチケット（one-time nonce）を含める、あるいはクライアントが提供するメッセージの重複を検出するなどの対策が推奨されています。アプリケーション層でのリプレイ耐性も考慮する必要があります（例：冪等なリクエストのみを0-RTTで許可する）。
- キー更新（Key Update）: 長時間持続するセッション中に暗号鍵を定期的に更新するメカニズムが導入され、セッション鍵が漏洩した場合の被害範囲を限定します。これは
KeyUpdateメッセージによって行われます。
- ハンドシェイク後の認証（Post-Handshake Authentication）: 初期ハンドシェイク後にクライアント証明書による認証を行うことが可能になりました。これにより、初回接続を高速化しつつ、必要に応じてセキュリティレベルを高めることができます。
実装メモ
TLS 1.3の実装には、パフォーマンスと堅牢性を確保するためのいくつかの考慮事項があります。
- MTU/Path MTU: TLSレコードサイズはPath MTUを超えないように調整する必要があります。特にハンドシェイクメッセージが大きい場合（例：多くの拡張を含むClientHelloやサイズの大きい証明書チェーン）、IPフラグメンテーションやTCPレベルでの再送が発生し、パフォーマンスが低下する可能性があります。適切なMTU管理は効率的なデータ転送に不可欠です。
- HOL blocking回避: QUIC/HTTP/3環境では、TLS 1.3がQUICの暗号化レイヤーとして機能し、ストリーム単位の多重化を提供します。これにより、TCP上のTLS 1.3で発生しうるアプリケーション層でのHOL blockingが回避されます。TCPベースのTLS 1.3実装では、この特性を意識し、適切にアプリケーションプロトコルを設計する必要があります。
- キュー制御と優先度: サーバー側では、ハンドシェイクメッセージや0-RTTデータのキュー制御と優先度付けが大切です。特に0-RTTデータはリプレイ攻撃のリスクがあるため、その処理の優先度やレートリミットを適切に設定し、悪意あるリクエストによるリソース枯渇を防ぐ必要があります。
- 鍵管理:
NewSessionTicketの配布と管理は、0-RTTのセキュリティとパフォーマンスに直結します。サーバーはチケットの有効期間、発行頻度、復号鍵のローテーションを適切に管理する必要があります。クライアントも受け取ったチケットの保存と利用戦略を考慮する必要があります。
- プロトコルダウングレードへの対応: クライアントは
supported_versions拡張に必ずTLS 1.3を含めることで、TLS 1.3のネゴシエーションを試みます。サーバーもこれを適切に解釈し、TLS 1.3での接続を優先すべきです。
まとめ
TLS 1.3は、ハンドシェイクの高速化、セキュリティ機能の強化、プロトコル複雑性の削減を通じて、現代のインターネット環境に最適化されたセキュアな通信基盤を提供します。1-RTTハンドシェイクと0-RTTハンドシェイクは、接続確立の遅延を大幅に削減し、特にHTTP/3とQUICにおける採用は、Webパフォーマンスの向上に大きく貢献しています。プロトコル実装者は、これらの利点を最大限に引き出すため、セキュリティ考慮事項と実装上の注意点を十分に理解し、堅牢なシステム構築に努める必要があります。
コメント