图解

图解后量子 TLS 1.3 连接

这是一次真实的 TLS 1.3 握手，从网络上抓取后逐字节拆解。双方用 X25519MLKEM768 协商密钥，它是后量子 ML-KEM-768 与经典 X25519 的混合方案，因此即使攻击者今天录下这次会话、日后攻破椭圆曲线，会话内容依然保密。下方的每个数值都根据抓取的字节重新计算，并与 OpenSSL 记录的内容核对；没有任何仅作示意的数据。

本次会话的一次性密钥

只有知道握手的秘密值，才能复现这次握手，所以本演示公开了这些值。这里的每个值都是这一次会话的一次性秘密值，专为这次抓包生成，之后不再使用——公开它们不会泄露任何其他连接的信息。正是有了它们，本页面和你才能重新计算下方的每一步。

ML-KEM 密钥生成种子 d ‖ z（64 字节）: 84745c7adf177dfb94e15c7cdef6f8006897b295bdafaadd090ef050c004b212921eb10b6b41e8f0221e0f7f164aadef44f4cba1139edd522c9f0860db6b0cde
客户端 X25519 私钥（混合密钥共享）: 784edfa4400a57540a7cbd71957c8ab182ae801a5c519755abe69f553b9e8c5d
客户端 X25519 私钥（独立密钥共享）: d81df8305a5f24f9077b3d669885d0d7b93ec55fe405ccde814bac62e778f656
ML-KEM 封装随机数 m（32 字节）: 4888d955ca1924fb19e233b6d516249f84e945e1d8345e9816b7fbaa2c3632b7
服务器 X25519 私钥: c81c64cbae9dc5549313f148f09f00da5f8fde45be679697e02204a781796145
服务器证书的私钥标量（P-256）: 11aa8fac7486c821d6c57baa03c3a3e119a635f33aaa2043bba12d7f20a40a99

混合密钥共享的结构

迁移到后量子的全部开销都集中在两个字段中。X25519MLKEM768 将一个 ML-KEM-768 值和一个 X25519 值拼接在一起，在这个组中 ML-KEM 在前（RFC 10024 §4）：客户端在一个密钥共享（key share）中同时提供两者，服务器也同时用两者应答，共享密钥的两个 32 字节部分也按同样的方式拼接。

客户端密钥共享——1216 字节

ML-KEM-768 · 1184 字节

X25519 · 32 字节

服务器密钥共享——1120 字节

ML-KEM-768 · 1088 字节

X25519 · 32 字节

共享密钥——64 字节

ML-KEM-768 · 32 字节

X25519 · 32 字节

后量子在传输上的开销

同一对客户端和服务器又用纯 X25519 协商了第二次握手，其他条件完全相同。混合密钥材料在每个方向上都多出一千多字节，这是唯一真正的开销：它让 ClientHello 超出了单个数据包的大小。

测量项	X25519MLKEM768	X25519	差值
ClientHello（整条记录）	1,483 字节	261 字节	+1,222 字节
key_share 扩展（客户端）	1,262 字节	42 字节	+1,220 字节
supported_groups 扩展	22 字节	20 字节	+2 字节
ServerHello（整条记录）	1,215 字节	127 字节	+1,088 字节
key_share 扩展（服务器）	1,128 字节	40 字节	+1,088 字节
客户端发送的字节数	1,620 字节	398 字节	+1,222 字节
服务器发送的字节数	2,326 字节	1,236 字节	+1,090 字节
ClientHello 占用的 TCP 报文段	2 个数据包	1 个数据包	+1 个数据包

客户端 → 服务器记录 1 · 传输大小 1,483 字节

ClientHello

客户端发起连接：提议使用 TLS 1.3，提供三个 AES/ChaCha 密码套件，列出所支持的密钥交换组（X25519MLKEM768 排在首位），并为最优先的两个组各发送一个密钥共享——其中包括 1216 字节的混合密钥共享。这条消息以明文传输；此时还没有任何内容是保密的。

网络传输数据 · 1,483 字节

这 1,478 字节与 OpenSSL 用 -msg 为该记录打印的内容一致。

计算方式客户端的密钥共享

在发出任何消息之前，客户端先生成它要提供的临时密钥。对于混合组，这是一个 ML-KEM-768 密钥对加上一个 X25519 密钥对，两者的公钥拼接成一个 1216 字节的密钥共享；独立的 X25519 组则有自己单独的密钥。

定义

d, z     ←$ B^32                                   FIPS 203 §7.1
(ek, dk) = ML-KEM-768.KeyGen_internal(d, z)        FIPS 203 §6.1
x_c      ←$ B^32,   X_c = X25519(x_c, 9)           RFC 7748 §5
share    = ek ‖ X_c                                1184 + 32 = 1216   RFC 10024 §4.1

y_c      ←$ B^32,   Y_c = X25519(y_c, 9)           key_share: x25519 (0x001d)

本次会话中的值

d（32 字节）——扩展为秘密向量: 84745c7adf177dfb94e15c7cdef6f8006897b295bdafaadd090ef050c004b212
z（32 字节）——隐式拒绝秘密值: 921eb10b6b41e8f0221e0f7f164aadef44f4cba1139edd522c9f0860db6b0cde
1184 字节封装密钥的 SHA-256: 4a2903bee32a7a18d3294d93a4d24d6ecc8c07bc098bab31899689f87a572be8
客户端 X25519 私钥（混合密钥共享）: 784edfa4400a57540a7cbd71957c8ab182ae801a5c519755abe69f553b9e8c5d
客户端 X25519 公钥（混合密钥共享）: 09e0802926363ed192b02f5261520f2056ba7af9a0acd1eee5bbe50181e0cf29
客户端 X25519 私钥（独立密钥共享）: d81df8305a5f24f9077b3d669885d0d7b93ec55fe405ccde814bac62e778f656
客户端 X25519 公钥（独立密钥共享）: 67aab4deeec206fa89034014d772bdd47cedd7930610e81f634871565424f14d

这证明了什么

用种子执行 ML-KEM-768 密钥生成，得到的封装密钥与客户端密钥共享中的一致。
封装密钥的全部 768 个系数都小于 q = 3329（最大为 3326），因此服务器接受该密钥（FIPS 203 §7.2）。
由该 X25519 私钥算出的公开值与客户端混合密钥共享中的一致。
独立的 X25519 密钥共享使用自己的密钥，与混合密钥共享中的不同。

手动复现

printf '%s' 3054020100300b06096086480165030404020442804084745c7adf177dfb94e15c7cdef6f8006897b295bdafaadd090ef050c004b212921eb10b6b41e8f0221e0f7f164aadef44f4cba1139edd522c9f0860db6b0cde | unhex > client-mlkem.der
openssl pkey -inform DER -in client-mlkem.der -pubout -outform DER | tail -c 1184 | openssl dgst -sha256 -binary | tohex

输出 4a2903bee32a7a18d3294d93a4d24d6ecc8c07bc098bab31899689f87a572be8

printf '%s' 302e020100300506032b656e04220420784edfa4400a57540a7cbd71957c8ab182ae801a5c519755abe69f553b9e8c5d | unhex > x25519.der
openssl pkey -inform DER -in x25519.der -pubout -outform DER | tail -c 32 | tohex

输出 09e0802926363ed192b02f5261520f2056ba7af9a0acd1eee5bbe50181e0cf29

服务器 → 客户端记录 2 · 传输大小 1,215 字节

ServerHello

服务器选定 TLS 1.3、密码套件 TLS_AES_128_GCM_SHA256 和组 X25519MLKEM768，并返回自己的 1120 字节混合密钥共享。这是最后一条明文消息：从这里开始，双方都能计算出握手密钥，之后的所有内容都经过加密。

网络传输数据 · 1,215 字节

这 1,210 字节与 OpenSSL 用 -msg 为该记录打印的内容一致。
OpenSSL 的 s_client 报告协商的组为 X25519MLKEM768。
OpenSSL 的 s_client 报告的加密算法为 TLS_AES_128_GCM_SHA256。

