TLS 1.2 协议

阅读量87626

发布时间 : 2023-01-06 11:00:33

 

这一篇我们将使用 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,可以看到,第二次握手之后直接就开启了加密通讯,省去了密钥协商的步骤。

本文由山石安研院原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/285089

安全客 - 有思想的安全新媒体

分享到:微信
+10赞
收藏
山石安研院
分享到:微信

发表评论

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66