TLS 1.3 仕様

TLS 1.2 までの複雑な暗号方式を整理し、1-RTT ハンドシェイク、前方秘匿性、暗号化範囲拡大を標準化した TLS 改訂版。

RFC 8446。Record layer content type 22(handshake), 23(application_data), legacy_record_version 0x0303

TLS 1.3 本体に加え、PSK 専用認証、QUIC での利用、更新ドラフトを合わせて参照する。

RFC 8446 (TLS 1.3), RFC 8773 (certificate-less PSK), RFC 9001 (QUIC TLS), TLS 8446bis は更新案

renegotiation、static RSA 鍵交換、CBC モード、RC4、圧縮などを廃止し、AEAD と (EC)DHE/PSK ベースに整理した。

廃止: renegotiation / static RSA / CBC cipher suites / compression。Cipher suite から鍵交換と署名を分離

ServerHello 後に handshake traffic secret が導出され、EncryptedExtensions 以降の多くのハンドシェイクが暗号化される。

ClientHello/ServerHello は平文。EncryptedExtensions, Certificate, CertificateVerify, Finished は Handshake keys で保護

TLS 1.3 の平文レコード構造。Handshake はこの Record Layer に格納される。

RFC 8446 TLSPlaintext ASCII 図:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ContentType  |        Legacy Version         |    Length     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Length     |                 Fragment ...                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Fragment ...                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLS 1.3 の暗号化後レコード構造。外側 content type は application_data(23) として扱われる。

RFC 8446 TLSCiphertext ASCII 図:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Opaque Type  |        Legacy Version         |    Length     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Length     |             Encrypted Record ...              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Encrypted Record ...                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

全 Handshake メッセージに共通する 1B type + 3B length のヘッダ。

RFC 8446 Handshake ASCII 図:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   msg_type    |                    length                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          message ...                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

クライアントが supported_versions、cipher_suites、key_share、SNI、ALPN などを提示する最初のメッセージ。

HandshakeType=1。legacy_version=0x0303、random 32B、cipher_suites 可変長、extensions 可変長

サーバが TLS 1.3、cipher suite、key share を選択して返す。これにより共有鍵導出が始まる。

HandshakeType=2。selected_version は supported_versions extension 内。ServerHello.random 32B

クライアントの key_share がサーバ希望グループと合わない場合などに、追加の ClientHello を要求する。

ServerHello 形式で表現。random は固定値 CF 21 AD 74...。発火条件: key_share/group/cookie 再要求

証明書に紐づかないサーバ拡張を暗号化して送る。ALPN の選択結果などがここに入る。

HandshakeType=8。ServerHello 後、CertificateRequest/Certificate より前

サーバがクライアント証明書認証を要求する任意メッセージ。mTLS で利用される。

HandshakeType=13。certificate_request_context + extensions(signature_algorithms 等)

サーバまたはクライアントの証明書チェーンを送る。TLS 1.3 では証明書メッセージ自体も暗号化される。

HandshakeType=11。certificate_request_context + certificate_list

証明書の秘密鍵を保持していることを署名で証明する。Transcript Hash に文脈文字列を付けて署名する。

HandshakeType=15。signature_scheme + signature。RSA-PSS/ECDSA/EdDSA など

ハンドシェイク transcript の MAC を検証し、以降の Application Data 鍵へ進むための最終確認。

HandshakeType=20。verify_data = HMAC(finished_key, Transcript-Hash)

再開用 PSK と ticket 情報をサーバが発行する。0-RTT の可否や lifetime もここで通知される。

HandshakeType=4。ticket_lifetime, ticket_age_add, ticket_nonce, ticket, extensions(early_data)

アプリケーションデータ鍵を更新するメッセージ。長時間接続で鍵材料の使い過ぎを避ける。

HandshakeType=24。request_update: update_not_requested(0) / update_requested(1)

クライアントが 0-RTT Early Data の終了を示す。サーバが Early Data を受理した場合だけ送られる。

HandshakeType=5。Client Finished の前、0-RTT 受理時のみ

TLS 1.3 の必須実装 cipher suite。AES-GCM 128bit と SHA-256 HKDF を使う。

0x1301。AEAD_AES_128_GCM、Hash SHA-256。RFC 8446 Mandatory-to-Implement

AES-GCM 256bit と SHA-384 を使う高強度 suite。AES-NI などハードウェア支援環境で多用される。

0x1302。AEAD_AES_256_GCM、Hash SHA-384