计算方式服务器的密钥共享

服务器并没有可以拿来做乘法的对应私钥——ML-KEM 是 KEM，不是 Diffie-Hellman。服务器用客户端的 ML-KEM 密钥封装一个新的秘密值，得到密文和后量子共享密钥，同时生成自己的 X25519 密钥。它的密钥共享由密文和其后的 X25519 公开值组成。

定义

m      ←$ B^32
(K, c) = ML-KEM-768.Encaps_internal(ek, m)         FIPS 203 §6.2
x_s    ←$ B^32,   X_s = X25519(x_s, 9)             RFC 7748 §5
share  = c ‖ X_s                                   1088 + 32 = 1120   RFC 10024 §4.2

本次会话中的值

ML-KEM 封装随机数 m（32 字节）: 4888d955ca1924fb19e233b6d516249f84e945e1d8345e9816b7fbaa2c3632b7
ML-KEM 共享密钥 K（32 字节）: dad26963f7510c64b7c7d9b80731d6b573abf15999f5bed3076173e3f8c0cbdb
1088 字节 ML-KEM 密文的 SHA-256: 30d5f4e26e8548b8796088ef0d56d307cab52802ab03e3cea966cb1391dbfc2a
服务器 X25519 私钥: c81c64cbae9dc5549313f148f09f00da5f8fde45be679697e02204a781796145
服务器 X25519 公钥: 339fdc7e19b200cb062df86bdf0e022c949abacd7db8dbdae0a92a6d9ba8d530

这证明了什么

用记录下来的随机数对客户端的密钥执行封装，得到的密文与服务器的一致。
由服务器的 X25519 私钥算出的公开值与其密钥共享中的一致。

计算方式共享密钥

现在双方都能得到相同的 64 字节。客户端用其 ML-KEM 私钥对密文解封装，双方完成 X25519 交换，再把两个 32 字节的结果拼接起来——ML-KEM 在前。攻击者必须同时攻破这两半才能恢复出共享密钥，这正是混合方案的意义所在。

定义

K  = ML-KEM-768.Decaps(dk, c)                      FIPS 203 §7.3
Z  = X25519(x_c, X_s) = X25519(x_s, X_c)           RFC 7748 §6.1
ss = K ‖ Z                                         32 + 32 = 64   RFC 10024 §4.3

本次会话中的值

ML-KEM 共享密钥 K（32 字节）: dad26963f7510c64b7c7d9b80731d6b573abf15999f5bed3076173e3f8c0cbdb
X25519 共享密钥 Z（32 字节）: 568c3055b3ac3516f0d780bbe022beb336ade7e7bae81752f2de6df09ebdc428
共享密钥 = K ‖ Z（64 字节）: dad26963f7510c64b7c7d9b80731d6b573abf15999f5bed3076173e3f8c0cbdb568c3055b3ac3516f0d780bbe022beb336ade7e7bae81752f2de6df09ebdc428

这证明了什么

客户端的解封装与服务器的封装得到相同的 ML-KEM 秘密值。
双方计算出相同的 X25519 秘密值。
X25519 秘密值不全为零，符合 RFC 9846 §7.4.2 的要求。
共享密钥的前 32 字节是 ML-KEM 秘密值，这正是 RFC 10024 §4.3 规定的顺序。

手动复现

printf '%s' 3054020100300b06096086480165030404020442804084745c7adf177dfb94e15c7cdef6f8006897b295bdafaadd090ef050c004b212921eb10b6b41e8f0221e0f7f164aadef44f4cba1139edd522c9f0860db6b0cde | unhex > client-mlkem.der
unhex > ciphertext.bin <<'EOF'
5db0e57cb763af0d1678753192830257df14de0eb4dd0d9a2d7ee2a7c94f4aab
2526fd0957b0c1025efff1763488c3bff22007fdd19b33a0e5605fc2b50ed3aa
adee4643eaa746cc65882d54a49ce4cb208226f6c732dc39981d81de9b788740
f6361120dc130f814bf5dd41d4df8682468e8ec8e2b3d5056cf245df0e0febe7
cf7423f725533dc39210093d57134c0e86a716d6d62694c9548082a5cd9352f2
fb8254397df2921d3a48702df9f622a7a539ba6110bec4736b6d15e38c558105
d6954e5fe1aec5b5ae065222fe1df4b1639e001695dcfba2d0aa09d14f9fee31
201383e58a16709631cb7b182ffbae8dc4e1345afd1763e55bb0714e92470c53
805f05ace3ce45402563cfd08db5429ffe5eeb033a7695530ee01ab7c5a179b1
1e3cd17082f457a158861fda8a9c08e7987dc5e18a48955ddba38766e14e09c3
b6319dbb5cb7c6c8e4aad9d40c2ec2b69e8ab793f742765d2af2644afc87cc1f
add8e0dc76f9725dfb9063f116ef8b02c7dc949160e22d716cfe1bed9a7eccae
e26ebc9615fd2c6e53a93bf97db63bbcae24bff5082a83dd2128fec9297cf449
2811d09363a21e98ac4869512ede9300c3fe5f049d7348404c56c37e1329fbbe
90fa854ef8b4de86c67bd16c4263f5eb99a50939a80086c9a1c0d038343d8c9e
d8b9300a6556d950492925628fb281cd077c82681f75e7aae144617adf613f49
11ff6e8f4246039f2ace861f2b2ec1d0f555e3e1a7fce9c80c6c2a8a062d0a64
7be31fc4b42c8776cd4b6517c4aa939a398b110c052e30a8eb746c476ee0dfc8
8866fbd8fdc816d20add8dbfeabcac6e0dac0f41a4e4822ab1f51b54e4bc178f
4eb7c07670704e425fd99205b8efd2f3fbccb200760127b1188fab5d7be84b06
87d779bfbe63e3b1db13f34ab9205d9f06312046e77737a05c070f1b808b5c80
9aa9e9945c52e4bf46d5b328030b42dbfba641cc0a39e6ace09361371d25fb3e
e78507a6fadfc2b6cd4a06851488b001d8b40a1ceb647b7d9debcbff6c375a13
73540d114e9bca1377b83192209bdb70824784b23da425bc7c8cca3ba0845d14
45e732d4e2327348f3a1d1f2499753bd5786ef80ef9a47c7293eedeef64d21ef
4ec47e847303fb963deff2f873efc8f2cfef263bdc40c34cb9aa80584e1ffd03
efe811cd6e12e4e6cdbda8a1ddc2df5f8f86462311425bae494f087f28524721
43e8bf6f53fb68f6063961b07dd34b0a4ebb4aba6b0f989f5955c4fe10088cae
6f7531a6b699f9e9dd34b2fc3ae102409bc97775b7bdc1e0028042e7c27fb8ed
c43c611b3ffd91de6a08a44700dd9b2d241488710e7cfabf974db0fd8a8f9b68
fee885b69d2cac23f6531af4f69c6f58e0d1ce620c47578c0bf4d3f3435df6ba
67556efaa65ec7bb518c76e840747c8454d0538f36134ee8beb0bd24a616a42d
fc826926ff9608def9b1c433d6e9ad8fcf1e11543a9595795f69c6630b60f581
156d98ce7e53124ceb06ce7e6e8054c6849aa2039b96cde7f9eac19b036b44a7
EOF
openssl pkeyutl -decap -inkey client-mlkem.der -keyform DER -in ciphertext.bin -secret mlkem-secret.bin
tohex < mlkem-secret.bin

输出 dad26963f7510c64b7c7d9b80731d6b573abf15999f5bed3076173e3f8c0cbdb

printf '%s' 302e020100300506032b656e04220420784edfa4400a57540a7cbd71957c8ab182ae801a5c519755abe69f553b9e8c5d | unhex > own.der
printf '%s' 302a300506032b656e032100339fdc7e19b200cb062df86bdf0e022c949abacd7db8dbdae0a92a6d9ba8d530 | unhex > peer.der
openssl pkeyutl -derive -inkey own.der -keyform DER -peerkey peer.der -peerform DER | tohex

