TLS 1.3 ハンドシェイク

TLS 1.3 は、鍵合意に必要な材料を ClientHello に事前に配置することで、一般的な完全ハンドシェイクのラウンドトリップを1回削減します。同時に、ハンドシェイクトラフィックとアプリケーショントラフィックを段階的に保護します。依然として、身份の検証、履歴の合意、鍵の合意が必要であり、0-RTT にも通常アプリケーションデータとは異なるセキュリティ特性があります。

2026年9月現在、TLS 1.3 の更新仕様は2026年7月に公開された RFC 9846 で、RFC 8446 を置き換えています。本稿では更新仕様を入口とし、旧資料の一般的な名称との対応関係も残しています。ECH は2026年3月に RFC 9849 として公開され、もはや草案ではありません。RFC 9846、RFC 9849

バージョン、スイート、認証アルゴリズムの分離合意

TLS 1.3 のバージョン選択は supported_versions を見ます。互換性フィールドの legacy_version は 0x0303 を使用するため、このフィールドを見ただけでは最終的に TLS 1.2 に合意したと直接判断できません。ServerHello の selected version と完全ハンドシェイクのコンテキストが判断の根拠となります。

TLS_AES_128_GCM_SHA256 は、記録層の AEAD と HKDF/トランスクリプトに使用されるハッシュのみを示し、TLS 1.2 のスイート名のように鍵交換や認証カテゴリを束縛しません。key_share/supported_groups と signature_algorithms が他の制約を示しており、AES スイート名から証明書が RSA でなければならない、または鍵交換が X25519 でなければならないと推論できません。

TLS 1.3 は、静的 RSA 鍵交換、CBC 記録保護などの旧メカニズムを削除しました。これにより RSA 署名がすべて消えたわけではありません。仕様上の基本5スイートが、登録空間に永遠に5つの値しか存在し得ないことを意味するわけではありません。TLS 1.2 と TLS 1.3 のスイートは相互に使用できません。RFC 9846：合意とスイート

1ラウンドトリップ内の4つの重要なアクション

クライアントは ClientHello でサポートされるグループと選択されたグループの公開 key_share を提供します。サーバーは互換性のある材料を選択し、自身の share を返します。一般的な ECDHE モードでは、この時点で双方が共有秘密を計算でき、ハンドシェイクトラフィック鍵を派生できるため、その後の Certificate などのメッセージを暗号化できます。

「すでに復号できる」からといって「相手を認証した」わけではありません。クライアントは依然として証明書によるサービス身元の検証、CertificateVerify の署名、Finished の検証を行う必要があります。サーバーはクライアントの Finished を受信して、対応するハンドシェイク状態を確認します。通常のサーバー認証シナリオでは、クライアントは最初の RTT 後に Finished とその後のアプリケーションデータを送信できますが、これらは異なる段階の鍵を使用します。

ここで言う1 RTT は TLS ハンドシェイクのセマンティクスであり、TCP 接続確立、DNS、またはビジネス応答は含まれません。TLS 1.2 でもすべてのハンドシェイクメッセージが平文であるわけではありません。TLS 1.2 の Finished は合意後の記録保護を使用します。TLS 1.3 の利点は、より早くより多くのハンドシェイクコンテンツを保護することであり、「完全に保護なし」から一歩で跳躍するものではありません。

HelloRetryRequest：材料が必要な場合の通常の再試行

supported_groups はサポートされるグループをリストし、key_share はその中の一部のグループの実際の材料のみを保持します。サーバーが保持されていないが双方がサポートするグループを必要とする場合、HRR を送信できるほか、cookie の要求も行う可能性があります。クライアントは制限に従って2番目の ClientHello を構築し、1ラウンドトリップ余計にかかります。

HRR は特殊な Random 値を持つ ServerHello 構造であり、メッセージタイプだけを見て通常の ServerHello と見なすことはできません。トランスクリプトは合成された message_hash を使用して最初の ClientHello のハッシュに組み込まれ、単純に破棄することはできません。実装では、許可されない2回目の HRR および不正なパラメータ変更もチェックする必要があります。RFC 9846：HelloRetryRequest

HRR の発生は、デプロイされたグループポリシーとクライアントの材料に依存しており、「X25519 はほぼ常に当てはまる」ということを永続的な事実として使用することはできません。更新仕様は、より一般的な非対称鍵確立の表現を使用して関連メカニズムを記述しており、すべての将来の key_share を楕円曲線上の裸の公開鍵として定義することはできません。

CertificateVerify と Finished はそれぞれ何を証明するか

CertificateVerify は、対応する証明書秘密鍵を使用して、規定されたコンテキストとトランスクリプトハッシュに署名し、身元認証を今回のハンドシェイクに結びつけます。この署名入力は、固定パディングと役割コンテキスト文字列も含んでおり、ClientHello テキストの断片を随意に直接署名するものではありません。