AES ハードウェア支援が弱い端末で有利なことが多い AEAD suite。モバイルや ARM 環境で選択されやすい。

0x1303。AEAD_CHACHA20_POLY1305、Hash SHA-256。RFC 8439 AEAD

CCM を使う TLS 1.3 suite。組み込みや制約環境で利用されることがある。

0x1304。AEAD_AES_128_CCM、Hash SHA-256

CCM の 8 octet tag 版。タグが短いため一般 Web ではあまり選ばれない。

0x1305。AEAD_AES_128_CCM_8、Hash SHA-256

TLS 1.3 の通常接続では ECDHE による前方秘匿性が基本。X25519 と P-256 が広く使われる。

supported_groups: x25519(0x001d), secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019)

有限体 DH も利用可能だが、Web 実運用では ECDHE が主流。十分なビット長の named group を使う。

ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144, ffdhe8192

事前共有鍵またはセッションチケットから導出した PSK で接続を再開する。証明書なし PSK は RFC 8773 で扱われる。

pre_shared_key extension + binders。モード: psk_ke / psk_dhe_ke

PSK 再開に ECDHE を組み合わせ、再開接続でも前方秘匿性を維持する推奨モード。

psk_key_exchange_modes: psk_dhe_ke(1)。key_share も送信

再開時にクライアントが最初のフライトでアプリデータを送る。冪等でない処理には replay 攻撃リスクがある。

early_data extension。HTTP では GET 等に限定する設計が必要。replay safe でない POST は避ける

TLS 1.3 では RSA-PSS、ECDSA、EdDSA などを signature_algorithms で交渉する。

rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, ecdsa_secp256r1_sha256, ed25519(0x0807), ed448(0x0808)

TLS 1.3 extension の共通構造。extension_type と extension_data の長さで構成される。

RFC 8446 Extension ASCII 図:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Extension Type         |       Extension Length        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Extension Data ...                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

同一 IP 上の複数ホスト名に対応するため、ClientHello で接続先名を通知する。

server_name extension (type 0)。ECH 未使用時は平文 ClientHello に含まれる

TLS 上で使うアプリケーションプロトコルを交渉する。HTTP/2 や HTTP/3 の発見に重要。

application_layer_protocol_negotiation。例: h2, http/1.1。QUIC では h3

ClientHello で TLS 1.3 対応を示し、ServerHello で選択バージョンを返す。

extension type 43。TLS 1.3 は 0x0304、legacy_version は 0x0303

利用可能な鍵交換グループをクライアントが提示する。HelloRetryRequest の判断材料になる。

extension type 10。x25519, secp256r1, ffdhe2048 など

CertificateVerify と証明書チェーン検証で許容する署名方式を通知する。

extension type 13。RSA-PSS / ECDSA / Ed25519 / Ed448

ECDHE/DHE の公開鍵共有値を ClientHello と ServerHello に入れる。合わない場合は HelloRetryRequest になる。

extension type 51。KeyShareEntry: group + key_exchange<1..2^16-1>

セッション再開と PSK 利用に必要な拡張。pre_shared_key は ClientHello の最後の拡張に置く制約がある。

pre_shared_key type 41、psk_key_exchange_modes type 45。binder 検証あり

early_data は 0-RTT 利用可否、cookie は HelloRetryRequest でクライアント到達性確認などに使う。

early_data type 42。cookie type 44。QUIC では Retry/トークンとも運用上関連

古い中間装置が TLS 1.3 を誤認しないよう、互換目的の ChangeCipherSpec を送る実装がある。

fake ChangeCipherSpec: content type 20, payload 0x01。暗号状態は変更しない

TLS 1.3 の ALPN、cipher、証明書チェーン、早期データ可否を切り分けるときに使う。

openssl s_client -connect example.com:443 -tls1_3 -alpn h2 -servername example.com

TLS 1.3 非対応のプロキシ、古いロードバランサ、SNI/ALPN 欠落、証明書署名アルゴリズム不一致で失敗することがある。

確認: curl -v --tlsv1.3 --http2、openssl s_client、サーバ cipher/curve/signature 設定

0-RTT は明示的に制御し、古い TLS バージョンや弱い署名方式を無効化し、証明書自動更新と OCSP/CRL 監視を行う。

推奨: TLS 1.2/1.3 のみ、RSA-PSS/ECDSA/EdDSA、ECDHE、AEAD、0-RTT は replay-safe API のみ