输出 568c3055b3ac3516f0d780bbe022beb336ade7e7bae81752f2de6df09ebdc428

计算方式握手流量秘密值

共享密钥作为 TLS 1.3 密钥调度的输入（RFC 9846 §7.1）：这是由一系列 HKDF-Extract 和 Derive-Secret 步骤组成的链条。没有预共享密钥时，早期秘密值是对全零输入执行 HKDF-Extract 的结果；再混入共享密钥，就得到握手秘密值，客户端和服务器的握手流量秘密值都由它结合 ClientHello…ServerHello 的握手消息派生而来。

定义

early_secret     = HKDF-Extract(salt = 0, IKM = 0)            0 = 00 × 32
derived          = Derive-Secret(early_secret, "derived", "")
handshake_secret = HKDF-Extract(salt = derived, IKM = K ‖ Z)
c_hs_traffic     = Derive-Secret(handshake_secret, "c hs traffic", ClientHello ‖ ServerHello)
s_hs_traffic     = Derive-Secret(handshake_secret, "s hs traffic", ClientHello ‖ ServerHello)

Derive-Secret(S, label, M)        = HKDF-Expand-Label(S, label, SHA-256(M), 32)
HKDF-Expand-Label(S, label, C, n) = HKDF-Expand(S, HkdfLabel, n)
HkdfLabel = uint16(n) ‖ uint8(6 + |label|) ‖ "tls13 " ‖ label ‖ uint8(|C|) ‖ C

本次会话中的值

early_secret = HKDF-Extract(0, 0): 33ad0a1c607ec03b09e6cd9893680ce210adf300aa1f2660e1b22e10f170f92a
SHA-256("")——空上下文的哈希: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
派生秘密值: 6f2615a108c702c5678f54fc9dbab69716c076189c48250cebeac3576c3611ba
handshake_secret: 06b849eff15c46a4401e154110a2e63a14f7333237260156f7f1b67ca3305198
SHA-256(ClientHello ‖ ServerHello): 0da9cb1015db6852c07fbdc2389ad83ee8b1898a147932620753ce82d3c0709c
用于“c hs traffic”的 HkdfLabel: 002012746c73313320632068732074726166666963200da9cb1015db6852c07fbdc2389ad83ee8b1898a147932620753ce82d3c0709c
client_handshake_traffic_secret: 8b0beea15604895fd4408c32b82684d347fa5e2422644c1d93978db70666f623
server_handshake_traffic_secret: 46925f99fa426e5dc105f5eaccfca048e1e89a93370b07cb9ab447518eb8f47f

这证明了什么

与两个 SSLKEYLOGFILE 中的 CLIENT_HANDSHAKE_TRAFFIC_SECRET 行一致。
与两个 SSLKEYLOGFILE 中的 SERVER_HANDSHAKE_TRAFFIC_SECRET 行一致。

手动复现

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXTRACT_ONLY \
  -kdfopt hexsalt:0000000000000000000000000000000000000000000000000000000000000000 \
  -kdfopt hexkey:0000000000000000000000000000000000000000000000000000000000000000 \
  HKDF | tohex

输出 33ad0a1c607ec03b09e6cd9893680ce210adf300aa1f2660e1b22e10f170f92a

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:33ad0a1c607ec03b09e6cd9893680ce210adf300aa1f2660e1b22e10f170f92a \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:derived' \
  -kdfopt hexdata:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 \
  TLS13-KDF | tohex

输出 6f2615a108c702c5678f54fc9dbab69716c076189c48250cebeac3576c3611ba

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXTRACT_ONLY \
  -kdfopt hexsalt:6f2615a108c702c5678f54fc9dbab69716c076189c48250cebeac3576c3611ba \
  -kdfopt hexkey:dad26963f7510c64b7c7d9b80731d6b573abf15999f5bed3076173e3f8c0cbdb568c3055b3ac3516f0d780bbe022beb336ade7e7bae81752f2de6df09ebdc428 \
  HKDF | tohex

输出 06b849eff15c46a4401e154110a2e63a14f7333237260156f7f1b67ca3305198