Finished は、その方向のハンドシェイクトラフィック秘密から finished_key を派生し、HMAC でトランスクリプトハッシュを検証します。SHA256 スイートでは verify_data は 32 バイト、SHA384 では 48 バイトであり、TLS 1.2 で一般的な 12 バイトをそのままコピーすることはできません。証明書検証、秘密鍵所持の証明、共有鍵の確認は補完関係にあり、どれか1つが欠けても「TLS で復号できる」だけで補うことはできません。RFC 9846：認証メッセージ

互換モードではダミーの CCS が表示される場合がありますが、TLS 1.3 は TLS 1.2 のような CCS を使用して実際の暗号化状態を切り替えません。パケットキャプチャは、ハンドシェイクの段階と traffic secret に基づいて記録を理解すべきであり、各 CCS を鍵切り替えイベントとして扱うべきではありません。

HKDF：Extract で秘密を混合し、Expand で用途を分離

HKDF-Extract は salt と入力鍵材料から PRK を取得します。HKDF-Expand は info と長さを使用して出力を派生します。TLS の HKDF-Expand-Label は、info に長さ、tls13 プレフィックス付きのタグ、およびコンテキストをエンコードします。タグはプロトコルバイトであり、自然言語の変数名の変更によって変更されるものではありません。RFC 5869：HKDF

Derive-Secret(S,label,messages) をトランスクリプトハッシュのタグを使用して派生するものとして覚えます。一般的な非対称合意パスは以下の通りです：

1. Early = Extract(zeros, PSK)。PSK を使用しない場合、入力はハッシュ長でゼロ埋めされます。
2. derived₁ = Derive-Secret(Early, "derived", empty_messages)。
3. Handshake = Extract(derived₁, shared_secret)。
4. derived₂ = Derive-Secret(Handshake, "derived", empty_messages)。
5. Main = Extract(derived₂, zeros)。

2回の Extract の前には、必ず derived secret を派生する必要があります。どちらかを省略すると、その後の秘密とトラフィック鍵が変更されます。Main Secret は RFC 8446 の資料では Master Secret と呼ばれていましたが、更新仕様で用語が変更されました。ただし、互換性のために必要なタグは保持されています。RFC 9846：鍵スケジュール

ハンドシェイク traffic secret は ServerHello のトランスクリプトにバインドされ、初期アプリケーション traffic secret はサーバーの Finished にバインドされ、回復関連秘密はクライアントの Finished にバインドされます。すべての Expand が「此刻のすべてのメッセージ」を混合するわけではありません。key/IV/finished などのブランチにはそれぞれ context ルールがあり、統一して置き換えることはできません。

記録 nonce とオーバーヘッド

アプリケーション traffic secret は key と IV を派生します。TLS 1.3 の記録 nonce は、この方向の IV とパディングされた記録シーケンス番号の XOR で取得され、TLS 1.2 の GCM のようにオンラインで別途 8 バイトの明示的な nonce を送信する必要はありません。鍵更新後は新しい状態に従ってシーケンス番号を管理し、同じ key/nonce が再利用されないようにする必要があります。

パディングなしの AES-GCM の例：1000 バイトのコンテンツに 1 バイトの内部 content type、16 バイトの tag、5 バイトの外部ヘッダーを追加すると、合計 1022 バイトの TLS データになります。内部の実際のタイプは暗号化され、外部は保護された記録で対応する互換タイプを使用します。これにより、パケット長とタイミングは隠蔽されません。

同じ秘密なのに、なぜ異なる方向の鍵を派生できるのか？

方向の切り替えは、traffic およびそのサブブランチのみを変更し、上位の Handshake Secret は変更してはいけません。トランスクリプトを変更する場合も同様です。derived を省略すると Extract の salt が変更され、Handshake 以降のすべての後続値に影響します。変更の境界を通じて依存関係図を読んでください。

PSK 回復と 0-RTT は別の事柄

回復は既存の PSK 状態を使用して新しい接続を確立し、通常の 1-RTT を選択することも、許可された場合に early data を試すこともできます。NewSessionTicket のチケットフィールドは、サーバーが認識可能な回復識別子/カプセル化であり、PSK を平文で送信するものではありません。クライアントは回復秘密と ticket nonce などを基に対応する PSK を派生します。

ClientHello の PSK identity は候補を指定し、binder はクライアントが関連する PSK を保持していることを証明し、規定された部分の ClientHello にバインドします。これは、まだ受信されていないサーバーの新しいメッセージを検証するものではなく、early data のリプレイ防止を自動的に有効にするものでもありません。

したがって、「TLS 1.3 は ECDHE のみを許可し、すべてのデータに前方秘匿性を強制する」という主張は成立しません。psk_dhe_ke 名称の dhe は、更新仕様では歴史的命名であり、対応する非対称鍵確立モードをカバーしています。RFC 9846：PSK モード

early data の受信とリプレイ

サーバーは early data を拒否しつつ、ハンドシェイクを継続することができます。クライアントは「ハンドシェイクの成功」と「早期操作の受信」を区別し、アプリケーションのセマンティクスに従って後続の再送信方法を決定する必要があります。max_early_data_size は受信可能な規模を制約するものであり、ビジネスの重複排除メカニズムとして使用することはできません。

