上一篇我们分析了下 TLS 1.2 协议的各个细节，这一篇我们将使用 wireshark 对一次连接（访问 www.baidu.com ）进行抓包并尝试分析。
这里我根据 client hello 包确定了baidu.com 的ip 是 220.181.33.11，于是设定过滤规则 tls，得到
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
614380d8（GMT Unix Time) 3e548c46492a96347a353e8efd4f43f114afdf7a41f01423ebe65245（Random Bytes）：Random Number
f12bbc673f3b62d31f63366790d12e1c13a043d829cfa98bfc9487dbd27e574f：session ID
0020：length of Cipher Suites
8a8a130113021303c02bc02fc02cc030cca9cca8c013c014009c009d002f0035：list of Cipher Suites
01：length of Compression Methods
686d2e62616964752e636f6d：hm.baidu.com
0000：length of master_secret
0001：length of renegotiation_info
00:：length of renegotiation_info extension
000a：length of supperted groups
0008：length of supperted groups list
6a6a001d00170018：4 groups
0002：length of ec_point_formats
0000：length of session_ticket
0010：application_layer_protocol_negotiation
000e：length of application_layer_protocol_negotiation
000c：length of ALPN Protocol
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
0029：length of Client Key Share
0001：length of Key Exchange
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
0007：length of supported_versions
06：lenth of supported versions
001b：compress_certificate
0003：length of compress_certificate
0002：length of Algorithms
0005：length of Unknown‘s data
0001：length of Reserved’s data
我们可以看到，Clinet Hello 请求连接的服务域名是 hm.baidu.com，并且之前是连接过的，所以携带了32字节的 Session ID；并且32字节随机数也不是完全随机的，前面4个字节代表 GMT UNIX 时间戳。
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
000046：length of Server Hello
6386f0d1（GMT Unix Time）954bb3362f237169b4c06155e3a3397487790c08ba7e9420c0edaead（random bytes）：Random
c02f：Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
00：Compression Method: null (0)
001e：length of Extensions
0000：length of session_ticket
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
0002：length of ec_point_formats
服务端发送响应的回应包，但是注意到这里服务端的回应是不带Session ID的。然后，服务端将会返回一个包含 服务端证书、服务端发送交换密钥、服务端回复完毕 的包。
具体证书的格式这里我们暂不细究，应该也许会开另一篇文章专门分析。
0012c6：length of Server Hello
00…70：Specific data of Certificate
在服务端发送交换密钥之前，服务端本地肯定是要先生成交换密钥的，不过这个过程肯定是没办法在抓到的数据包中体现的。
16·0303·012c·0c·000128·03·001d·20·84890a5d3dd07f92a099e20e5990b8512803f84a90409e7c2802d9509e3f3d67·0804·0100·8d8765a013acab1283f5bd691120c89012432abc9e1f169187bd0a3bf4af50b4bfc44f5d26e7ce17d3b943297c5fb8aa6435515a43ce0de426e5b4bf9d86263a023b0f710fd74f2962dbf449fc46872560f4c9b0dcd2c60bf616cac071f2a48dd69ceb42810556403f1447b9a488d0e4f96d98174f5f4d6dc5df9d9b4ddae2eec67155e277a3fe8627ac790d7fb035c0e8d28f932ee3806c72ddaf7e05fa87f64b863036012e78ec6191c385874dafe86b84a53e253d8874b59619296d865c2927edbea3cd2260da84129813f30408fca64e71e37a82a86407626483933b40c2a00d70abdf56daf41cb9938ab646861659832de8861d511942d3eb7b55bd2049
000128：length of Server Key Exchange
84890a5d3dd07f92a099e20e5990b8512803f84a90409e7c2802d9509e3f3d67：publickey
0804：signature algorithm-rsa_pss_rsae_sha256
0100：length of signature algorithm
总共报文就只有300字节，光签名就占了256字节。
000000：length of Server Hello Done
下一个包一次性包含三段报 文，分别是 客户端发送交换密钥；客户端启用加密通讯；握手完毕并发送一段用于验证的加密握手信息
16·0303·0025·10·000021·20·7f59d0486f3e6d18824128937a23dcd332c3d0ecab36c82adbc8dbbc40074d22
000021：length of Client Key Exchange
7f59d0486f3e6d18824128937a23dcd332c3d0ecab36c82adbc8dbbc40074d22：Publickey
（Client Change Cipher Spec）
客户端提示服务端，接下来的报文将使用通讯密钥进行加密
0001：length of Change Cipher Spec
（Encrypted Handshake Message）
16·0303·0028·0000000000000000·c96711c338789358217e5806a5862f53d6a8e6307a6ff6f6bbc0ac0a49f3a2f4
0028：length of Handshake·
0000000000000000c96711c338789358217e5806a5862f53d6a8e6307a6ff6f6bbc0ac0a49f3a2f4：加密消息的密文，其中，前十六字节是IV向量，这里是十六个字节的0向量。正确解密应该会得到与之前所有握手消息的 SHA256 相关的一段验证信息。
服务端也会有相应的动作，下一份服务端发送的包含：创建新的Session票据；启用加密通讯；和一段加密的握手消息。
16·0303·0072·04·00006e·00000000·0068·6ede616a704ce1417f6314326df7fa7566284ae5c5609150b2f87b58a78b9060d807630fdd6cd22831c3e9a5a2f8f388e444e7edbed2b99dbfe4cd02ea98abce5bba458cc569f44c013e7576a080afe7247d3fda34b4300a7a0e3bb64eb1bfa6dc7da28f936cdf20
00006e：length of TLS Session Ticket
00000000：Session Ticket Lifetime：0
0068：length of Session Ticket
6ede616a…6dc7da28f936cdf20：Session Ticket
（Server Change Cipher Spec）
（Encrypted Handshake Message）
16·0303·0028·0000000000000000·e773ce87074526aff7798fae9306f8d88359efb62b4d06d12b2357ca01b48283
150303001a00000000000000021f8d2caea7b37d2249d63b60bc472232ce6f
0000…2ce6f ：Encrypted Alert
不难发现，本次连接使用的加密向量均为0向量。这样使用会不会出现安全问题呢？也许是一个可以研究的点。
最后，我们还有一个疑问，就是每次连接的session和上一次分发的session ticket 有什么关系呢？Session ID 和 Session Ticket 都是用于会话恢复。不过 Session ID 一般用于单一服务器。向百度这种大网站，肯定是需要负载均衡的，因此会使用加密的Session Ticket，该Session Ticket 使用百度服务端的密钥加密，也只有百度所有的服务器能够解密。解密后的Ticket包含会话密钥等前一次连接已协商完成的信息，于是此次就可以直接进行会话的恢复，无需重新进行密钥协商。
这里我重新访问了两次www.baidu.com，可以看到，第二次握手之后直接就开启了加密通讯，省去了密钥协商的步骤。
原文始发于微信公众号（山石网科安全技术研究院）：密码学 ｜TLS 1.2 协议（二）