unhex <<'EOF' | openssl dgst -sha256 -binary | tohex
010005c2030398fd30aaaf1617a1d20cc42c00c775d798dbaba001b1ae95ca6b
039f1e1fbbd7202bfbccd3b1cde003314afdea3e30508dd784674df104782760
5aeaca811f310d00061302130313010100057300000013001100000e70712d74
6c732e6578616d706c65000b000403000102000a0012001011ec001d0017001e
0018001901000101002300000016000000170000000d002a0028090509060904
04030503060308070808081a081b081c0809080a080b08040805080604010501
0601002b0003020304002d00020101003304ea04e811ec04c064180ac1469cd6
5bc990ebc8e4b7a5bf643e3a709d3f543a187c20c7aa082a02aecd74cb814452
7f8606b7a846953ca9f657ae6a7c7463f22ae0e44589139450d20b0311c7ca93
4a8898abde41c22c20b0367875bb8191d086a6a4141a6e4630d2588642d040c2
a73f8c82c8d6776a196c39f9066e9807a7b62b7745c12b6b04c2c2a0b235f889
8e16a1db48bdea02b66744b2e844b78a98a6796a10d2ab03143943f7d32286fc
8e78047854d555956c7db02079cbac0289cc60e345ceac998f7e4157b646c870
72627627076649b7b0ac7cc60294abe1229b42c4e8f9041d4b76268234550079
81ea36d3f62fc52382eec77f3796513b91a9a56ab1675466486475ebc287ac08
91185b37d1b36b31735a5d647b02481f0c1937dab04e3c956e15e69f89e83fb8
db43a428ab9d97a41e077e91a7b6ba26a350255c20b7a9791283aa5a181b8560
1b7971d993bcb698cd4dab1a92e8657b4329fad22705876904e2bd6ef5469cf8
a9c5674178d2b94d9065491b8fa530018bf15e0a1a17fefc67be14b07a755a80
5b650319025fc72c39b93141051ada437d154712647624b893be82f48ed0632d
a6317df11c56c14835b6d42b5a405f7eca9770675710b545e4f21cec18b139d7
b91a578a0416641f291950e5493cd170f7c8a4273a13bef81215bba72dc214d8
958db49a2004487aef97a672454758dc82f78704762c5264d596d9d38ce4589d
0f549710383924b16365596e2d6100cbc54e2eec665c572d13508b693c61445b
a7ea4b9a6a053c0c89ad955b43e8c035cb7130f6e85063d20e6f8652f592c069
02bedd0209ea14c79f9a902ee62a5a0b5f295779f1946a49b782bac2781b4922
354ca674a99b51d999e784659890acb2569dcc34aadcc51e52a637fea85dfc02
214d796fc64b424034cfa1e40cb114733e0c66fd4c990174c4dfe02d92e8b002
cc75d7597fb6ab5c27824c738c2bb3a239e2726ed9bc8cdecc944c992c9d3044
05493ff537a8d04632b3d3c0dca8ab98428cdd9184455455e7294d772c126e08
aa925c92c2660985b811ca041b7997646d909fe1671c83cccfbf2c49c7086587
d6beeb65a9596406bc95a88d7aa09ec58cc6c1b37366cd4d7c9ed49c90903995
f098412f1abfe1516ab63866b1a86d5f939691bb4dcff85c0cd62ada4c553c10
129e33b14f45a9794990f1501710c485b4c19370e1ca7d4326b092b12280316b
c76267957d5f48210a5baccb81a5d1fc985a77c8dc156fef1188d83616104623
1fe9352a16c8f2262946f3ca9015cb27e26e07052d19d7565e9623e1182cc2f0
67854708c921bd9f52852b810505b577146b31a2acb909440cfb2730e0ea520c
828b2b30c1d3c115700504a518ab05bac15c4a6fd634977748c6b0283b01784f
23179277199d1f399d66d5c2a3636d905a05b625a8e69686b43b166f635510e4
2dba6996bf10bdb0f2afea9ca9e9e8b1c41b012ed735d7646998d051f7124989
c29f3da18334ec22b5a47eea9c13fa9ac1d4e7bf9c1899abd96831f323bcd6ab
2d4caf33e86afeb475f7db256fd56da6c1367ce33a91260443e22573221f4295
3a4517046a2a951b9b41afdca2d156b5cb2c876ab032102392b02d7f437802dd
17ef543d6612ef4856f5558c2dddea2dde270fdab179bdb25309e0802926363e
d192b02f5261520f2056ba7af9a0acd1eee5bbe50181e0cf29001d002067aab4
deeec206fa89034014d772bdd47cedd7930610e81f634871565424f14d001b00
050400010003020004b60303498497776391725d59356de785c94cedb9c5def8
704f1426dfa548c1b589437f202bfbccd3b1cde003314afdea3e30508dd78467
4df1047827605aeaca811f310d130100046e002b000203040033046411ec0460
5db0e57cb763af0d1678753192830257df14de0eb4dd0d9a2d7ee2a7c94f4aab
2526fd0957b0c1025efff1763488c3bff22007fdd19b33a0e5605fc2b50ed3aa
adee4643eaa746cc65882d54a49ce4cb208226f6c732dc39981d81de9b788740
f6361120dc130f814bf5dd41d4df8682468e8ec8e2b3d5056cf245df0e0febe7
cf7423f725533dc39210093d57134c0e86a716d6d62694c9548082a5cd9352f2
fb8254397df2921d3a48702df9f622a7a539ba6110bec4736b6d15e38c558105
d6954e5fe1aec5b5ae065222fe1df4b1639e001695dcfba2d0aa09d14f9fee31
201383e58a16709631cb7b182ffbae8dc4e1345afd1763e55bb0714e92470c53
805f05ace3ce45402563cfd08db5429ffe5eeb033a7695530ee01ab7c5a179b1
1e3cd17082f457a158861fda8a9c08e7987dc5e18a48955ddba38766e14e09c3
b6319dbb5cb7c6c8e4aad9d40c2ec2b69e8ab793f742765d2af2644afc87cc1f
add8e0dc76f9725dfb9063f116ef8b02c7dc949160e22d716cfe1bed9a7eccae
e26ebc9615fd2c6e53a93bf97db63bbcae24bff5082a83dd2128fec9297cf449
2811d09363a21e98ac4869512ede9300c3fe5f049d7348404c56c37e1329fbbe
90fa854ef8b4de86c67bd16c4263f5eb99a50939a80086c9a1c0d038343d8c9e
d8b9300a6556d950492925628fb281cd077c82681f75e7aae144617adf613f49
11ff6e8f4246039f2ace861f2b2ec1d0f555e3e1a7fce9c80c6c2a8a062d0a64
7be31fc4b42c8776cd4b6517c4aa939a398b110c052e30a8eb746c476ee0dfc8
8866fbd8fdc816d20add8dbfeabcac6e0dac0f41a4e4822ab1f51b54e4bc178f
4eb7c07670704e425fd99205b8efd2f3fbccb200760127b1188fab5d7be84b06
87d779bfbe63e3b1db13f34ab9205d9f06312046e77737a05c070f1b808b5c80
9aa9e9945c52e4bf46d5b328030b42dbfba641cc0a39e6ace09361371d25fb3e
e78507a6fadfc2b6cd4a06851488b001d8b40a1ceb647b7d9debcbff6c375a13
73540d114e9bca1377b83192209bdb70824784b23da425bc7c8cca3ba0845d14
45e732d4e2327348f3a1d1f2499753bd5786ef80ef9a47c7293eedeef64d21ef
4ec47e847303fb963deff2f873efc8f2cfef263bdc40c34cb9aa80584e1ffd03
efe811cd6e12e4e6cdbda8a1ddc2df5f8f86462311425bae494f087f28524721
43e8bf6f53fb68f6063961b07dd34b0a4ebb4aba6b0f989f5955c4fe10088cae
6f7531a6b699f9e9dd34b2fc3ae102409bc97775b7bdc1e0028042e7c27fb8ed
c43c611b3ffd91de6a08a44700dd9b2d241488710e7cfabf974db0fd8a8f9b68
fee885b69d2cac23f6531af4f69c6f58e0d1ce620c47578c0bf4d3f3435df6ba
67556efaa65ec7bb518c76e840747c8454d0538f36134ee8beb0bd24a616a42d
fc826926ff9608def9b1c433d6e9ad8fcf1e11543a9595795f69c6630b60f581
156d98ce7e53124ceb06ce7e6e8054c6849aa2039b96cde7f9eac19b036b44a7
339fdc7e19b200cb062df86bdf0e022c949abacd7db8dbdae0a92a6d9ba8d530
EOF

输出 0da9cb1015db6852c07fbdc2389ad83ee8b1898a147932620753ce82d3c0709c

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:06b849eff15c46a4401e154110a2e63a14f7333237260156f7f1b67ca3305198 \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:c hs traffic' \
  -kdfopt hexdata:0da9cb1015db6852c07fbdc2389ad83ee8b1898a147932620753ce82d3c0709c \
  TLS13-KDF | tohex

输出 8b0beea15604895fd4408c32b82684d347fa5e2422644c1d93978db70666f623

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:06b849eff15c46a4401e154110a2e63a14f7333237260156f7f1b67ca3305198 \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:s hs traffic' \
  -kdfopt hexdata:0da9cb1015db6852c07fbdc2389ad83ee8b1898a147932620753ce82d3c0709c \
  TLS13-KDF | tohex

输出 46925f99fa426e5dc105f5eaccfca048e1e89a93370b07cb9ab447518eb8f47f

计算方式握手记录密钥

每个流量秘密值都通过 HKDF-Expand-Label 扩展为一个 AES-128-GCM 密钥和一个 12 字节的 write_iv。从 EncryptedExtensions 开始的每条握手记录都用它们解密；逐记录 nonce 是 write_iv 与该记录序列号的异或。

定义

write_key = HKDF-Expand-Label(traffic_secret, "key", "", 16)     AES-128-GCM   RFC 9846 §7.3
write_iv  = HKDF-Expand-Label(traffic_secret, "iv",  "", 12)
nonce     = write_iv XOR uint96(seq)                             RFC 9846 §5.3

本次会话中的值

用于“key”的 HkdfLabel: 001009746c733133206b657900
服务器握手密钥（AES-128）: 5ed29e03b3495fd20354ed3f2421640a
服务器握手 write_iv: e465385b2d22f07ffc6a4079
客户端握手密钥（AES-128）: 96fa01469d090b2a8f4ef6b9fa5e0784
客户端握手 write_iv: 9f45d2e464131048897a81c6

这证明了什么

手动复现

openssl kdf -binary -keylen 16 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:46925f99fa426e5dc105f5eaccfca048e1e89a93370b07cb9ab447518eb8f47f \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:key' \
  TLS13-KDF | tohex

输出 5ed29e03b3495fd20354ed3f2421640a

openssl kdf -binary -keylen 12 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:46925f99fa426e5dc105f5eaccfca048e1e89a93370b07cb9ab447518eb8f47f \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:iv' \
  TLS13-KDF | tohex

输出 e465385b2d22f07ffc6a4079

openssl kdf -binary -keylen 16 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:8b0beea15604895fd4408c32b82684d347fa5e2422644c1d93978db70666f623 \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:key' \
  TLS13-KDF | tohex

输出 96fa01469d090b2a8f4ef6b9fa5e0784

openssl kdf -binary -keylen 12 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:8b0beea15604895fd4408c32b82684d347fa5e2422644c1d93978db70666f623 \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:iv' \
  TLS13-KDF | tohex

输出 9f45d2e464131048897a81c6

