TLS 1.2 协议（二）
- 客户端请求（Client Hello)
- 服务端回应（Server Hello）
- 服务端证书（Server Certificate）
- 服务端发送交换密钥（Server Key Exchange）
- 服务端回复完毕（Server Hello Done）
- 客户端发送交换密钥（Client Key Exchange）
- 客户端启用加密通讯（Client Change Cipher Spec）
- 加密的握手信息（Encrypted Handshake Message）
- 服务端创建新的Session票据（New Session Ticket）
- 服务端启用通讯加密（Server Change Cipher Spec）
- 加密的握手信息（Encrypted Handshake Message）
- 加密的告警（Encrypted Alert）
上一篇我们分析了下 TLS 1.2 协议的各个细节，这一篇我们将使用 wireshark 对一次连接（访问 www.baidu.com ）进行抓包并尝试分析。
这里我根据 client hello 包确定了baidu.com 的ip 是 220.181.33.11，于是设定过滤规则 tls，得到
客户端请求（Client Hello)
报文：16·0301·0200·01·0001fc·0303·614380d83e548c46492a96347a353e8efd4f43f114afdf7a41f01423ebe65245·20·f12bbc673f3b62d31f63366790d12e1c13a043d829cfa98bfc9487dbd27e574f·0020·8a8a130113021303c02bc02fc02cc030cca9cca8c013c014009c009d002f0035·01·00·0193·0a0a·00·00·0000·0011·000f·00·000c·686d2e62616964752e636f6d·0017·0000·ff01·0001·00·000a·000a·0008·6a6a001d00170018·000b·0002·01·00·0023·0000·0010·000e·000c·02·6832·08·687474702f312e31·0005·0005·01·0000·0000·000d·0012·0010·04030804040105030805050108060601·0012·0000·0033·002b·0029·6a6a·0001·00·001d·0020·1d2d75215d350b351a289937a974c8b1a1f8430b2c4516a9e03329528cefba5f·002d·0002·01·01·002b·0007·06·5a5a·0304·0303·001b·0003·02·0002·4469·0005·0003026832·caca·0001·00·0015·00cb·0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
16：Handshake
0301：TLS 1.0
0200：length
01：Client Hello
0001fc：length
0303：TLS 1.2
614380d8（GMT Unix Time) 3e548c46492a96347a353e8efd4f43f114afdf7a41f01423ebe65245（Random Bytes）：Random Number
20：length of session ID
f12bbc673f3b62d31f63366790d12e1c13a043d829cfa98bfc9487dbd27e574f：session ID
0020：length of Cipher Suites
8a8a130113021303c02bc02fc02cc030cca9cca8c013c014009c009d002f0035：list of Cipher Suites
01：length of Compression Methods
00：null
0193：length of Extension
0a0a：Reserved
00：length
0000：server_name
0011：length
000f：length
00：host_name
000c：length of host_name
686d2e62616964752e636f6d：hm.baidu.com
0017：master_secret
0000：length of master_secret
ff01：renegotiation_info
0001：length of renegotiation_info
00:：length of renegotiation_info extension
000a：supported_groups
000a：length of supperted groups
0008：length of supperted groups list
6a6a001d00170018：4 groups
000b：ec_point_formats
0002：length of ec_point_formats
01：length of formats
00：uncompressed
0023：session_ticket
0000：length of session_ticket
0010：application_layer_protocol_negotiation
000e：length of application_layer_protocol_negotiation
000c：length of ALPN Protocol
02：length of ALPN string
6832：h2
08：length of ALPN string
687474702f31：http/1.1
0005：status_request
0005：length of status_request
01：Certificate Status Type：OSCP
0000：length of Resonder ID list
0000：length of Request Extension
000d：signature_algorithms
0012：length of signature_algorithms
0010：length of Signature Hash algorithms
04030804040105030805050108060601：8 algorithms
0012：signed_certificate_timestamp
0000：length of signed_certificate_timestamp
0033：key_share
002b：length of key_share
0029：length of Client Key Share
6a6a：Reserved
0001：length of Key Exchange
00：Key Exchange
001d：x25519
0020：length of Key Exchange
1d2d75215d350b351a289937a974c8b1a1f8430b2c4516a9e03329528cefba5f：Key Exchange
002d：psk_key_exchange_modes
0002：length of psk_key_exchange_modes
01：length of PSK key Exchange Modes
01：PSK with (EC)DHE key estabishment
002b：supported_versions
0007：length of supported_versions
06：lenth of supported versions
5a5a：Unknown
0304：TLS1.3
0303：TLS1.2
001b：compress_certificate
0003：length of compress_certificate
0002：length of Algorithms
0002：brotli
4469：Unknown
0005：length of Unknown‘s data
0003026832：data
caca：Reserved
0001：length of Reserved’s data
00：data
0015：padding
00cb：length of padding
00…..000：padding
我们可以看到，Clinet Hello 请求连接的服务域名是 hm.baidu.com，并且之前是连接过的，所以携带了32字节的 Session ID；并且32字节随机数也不是完全随机的，前面4个字节代表 GMT UNIX 时间戳。
服务端回应（Server Hello）
16·0303·004a·02·000046·0303·6386f0d1954bb3362f237169b4c06155e3a3397487790c08ba7e9420c0edaead·00·c02f·00·001e·0023·0000·ff01·0001·00·0010·000b·0009·08·687474702f312e31·000b·0002·01·00
16：Handshake
0303：TLS 1.2
004a：length of Handshake
02：Server Hello
000046：length of Server Hello
0303：TLS 1.2
6386f0d1（GMT Unix Time）954bb3362f237169b4c06155e3a3397487790c08ba7e9420c0edaead（random bytes）：Random
00：length of session ID
c02f：Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
00：Compression Method: null (0)
001e：length of Extensions
0023：session_ticket
0000：length of session_ticket
ff01：renegotiation_info
0001：length of renegotiation_info
00：length of Renegotiation info extension
0010：application_layer_protocol_negotiation
000b：length of application_layer_protocol_negotiation
0009：length of ALPN Protocol
08：length of ALPN string
687474702f31：http/1.1
000b：ec_point_formats
0002：length of ec_point_formats
01：length of formats
00：uncompressed
服务端发送响应的回应包，但是注意到这里服务端的回应是不带Session ID的。然后，服务端将会返回一个包含 服务端证书、服务端发送交换密钥、服务端回复完毕 的包。
服务端证书（Server Certificate）
具体证书的格式这里我们暂不细究，应该也许会开另一篇文章专门分析。
证书的报文结构：
16：Handshake
0303：TLS 1.2
12ca：length of Handshake
0b：Certificate
0012c6：length of Server Hello
00…70：Specific data of Certificate
服务端发送交换密钥（Server Key Exchange）
在服务端发送交换密钥之前，服务端本地肯定是要先生成交换密钥的，不过这个过程肯定是没办法在抓到的数据包中体现的。
16·0303·012c·0c·000128·03·001d·20·84890a5d3dd07f92a099e20e5990b8512803f84a90409e7c2802d9509e3f3d67·0804·0100·8d8765a013acab1283f5bd691120c89012432abc9e1f169187bd0a3bf4af50b4bfc44f5d26e7ce17d3b943297c5fb8aa6435515a43ce0de426e5b4bf9d86263a023b0f710fd74f2962dbf449fc46872560f4c9b0dcd2c60bf616cac071f2a48dd69ceb42810556403f1447b9a488d0e4f96d98174f5f4d6dc5df9d9b4ddae2eec67155e277a3fe8627ac790d7fb035c0e8d28f932ee3806c72ddaf7e05fa87f64b863036012e78ec6191c385874dafe86b84a53e253d8874b59619296d865c2927edbea3cd2260da84129813f30408fca64e71e37a82a86407626483933b40c2a00d70abdf56daf41cb9938ab646861659832de8861d511942d3eb7b55bd2049
报文结构：
16：Handshake
0303：TLS 1.2
012c：length of Handshake
0c：Server Key Exchange
000128：length of Server Key Exchange
03：named_curve
001d：曲线x25519
20：length of publickey
84890a5d3dd07f92a099e20e5990b8512803f84a90409e7c2802d9509e3f3d67：publickey
0804：signature algorithm-rsa_pss_rsae_sha256
0100：length of signature algorithm
8d…..49：signature
总共报文就只有300字节，光签名就占了256字节。。。。
服务端回复完毕（Server Hello Done）
16·0303·0004·0e·000000
报文结构：
16：Handshake
0303：TLS 1.2
0004：length of Handshake
0e：Server Hello Done
000000：length of Server Hello Done
下一个包一次性包含三段报 文，分别是 客户端发送交换密钥；客户端启用加密通讯；握手完毕并发送一段用于验证的加密握手信息
客户端发送交换密钥（Client Key Exchange）
客户端发送交换密钥的报文格式同服务端发送交换密钥
16·0303·0025·10·000021·20·7f59d0486f3e6d18824128937a23dcd332c3d0ecab36c82adbc8dbbc40074d22
报文结构：
16：Handshake
0303：TLS 1.2
0025：length of Handshake
10: Client Key Exchange
000021：length of Client Key Exchange
20：length of Publickey
7f59d0486f3e6d18824128937a23dcd332c3d0ecab36c82adbc8dbbc40074d22：Publickey
客户端启用加密通讯（Client Change Cipher Spec）
客户端提示服务端，接下来的报文将使用通讯密钥进行加密
14·0303·0001·01
报文结构：
14：Change Cipher Spec
0303：TLS 1.2
0001：length of Change Cipher Spec
01：Cipher Spec Message
加密的握手信息（Encrypted Handshake Message）
16·0303·0028·0000000000000000·c96711c338789358217e5806a5862f53d6a8e6307a6ff6f6bbc0ac0a49f3a2f4
报文结构：
16：Handshake
0303：TLS 1.2
0028：length of Handshake·
0000000000000000c96711c338789358217e5806a5862f53d6a8e6307a6ff6f6bbc0ac0a49f3a2f4：加密消息的密文，其中，前十六字节是IV向量，这里是十六个字节的0向量。正确解密应该会得到与之前所有握手消息的 SHA256 相关的一段验证信息。
随后客户端会发送正常的用于通讯的但被加密的消息
服务端也会有相应的动作，下一份服务端发送的包含：创建新的Session票据；启用加密通讯；和一段加密的握手消息
服务端创建新的Session票据（New Session Ticket）
16·0303·0072·04·00006e·00000000·0068·6ede616a704ce1417f6314326df7fa7566284ae5c5609150b2f87b58a78b9060d807630fdd6cd22831c3e9a5a2f8f388e444e7edbed2b99dbfe4cd02ea98abce5bba458cc569f44c013e7576a080afe7247d3fda34b4300a7a0e3bb64eb1bfa6dc7da28f936cdf20
报文结构：
16：Handshake
0303：TLS 1.2
0072：length of Handshake
04：New Session Ticket
00006e：length of TLS Session Ticket
00000000：Session Ticket Lifetime：0s
0068：length of Session Ticket
6ede616a…6dc7da28f936cdf20：Session Ticket
服务端启用通讯加密（Server Change Cipher Spec）
14·0303·0001·01
同客户端启用加密通讯
加密的握手信息（Encrypted Handshake Message）
16·0303·0028·0000000000000000·e773ce87074526aff7798fae9306f8d88359efb62b4d06d12b2357ca01b48283
结构同客户端发送的加密握手信息
加密的告警（Encrypted Alert）
最后，本次连接由服务端主动关闭，发出关闭告警
150303001a00000000000000021f8d2caea7b37d2249d63b60bc472232ce6f
报文结构
15：Alert
0303：TLS 1.2
001a：length of Alert
0000…2ce6f ：Encrypted Alert
不难发现，本次连接使用的加密向量均为0向量。这样使用会不会出现安全问题呢？也许是一个可以研究的点。
最后，我们还有一个疑问，就是每次连接的session和上一次分发的session ticket 有什么关系呢？Session ID 和 Session Ticket 都是用于会话恢复。不过 Session ID 一般用于单一服务器。向百度这种大网站，肯定是需要负载均衡的，因此会使用加密的Session Ticket，该Session Ticket 使用百度服务端的密钥加密，也只有百度所有的服务器能够解密。解密后的Ticket包含会话密钥等前一次连接已协商完成的信息，于是此次就可以直接进行会话的恢复，无需重新进行密钥协商。
这里我重新访问了两次www.baidu.com，可以看到，第二次握手之后直接就开启了加密通讯，省去了密钥协商的步骤。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可联系QQ 643713081，也可以邮件至 643713081@qq.com
文章标题:TLS 1.2 协议（二）
文章字数:1.8k
本文作者:Van1sh
发布时间:2022-12-15, 10:24:00
最后更新:2023-01-31, 16:18:47
原始链接:http://jayxv.github.io/2022/12/15/TLS1.2协议分析（二）/版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。