攻撃者は有効な早期データをリプレイする可能性があります。サーバーは、チケットの使用、時間窓、リプレイ防止状態、およびアプリケーション設計を組み合わせて処理する必要があります。ノード間キャッシュにより、ワンタイム使用を保証するのが困難になる場合もあります。HTTP メソッド名はセキュリティ証明ではなく、GET でも副作用がある場合は軽率に事前に実行すべきではありません。0-RTT は送信前の待機時間を削減しますが、ゼロ時間でビジネス結果を受信することを意味するものではありません。RFC 9846：0-RTT とリプレイ防止

KeyUpdate：方向鍵を変更し、身份を再認証しない

接続確立後、KeyUpdate を使用してアプリケーショントラフィック秘密を進め、その後新しい key/IV でその方向の記録を保護し、規定に従って対向先に更新応答を要求します。これは証明書を再送信するものではなく、非対称鍵交換を再実行するものでもなく、すでに漏洩した現在の秘密が自動的にすべてのセキュリティを回復するものでもありません。

無効化された TLS renegotiation、ハンドシェイク後のクライアント認証、および KeyUpdate は異なるメカニズムです。アプリケーションが認証状態を更新する必要がある場合は、独自のライフサイクル内で設計すべきであり、「トラフィック鍵が変更された」ことをユーザー権限が再検証されたものと見なしてはいけません。

ECH：内側の ClientHello を保護し、すべてのメタデータを消滅させない

RFC 9849 は内外の ClientHello を定義しています。機密性の高い実際のパラメータは保護された内側に配置され、外部にはフロントエンド処理用の公開情報が提供されます。対応する秘密鍵を持つサーバーが内側を復号します。ECH が保護するのは裸の SNI フィールドだけでなく、受信確認、設定の有効期限切れ、および失敗時の再試行の処理も必要です。RFC 9849：ECH

クライアントはまず ECHConfigList を取得する必要があります。DNS SVCB/HTTPS の ech パラメータは標準的な誘導方法の1つであり、取得された設定の真正性とプライバシーも完全なデプロイメントの一部です。ドメイン名に HTTPS レコードが存在するだけで、必ずしも ECH が有効になっているわけではありません。RFC 9848：DNS 誘導 ECH

ECH は暗号化 DNS と組み合わせて名前を直接露出するのを減らしますが、目的の IP、外部の公開名、トラフィックサイズ、時間、およびサーバーログは依然として可視です。独占 IP もサイトを示唆する可能性があるため、「ユーザーがどのウェブサイトにアクセスしたかが完全に隠蔽された」と約束することはできません。

ローカル HKDF 検証と鍵導出の比較

import hashlib
import hmac
import struct

def extract(salt,ikm):
    return hmac.digest(salt,ikm,'sha256')
def expand(prk,info,length):
    previous,result = b'',b''
    for counter in range(1,(length+31)//32+1):
        previous = hmac.digest(prk,previous+info+bytes([counter]),'sha256')
        result += previous
    return result[:length]
def expand_label(secret,label,context,length):
    label = b'tls13 '+label
    info = struct.pack('!H',length)+bytes([len(label)])+label+bytes([len(context)])+context
    return expand(secret,info,length)
def derive(secret,label,messages):
    return expand_label(secret,label,hashlib.sha256(messages).digest(),32)

# RFC 5869 Appendix A.1、SHA256 テストベクトル。
ikm = bytes([11])*22
prk = extract(bytes.fromhex('000102030405060708090a0b0c'),ikm)
assert prk.hex()=='077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5'
assert expand(prk,bytes.fromhex('f0f1f2f3f4f5f6f7f8f9'),42).hex()==(
    '3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf'
    '34007208d5b887185865')
zero = bytes(32)
early = extract(zero,zero)
# RFC 8448 における PSK なしの early secret。
assert early.hex()=='33ad0a1c607ec03b09e6cd9893680ce210adf300aa1f2660e1b22e10f170f92a'
shared = bytes(range(32)) # 教学入力、実際の鍵交換結果ではない。
handshake = extract(derive(early,b'derived',b''),shared)
assert handshake != extract(early,shared)
main = extract(derive(handshake,b'derived',b''),zero)
client = derive(handshake,b'c hs traffic',b'hello transcript')
server = derive(handshake,b's hs traffic',b'hello transcript')
assert client!=server
assert len(expand_label(client,b'key',b'',16))==16
assert len(expand_label(client,b'iv',b'',12))==12
assert len(main)==32 and 1000+1+16+5==1022
print('HKDF 標準ベクトル、early secret、derived ステップ、記録オーバーヘッドのチェック通過')

この例は HKDF プリミティブと一部の派生関係を検証します。完全なトランスクリプト、証明書認証、実際の ECDHE/ECH、または TLS 相互運用性は実装されていません。公開テスト値は本番の秘密ではありません。RFC 8448：ハンドシェイクテスト材料

継続的な参照

• TLS 1.2 ハンドシェイク：PRF、CCS、およびセッション再開の比較。
• 証明書と PKI：証明書チェーンとサービス身元。
• mTLS と双方向認証：クライアント認証。
• UDP と QUIC：TLS ハンドシェイクと QUIC パケット保護の役割分担。