服务器 → 客户端记录 3 · 传输大小 6 字节

ChangeCipherSpec

一个不起任何作用的 0x01 字节。TLS 1.3 保留它，只是为了让握手在中间设备看来像 TLS 1.2，否则这些设备会断开连接（RFC 9846 附录 E.4）。

网络传输数据 · 6 字节

这 1 字节与 OpenSSL 用 -msg 为该记录打印的内容一致。

服务器 → 客户端记录 4 · 传输大小 28 字节

EncryptedExtensions

第一条加密消息：服务器发送的、建立密钥时用不到的扩展。这里没有这样的扩展，所以消息为空——但它已经受到服务器握手密钥的保护，这证明密钥调度工作正常。

记录保护

这是一条携带加密数据的 application_data 记录。它使用服务器握手流量密钥和下方的逐记录 nonce，以 AES-128-GCM 解密；验证 16 字节的认证标签时，5 字节的记录头作为附加数据参与计算（RFC 9846 §5.2）。

AES-128-GCM 密钥write_key: 5ed29e03b3495fd20354ed3f2421640a
初始化向量write_iv: e465385b2d22f07ffc6a4079
序列号 0 的 noncenonce: e465385b2d22f07ffc6a4079
附加数据：记录头additional_data: 1703030017
认证标签tag: 55c0c9b55b240c731db30884422ef691

GCM 标签验证通过：该记录在序列号 0 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 6 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 28 字节

解密后的内容 · 7 字节

服务器 → 客户端记录 5 · 传输大小 524 字节

Certificate

服务器的证书链——这里只有一张 ECDSA P-256 证书——用握手密钥加密。本页面将它一直解析到公钥的两个坐标，并验证演示 CA 对它的签名。

记录保护

AES-128-GCM 密钥write_key: 5ed29e03b3495fd20354ed3f2421640a
初始化向量write_iv: e465385b2d22f07ffc6a4079
序列号 1 的 noncenonce: e465385b2d22f07ffc6a4078
附加数据：记录头additional_data: 1703030207
认证标签tag: 01e58b85a9daa69fa78913be25313b55

GCM 标签验证通过：该记录在序列号 1 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 502 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 524 字节

解密后的内容 · 503 字节

计算方式证书链

服务器的身份建立在一条普通的签名链之上。演示 CA 对服务器证书的 tbsCertificate 字节签了名；用 CA 的公钥验证这个签名——并检查名称和有效期——就是 OpenSSL 输出的“Verification: OK”所代表的含义。

定义

e     = SHA-256(tbsCertificate)
valid = ECDSA-P256-Verify(Q_CA, e, (r, s))         ecdsa-with-SHA256   RFC 5758 §3.2

本次会话中的值

演示 CA 公钥（P-256 未压缩点）: 04136596262dfe32c00a117a326530235df0416dcfb8300ac1e76b4ceaa7c3417ab65dbcce2950dc2616c49bea9c842dcc4f7d2fe1a2157adc6e4900e72b78cf64
SHA-256(tbsCertificate): 68ec291c24ed1fc272a0439a31cd0d28307258ca08f3cc67bde7fa115516e293
签名值 r: 5f1c8dec01971b89bab6c887166550128ee211099c2ecbe17c0efd5d1c2d5e71
签名值 s: 323909f5ef7bb5a0743701eccfbe4ffbc7fdfefbd12d33733c05541d8d87c86b

这证明了什么

证书签名经 CA（O=ecdsa.com, CN=Illustrated PQ TLS Demo CA）验证通过。
CA 证书由 O=ecdsa.com, CN=Illustrated PQ TLS Demo CA 自签名。
Certificate 消息中的证书与抓包记录的证书逐字节一致。
证书的 subjectAltName 涵盖 pq-tls.example。
抓包时间 2026-10-20T11:32:29Z 在证书有效期内。
OpenSSL 的 s_client 报告了“Verification: OK”以及已验证的对端名称。

手动复现

cat > ca.pem <<'EOF'
-----BEGIN CERTIFICATE-----
MIIBtjCCAVygAwIBAgIUPfq2HpUguo3lvTcCMSTFcL+tV1swCgYIKoZIzj0EAwIw
OTESMBAGA1UECgwJZWNkc2EuY29tMSMwIQYDVQQDDBpJbGx1c3RyYXRlZCBQUSBU
TFMgRGVtbyBDQTAeFw0yNjEwMjAxMTMyMjlaFw0yNzEwMjAxMTMyMjlaMDkxEjAQ
BgNVBAoMCWVjZHNhLmNvbTEjMCEGA1UEAwwaSWxsdXN0cmF0ZWQgUFEgVExTIERl
bW8gQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQTZZYmLf4ywAoRejJlMCNd
8EFtz7gwCsHna0zqp8NBerZdvM4pUNwmFsSb6pyELcxPfS/hohV63G5JAOcreM9k
o0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU
1K3Yjw1jXxL5EZzxdBQ4jybTtAcwCgYIKoZIzj0EAwIDSAAwRQIgYKgqZkMtJeI9
K8K7qZ2tdO5RPkRq7VYFUSdJZZxMNKACIQDs0idPxo5cjXaIzPUz3GNZeZGlQ0s9
vjbIEmIss3iqJw==
-----END CERTIFICATE-----
EOF
cat > server.pem <<'EOF'
-----BEGIN CERTIFICATE-----
MIIB5TCCAYygAwIBAgIUGfvagR77OCskKbwCCGme9dcUymUwCgYIKoZIzj0EAwIw
OTESMBAGA1UECgwJZWNkc2EuY29tMSMwIQYDVQQDDBpJbGx1c3RyYXRlZCBQUSBU
TFMgRGVtbyBDQTAeFw0yNjEwMjAxMTMyMjlaFw0yNjEyMDYxMTMyMjlaMBkxFzAV
BgNVBAMMDnBxLXRscy5leGFtcGxlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
vkyKek8iRLRJMhTwPtyzIi6agRiN4WF05FHlTfFE91h7RW5dsCsVIaxyYsvRhUQ/
dZJrO8Vm3mzr9OWSBf4rz6OBkTCBjjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQE
AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAZBgNVHREEEjAQgg5wcS10bHMuZXhh
bXBsZTAdBgNVHQ4EFgQUQsmdGy/ZbmpLy3vpYLmOhLcQs/4wHwYDVR0jBBgwFoAU
1K3Yjw1jXxL5EZzxdBQ4jybTtAcwCgYIKoZIzj0EAwIDRwAwRAIgXxyN7AGXG4m6
tsiHFmVQEo7iEQmcLsvhfA79XRwtXnECIDI5CfXve7WgdDcB7M++T/vH/f770S0z
czwFVB2Nh8hr
-----END CERTIFICATE-----
EOF
openssl verify -attime 1792495949 -CAfile ca.pem -verify_hostname pq-tls.example server.pem

输出 server.pem: OK

服务器 → 客户端记录 6 · 传输大小 102 字节

CertificateVerify

服务器用其证书对应的私钥，对截至目前的全部握手消息签名，以证明自己持有该私钥。验证这个签名时使用 Certificate 消息中的公钥。

记录保护

AES-128-GCM 密钥write_key: 5ed29e03b3495fd20354ed3f2421640a
初始化向量write_iv: e465385b2d22f07ffc6a4079
序列号 2 的 noncenonce: e465385b2d22f07ffc6a407b
附加数据：记录头additional_data: 1703030061
认证标签tag: a7d50cfc2454b60756d83834baef0ca7

GCM 标签验证通过：该记录在序列号 2 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 80 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 102 字节

解密后的内容 · 81 字节

计算方式CertificateVerify 签名

仅有有效的证书还不够；服务器必须证明自己此时此刻、针对这次握手的消息持有对应的私钥。它对一个固定的上下文字符串加上截至 Certificate 消息所有内容的哈希进行签名，客户端则用刚收到的公钥验证这个签名。

定义

content = 0x20 × 64 ‖ "TLS 1.3, server CertificateVerify" ‖ 0x00 ‖ SHA-256(ClientHello … Certificate)
valid   = ECDSA-P256-Verify(Q_server, SHA-256(content), (r, s))      ecdsa_secp256r1_sha256

本次会话中的值

SHA-256(ClientHello … Certificate): af76fc7ac4f19eb2af3f584874eb0cd0429a06a15cf60faefa739b3fa4eb8aad
被签名内容（130 字节）: 20202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020544c5320312e332c2073657276657220436572746966696361746556657269667900af76fc7ac4f19eb2af3f584874eb0cd0429a06a15cf60faefa739b3fa4eb8aad
服务器证书公钥（P-256 点）: 04be4c8a7a4f2244b4493214f03edcb3222e9a81188de16174e451e54df144f7587b456e5db02b1521ac7262cbd185443f75926b3bc566de6cebf4e59205fe2bcf
签名值 r: e2a43fd0b309c60cd461d2e842bf89926c1d271a3f6e79ee5776cb8cc4f8ddbc
签名值 s: a9667486294b49473c7bc82723f305694cdd7e8f591b587e2b75b909da995827

这证明了什么

ecdsa_secp256r1_sha256 是客户端在 signature_algorithms 中提供的方案之一。
CertificateVerify 签名经证书公钥针对被签名内容验证通过。
公开的演示签名密钥正是该证书的私钥。
OpenSSL 的 s_client 报告的对端签名类型为 ecdsa_secp256r1_sha256。

手动复现

unhex > server.der <<'EOF'
308201e53082018ca003020102021419fbda811efb382b2429bc0208699ef5d7
14ca65300a06082a8648ce3d040302303931123010060355040a0c0965636473
612e636f6d3123302106035504030c1a496c6c75737472617465642050512054
4c532044656d6f204341301e170d3236313032303131333232395a170d323631
3230363131333232395a30193117301506035504030c0e70712d746c732e6578
616d706c653059301306072a8648ce3d020106082a8648ce3d03010703420004
be4c8a7a4f2244b4493214f03edcb3222e9a81188de16174e451e54df144f758
7b456e5db02b1521ac7262cbd185443f75926b3bc566de6cebf4e59205fe2bcf
a3819130818e300c0603551d130101ff04023000300e0603551d0f0101ff0404
0302078030130603551d25040c300a06082b0601050507030130190603551d11
04123010820e70712d746c732e6578616d706c65301d0603551d0e0416041442
c99d1b2fd96e6a4bcb7be960b98e84b710b3fe301f0603551d23041830168014
d4add88f0d635f12f9119cf17414388f26d3b407300a06082a8648ce3d040302
034700304402205f1c8dec01971b89bab6c887166550128ee211099c2ecbe17c
0efd5d1c2d5e710220323909f5ef7bb5a0743701eccfbe4ffbc7fdfefbd12d33
733c05541d8d87c86b
EOF
openssl x509 -inform DER -in server.der -pubkey -noout > server-pub.pem
{ printf '%64s' ''; printf 'TLS 1.3, server CertificateVerify\000'; printf '%s' af76fc7ac4f19eb2af3f584874eb0cd0429a06a15cf60faefa739b3fa4eb8aad | unhex; } > signed.bin
printf '%s' 3046022100e2a43fd0b309c60cd461d2e842bf89926c1d271a3f6e79ee5776cb8cc4f8ddbc022100a9667486294b49473c7bc82723f305694cdd7e8f591b587e2b75b909da995827 | unhex > signature.der
openssl dgst -sha256 -verify server-pub.pem -signature signature.der signed.bin

输出 Verified OK

printf '%s' 3031020101042011aa8fac7486c821d6c57baa03c3a3e119a635f33aaa2043bba12d7f20a40a99a00a06082a8648ce3d030107 | unhex > server-key.der
openssl ec -inform DER -in server-key.der -pubout -outform DER 2>/dev/null | tail -c 65 | tohex

输出 04be4c8a7a4f2244b4493214f03edcb3222e9a81188de16174e451e54df144f7587b456e5db02b1521ac7262cbd185443f75926b3bc566de6cebf4e59205fe2bcf

服务器 → 客户端记录 7 · 传输大小 58 字节

Finished（服务器）

对全部握手消息计算的 HMAC，其密钥是只有掌握握手密钥的一方才能得到的秘密值。它完成并锁定了握手中服务器的那一半；客户端验证它之后，服务器即通过身份验证，密钥也得到确认。

记录保护

AES-128-GCM 密钥write_key: 5ed29e03b3495fd20354ed3f2421640a
初始化向量write_iv: e465385b2d22f07ffc6a4079
序列号 3 的 noncenonce: e465385b2d22f07ffc6a407a
附加数据：记录头additional_data: 1703030035
认证标签tag: 19198cc6e0426e75d2b219994f1a0467

GCM 标签验证通过：该记录在序列号 3 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 36 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 58 字节

解密后的内容 · 37 字节

计算方式服务器的 Finished

服务器的 Finished 是对截至目前全部握手消息计算的 HMAC，其密钥派生自握手流量秘密值。只有算出了相同密钥的一方才能生成它，因此验证它既能确认服务器的密钥，也能确认握手消息没有被篡改。

定义

finished_key = HKDF-Expand-Label(s_hs_traffic, "finished", "", 32)
verify_data  = HMAC-SHA256(finished_key, SHA-256(ClientHello … CertificateVerify))

本次会话中的值

服务器 finished_key: 0506725331e4fe72ae23212deef946f34556d38825410fb427bf071ee67951a1
SHA-256(ClientHello … CertificateVerify): 9e49537a2a313824d7825cbef2384d2a12ae91c8e09dcf3ac42fcd2393dae658
verify_data = HMAC(finished_key, 握手消息): 37187ea7e2a1e27e9d42e736edaac65dccc6dc9d03e7b862019dac0212000280

这证明了什么

重新计算的 verify_data 与 Finished 消息中的一致。

手动复现

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:46925f99fa426e5dc105f5eaccfca048e1e89a93370b07cb9ab447518eb8f47f \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:finished' \
  TLS13-KDF | tohex

输出 0506725331e4fe72ae23212deef946f34556d38825410fb427bf071ee67951a1

printf '%s' 9e49537a2a313824d7825cbef2384d2a12ae91c8e09dcf3ac42fcd2393dae658 | unhex | openssl mac -binary -digest SHA256 -macopt hexkey:0506725331e4fe72ae23212deef946f34556d38825410fb427bf071ee67951a1 HMAC | tohex

输出 37187ea7e2a1e27e9d42e736edaac65dccc6dc9d03e7b862019dac0212000280

计算方式应用流量秘密值

服务器一方完成后，密钥调度推进到主秘密值，结合截至服务器 Finished 的握手消息派生出应用流量秘密值，以及导出秘密值。由它们得到的密钥保护所有应用数据；OpenSSL 记录了全部三个秘密值，本页面的结果与之一致。

定义

derived         = Derive-Secret(handshake_secret, "derived", "")
main_secret     = HKDF-Extract(salt = derived, IKM = 0)          RFC 8446: master_secret
c_ap_traffic    = Derive-Secret(main_secret, "c ap traffic", ClientHello … server Finished)
s_ap_traffic    = Derive-Secret(main_secret, "s ap traffic", ClientHello … server Finished)
exporter_secret = Derive-Secret(main_secret, "exp master",   ClientHello … server Finished)

write_key = HKDF-Expand-Label(c_ap_traffic | s_ap_traffic, "key", "", 16)
write_iv  = HKDF-Expand-Label(c_ap_traffic | s_ap_traffic, "iv",  "", 12)

本次会话中的值

派生秘密值: cf180a268bf009d2b86962078fe3a21b7946acf2bf393b3a1672276547e88a81
main_secret（RFC 8446 中称为 master_secret）: 535beb1d564ea9c45dce195f453307900f8548a29f3889d55aea446547724e1b
SHA-256(ClientHello … 服务器 Finished): 5a0c617c785aacf18760a5272a8424b31be9504bf266939c6d0c7a008ca49adb
client_application_traffic_secret_0: 822f761f7f0218c1566132cf545c5f7b632ec3c9e5c454254c1ab051f2a92dec
server_application_traffic_secret_0: 556780cd0561751359abc293e490bbdff13dee06fe016160961add756502e56d
exporter_master_secret: fdf77404b2ef159adf31a636a7efb2a693ed0491d0362d0eb270ad93bd96592e
服务器应用密钥（AES-128）: f2c6df22d8075b76928d37545f335a64
服务器应用 write_iv: d3bd0df90c48d9fbb108cffb
客户端应用密钥（AES-128）: 58391c840aa46afae3552c38ad15b95b
客户端应用 write_iv: 68020e323a5ac9a9f0a4d49c

这证明了什么

与两个 SSLKEYLOGFILE 中的 CLIENT_TRAFFIC_SECRET_0 行一致。
与两个 SSLKEYLOGFILE 中的 SERVER_TRAFFIC_SECRET_0 行一致。
与两个 SSLKEYLOGFILE 中的 EXPORTER_SECRET 行一致。

手动复现

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:06b849eff15c46a4401e154110a2e63a14f7333237260156f7f1b67ca3305198 \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:derived' \
  -kdfopt hexdata:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 \
  TLS13-KDF | tohex

输出 cf180a268bf009d2b86962078fe3a21b7946acf2bf393b3a1672276547e88a81

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXTRACT_ONLY \
  -kdfopt hexsalt:cf180a268bf009d2b86962078fe3a21b7946acf2bf393b3a1672276547e88a81 \
  -kdfopt hexkey:0000000000000000000000000000000000000000000000000000000000000000 \
  HKDF | tohex

输出 535beb1d564ea9c45dce195f453307900f8548a29f3889d55aea446547724e1b

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:535beb1d564ea9c45dce195f453307900f8548a29f3889d55aea446547724e1b \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:c ap traffic' \
  -kdfopt hexdata:5a0c617c785aacf18760a5272a8424b31be9504bf266939c6d0c7a008ca49adb \
  TLS13-KDF | tohex

输出 822f761f7f0218c1566132cf545c5f7b632ec3c9e5c454254c1ab051f2a92dec

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:535beb1d564ea9c45dce195f453307900f8548a29f3889d55aea446547724e1b \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:s ap traffic' \
  -kdfopt hexdata:5a0c617c785aacf18760a5272a8424b31be9504bf266939c6d0c7a008ca49adb \
  TLS13-KDF | tohex

输出 556780cd0561751359abc293e490bbdff13dee06fe016160961add756502e56d

客户端 → 服务器记录 8 · 传输大小 6 字节

ChangeCipherSpec

客户端发送的对应占位记录，原因同样在于中间设备。

网络传输数据 · 6 字节

这 1 字节与 OpenSSL 用 -msg 为该记录打印的内容一致。

客户端 → 服务器记录 9 · 传输大小 58 字节

Finished（客户端）

客户端对截至服务器 Finished 的全部握手消息计算的 HMAC。它完成了握手：双方现在都已通过身份验证，并切换到应用密钥。

记录保护

这是一条携带加密数据的 application_data 记录。它使用客户端握手流量密钥和下方的逐记录 nonce，以 AES-128-GCM 解密；验证 16 字节的认证标签时，5 字节的记录头作为附加数据参与计算（RFC 9846 §5.2）。

AES-128-GCM 密钥write_key: 96fa01469d090b2a8f4ef6b9fa5e0784
初始化向量write_iv: 9f45d2e464131048897a81c6
序列号 0 的 noncenonce: 9f45d2e464131048897a81c6
附加数据：记录头additional_data: 1703030035
认证标签tag: f3a8eac5bf26a9ac3aaca3a4afebd656

GCM 标签验证通过：该记录在序列号 0 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 36 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 58 字节

解密后的内容 · 37 字节

计算方式客户端的 Finished

客户端用自己的 Finished 应答——对截至服务器 Finished 的握手消息计算的 HMAC，其密钥来自客户端握手流量秘密值。服务器验证通过后，握手即告完成，并且双向都经过了身份验证。

定义

finished_key = HKDF-Expand-Label(c_hs_traffic, "finished", "", 32)
verify_data  = HMAC-SHA256(finished_key, SHA-256(ClientHello … server Finished))

本次会话中的值

客户端 finished_key: 780c2e56af642c22fc8ae057276cd0d8bde149879a68ccb28064b4cf6b677a73
SHA-256(ClientHello … 服务器 Finished): 5a0c617c785aacf18760a5272a8424b31be9504bf266939c6d0c7a008ca49adb
verify_data = HMAC(finished_key, 握手消息): e1c250d75d6df181b0df677983ec692a146f428d982a0b4281cca28607ac7fb1

这证明了什么

重新计算的 verify_data 与 Finished 消息中的一致。

手动复现

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:8b0beea15604895fd4408c32b82684d347fa5e2422644c1d93978db70666f623 \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:finished' \
  TLS13-KDF | tohex

输出 780c2e56af642c22fc8ae057276cd0d8bde149879a68ccb28064b4cf6b677a73

printf '%s' 5a0c617c785aacf18760a5272a8424b31be9504bf266939c6d0c7a008ca49adb | unhex | openssl mac -binary -digest SHA256 -macopt hexkey:780c2e56af642c22fc8ae057276cd0d8bde149879a68ccb28064b4cf6b677a73 HMAC | tohex

输出 e1c250d75d6df181b0df677983ec692a146f428d982a0b4281cca28607ac7fb1

服务器 → 客户端记录 10 · 传输大小 239 字节

NewSessionTicket

服务器在握手之后附赠的礼物：一张票据，客户端下次可以出示它来恢复会话，无需完整的密钥交换。它所代表的预共享密钥由会话恢复秘密值和票据的 nonce 派生而来。

记录保护

这是一条携带加密数据的 application_data 记录。它使用服务器应用流量密钥和下方的逐记录 nonce，以 AES-128-GCM 解密；验证 16 字节的认证标签时，5 字节的记录头作为附加数据参与计算（RFC 9846 §5.2）。

AES-128-GCM 密钥write_key: f2c6df22d8075b76928d37545f335a64
初始化向量write_iv: d3bd0df90c48d9fbb108cffb
序列号 0 的 noncenonce: d3bd0df90c48d9fbb108cffb
附加数据：记录头additional_data: 17030300ea
认证标签tag: da58bb9fa9790e3f945cd811785d9ab3

GCM 标签验证通过：该记录在序列号 0 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 217 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 239 字节

解密后的内容 · 218 字节

计算方式会话恢复预共享密钥

没有票据所指代的秘密值，票据本身毫无用处。这个预共享密钥由会话恢复秘密值（它本身派生自截至客户端 Finished 的握手消息）和票据的 nonce 派生而来。OpenSSL 打印了 PSK 和票据；本页面重新计算 PSK 并与打印的值核对。

定义

resumption_secret = Derive-Secret(main_secret, "res master", ClientHello … client Finished)
PSK               = HKDF-Expand-Label(resumption_secret, "resumption", ticket_nonce, 32)

本次会话中的值

SHA-256(ClientHello … 客户端 Finished): b014275674636844d99285ea448e9c45e92acb5bc9bf249fa8d94b7796eb1211
resumption_master_secret: d013100d5c7e78c4d128a445969ce4ed1ddc3cd63a7f63bddcd82728d5129f8a
来自 NewSessionTicket 的 ticket_nonce: 0000000000000000
会话恢复 PSK: d1039d8e602a12c21ed17aa291499d5f1ef30eda117144c3591d5fccd74f7c0d

这证明了什么

重新计算的会话恢复 PSK 与 s_client 打印的一致。
票据的 192 字节与 s_client 打印的票据一致。

手动复现

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:535beb1d564ea9c45dce195f453307900f8548a29f3889d55aea446547724e1b \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:res master' \
  -kdfopt hexdata:b014275674636844d99285ea448e9c45e92acb5bc9bf249fa8d94b7796eb1211 \
  TLS13-KDF | tohex

输出 d013100d5c7e78c4d128a445969ce4ed1ddc3cd63a7f63bddcd82728d5129f8a

openssl kdf -binary -keylen 32 -kdfopt digest:SHA256 -kdfopt mode:EXPAND_ONLY \
  -kdfopt hexkey:d013100d5c7e78c4d128a445969ce4ed1ddc3cd63a7f63bddcd82728d5129f8a \
  -kdfopt 'prefix:tls13 ' -kdfopt 'label:resumption' \
  -kdfopt hexdata:0000000000000000 \
  TLS13-KDF | tohex

输出 d1039d8e602a12c21ed17aa291499d5f1ef30eda117144c3591d5fccd74f7c0d

客户端 → 服务器记录 11 · 传输大小 49 字节

应用数据（请求）

第一个真正的载荷，用客户端应用密钥加密：一行 HTTP 请求。从这里开始，记录的内容类型隐藏在加密数据内部。

记录保护

这是一条携带加密数据的 application_data 记录。它使用客户端应用流量密钥和下方的逐记录 nonce，以 AES-128-GCM 解密；验证 16 字节的认证标签时，5 字节的记录头作为附加数据参与计算（RFC 9846 §5.2）。

AES-128-GCM 密钥write_key: 58391c840aa46afae3552c38ad15b95b
初始化向量write_iv: 68020e323a5ac9a9f0a4d49c
序列号 0 的 noncenonce: 68020e323a5ac9a9f0a4d49c
附加数据：记录头additional_data: 170303002c
认证标签tag: 44f8869fbc72bc4a095024412310f30e

GCM 标签验证通过：该记录在序列号 0 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的内容类型和字节与 OpenSSL 的 -msg 跟踪输出一致。

网络传输数据 · 49 字节

解密后的内容 · 28 字节

服务器 → 客户端记录 12 · 传输大小 130 字节

应用数据（响应）

服务器用其应用密钥加密的应答：包含客户端所请求文件的 HTTP 响应。

记录保护

AES-128-GCM 密钥write_key: f2c6df22d8075b76928d37545f335a64
初始化向量write_iv: d3bd0df90c48d9fbb108cffb
序列号 1 的 noncenonce: d3bd0df90c48d9fbb108cffa
附加数据：记录头additional_data: 170303007d
认证标签tag: 152ee3122b64d6188a96491377f3ba2d

GCM 标签验证通过：该记录在序列号 1 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的内容类型和字节与 OpenSSL 的 -msg 跟踪输出一致。

网络传输数据 · 130 字节

解密后的内容 · 109 字节

服务器 → 客户端记录 13 · 传输大小 24 字节

警报（close_notify）

服务器通知正常关闭连接。警报同样经过加密，因此连关闭过程也是保密的。

记录保护

AES-128-GCM 密钥write_key: f2c6df22d8075b76928d37545f335a64
初始化向量write_iv: d3bd0df90c48d9fbb108cffb
序列号 2 的 noncenonce: d3bd0df90c48d9fbb108cff9
附加数据：记录头additional_data: 1703030013
认证标签tag: d1a180f9a2947d57978b590f4ea3faa8

GCM 标签验证通过：该记录在序列号 2 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 2 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 24 字节

解密后的内容 · 3 字节

客户端 → 服务器记录 14 · 传输大小 24 字节

警报（close_notify）

客户端确认关闭，连接随之结束。

记录保护

AES-128-GCM 密钥write_key: 58391c840aa46afae3552c38ad15b95b
初始化向量write_iv: 68020e323a5ac9a9f0a4d49c
序列号 1 的 noncenonce: 68020e323a5ac9a9f0a4d49d
附加数据：记录头additional_data: 1703030013
认证标签tag: daf6ae55a253a373f23464e913920d47

GCM 标签验证通过：该记录在序列号 1 下顺利解密。
将解密得到的明文重新加密，结果与抓取的记录完全一致。
解密得到的 2 字节与 OpenSSL 用 -msg 为该消息打印的内容一致。

网络传输数据 · 24 字节

解密后的内容 · 3 字节

与 OpenSSL 的密钥日志核对

OpenSSL 在两端各写入了一个 SSLKEYLOGFILE——Wireshark 用来解密抓包文件的格式。其中的五个秘密值，每一个都是上文计算出的某个流量秘密值，因此逐一完全匹配，就证明了本页面的密钥调度正是真实连接所用的那一套。

SSLKEYLOGFILE 标签	秘密值（十六进制）	在本页面中派生为
SERVER_HANDSHAKE_TRAFFIC_SECRET	46925f99fa426e5dc105f5eaccfca048e1e89a93370b07cb9ab447518eb8f47f	server_handshake_traffic_secret
EXPORTER_SECRET	fdf77404b2ef159adf31a636a7efb2a693ed0491d0362d0eb270ad93bd96592e	exporter_master_secret
SERVER_TRAFFIC_SECRET_0	556780cd0561751359abc293e490bbdff13dee06fe016160961add756502e56d	server_application_traffic_secret_0
CLIENT_HANDSHAKE_TRAFFIC_SECRET	8b0beea15604895fd4408c32b82684d347fa5e2422644c1d93978db70666f623	client_handshake_traffic_secret
CLIENT_TRAFFIC_SECRET_0	822f761f7f0218c1566132cf545c5f7b632ec3c9e5c454254c1ab051f2a92dec	client_application_traffic_secret_0

抓包方式

这次握手是真实的，而非模拟：两个 OpenSSL 进程在同一个固定版本的容器内通过环回接口进行 TLS 1.3 通信，数据包直接从网络上抓取。重新抓包会生成一个结构相同的新会话。

容器镜像: node:24.22.0-trixie@sha256:ff054b356ab93ed540518ca23cfcd9840e5256dd04db5a8d8afc43f4ecc7c9f8
OpenSSL: OpenSSL 3.5.7 9 Jun 2026 (Library: OpenSSL 3.5.7 9 Jun 2026)
抓取时间: 2026-10-20T11:32:29Z
服务器: openssl s_server -accept 4433 -naccept 1 -WWW -cert server.crt -key server.key -tls1_3 -ciphersuites TLS_AES_128_GCM_SHA256 -groups X25519MLKEM768 -num_tickets 1 -keylogfile server-keylog.txt
客户端: openssl s_client -connect 127.0.0.1:4433 -servername pq-tls.example -verify_hostname pq-tls.example -CAfile ca.crt -verify_return_error -tls1_3 -keylogfile client-keylog.txt -ign_eof -msg -msgfile client-msg.txt

每条命令都是独立的，只依赖下面这两个辅助函数；先粘贴它们（需要 OpenSSL 3.5，以及 Linux 和 macOS 都自带的 Perl 和 od）：

unhex() { perl -0777 -ne 's/\s+//g; print pack("H*", $_)'; }
tohex() { od -An -v -tx1 | tr -d ' \n'; echo; }

规范

混合密钥交换由 RFC 10024（X25519MLKEM768）定义，它将 NIST FIPS 203 中的 ML-KEM-768 与 RFC 7748 中的 X25519 结合在一起；混合构造方式以及各分量在密钥共享中的排列顺序遵循 RFC 9954；其余部分均为 RFC 9846（它取代了 RFC 8446）所规定的 TLS 1.3，密钥调度的推导过程已与 RFC 8448 交叉核对。码点和算法名称取自 IANA 的 TLS 注册表和对象标识符注册表。

用自己的流量试一试

继续阅读

本页面的形式——一次真实的连接，每个字节都有讲解——沿用自 Michael Driscoll 的 The Illustrated TLS 1.3 Connection（采用 MIT 许可证）。这里的抓包数据、讲解和代码都出自我们之手；本页面在此基础上增加了后量子密钥交换。