小木槌

Appearance

TLS1.2协议-GET请求抓包分析 ​

本文写的略显粗糙，主要是因为对TLS认识不够充分。请辩证阅读，避免误导。

理论前提 ​

一个网站如果要支持HTTPS，需要在CA机构申领一份数字证书及其私钥文件，数字证书里含有证书持有者信息、公钥信息等。CA机构是可信方。如果CA机构作恶，那么HTTPS将不安全（退化为HTTP）。也就是说，服务端拥有一套非对称加密体系的公私钥。

服务端的公钥可以向外发送传输，但是私钥不会向外发送传输。

HTTPS的流程如下：

1.Client向Server发起HTTPS请求。

2.Server向Client返回自身数字证书（其中含有服务端公钥PK），Client收到证书后会验证数字证书的合法性。合法性验证通过后，Client会生成一个随机密钥client key，这个密钥被称为客户端密钥，用于对称加密。

3.Client使用服务端公钥PK对client key进行加密，将加密之后的客户端密钥发送给服务器。

4.Server接收到Client发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对Data进行对称加密，这样Data就变成了Cipher。

5.Server将加密后的密文Cipher发送给Client。

6.Client接收到密文Cipher后用client key解密即可得到服务器发送的数据明文。

抓包实验 ​

一次HTTPS的Get请求如下：

1

使用Wireshark抓包，得到的数据帧如下图：

2

可以从上图看到，前三帧为三次握手，最后四帧为四次挥手，这中间的帧便是TLS的相关数据帧，可以看到其使用的是TLS 1.2。TLS 1.3在 RFC 8446 中定义，于2018年8月发表。

因此不同类型的TLS数据包的帧格式也不同，所以本文就不再分别给出TLS的所有帧格式，也不再逐个字节分析数据包的内容。给出TLS的通用帧格式图。

3

直接看Wireshark给出的分析：

4

然后客户端接收到了一个ACK（第643帧），表示服务端已收到第642帧内容。

然后服务器发送了第644，645和646帧，这三帧其实是一次发送的，但是被分片了。分片相关内容本文不详细分析，只分析TLS流程。

5

可以看到，服务端向客户端发送了数字证书，公钥并发送Server Hello Done给客户端，告知本次Hello行为已结束。

其中，服务端发送了ECDH（即上图的EC Diffie-Hellman）参数，包括曲线种类，曲线名字，公钥长度，公钥，数字签名算法，签名长度与签名本身。发送ECSH参数的目的是为了在不传递密钥明文的情况下，能够完成对公共密钥的协商。这里双方就是在协商客户端的AES对称加密的密钥。

6

在Client连续返回了两个ACK后，其向服务端发送了第649帧。可以看到，客户端也发送了ECDH公钥，并发送了Change Cipher Spec和Encrypted Handshake Message消息。

其中，Change Cipher Spec消息可以让对方知晓我方已经生成了会话密钥，已经做好切换至加密通信的准备了。Encrypted Handshake Message是使用对称秘钥进行加密的第一个报文，如果对方接收到这个报文并对其加解密校验成功，那么就说明对称秘钥是正确的。

然后看下一帧，第650帧。

7

这一帧服务端向客户端发送了Change Cipher Spec和Encrypted Handshake Message消息。这里客户端发送Change Cipher Spec的前提是649帧的Encrypted Handshake Message已经校验成功。然后服务端同样发送Encrypted Handshake Message来让客户端验证。

随后，客户端向服务端发送了一个ACK，也就是第651帧。

然后，看第652帧，服务端向客户端发了一个加密的Application Data，后续就是加密后的HTTP流程了，也就是HTTPS。

问题：为什么会存在第652帧？

然后，看第667帧，客户端发出了Encrypted Alert，意味着加密通信因为某些原因需要中断，警告对方不要再发送敏感的数据。

8

最后便是四次挥手断开连接。

DH密钥协商 ​

这是DH密钥协商步骤，ECDH是基于椭圆曲线的密钥协商，更为复杂一些。

  • 双方共同协商大质数P和G。

  • 双方生成各自私钥。

  • 双方用**各自私钥×G modP **生成公钥。

  • 双方交换公钥。

  • 双方用各自私钥×对方公钥 mod P生成整数K。

其中，双方生成的K值相同，K值则为双方所协商的密钥。

注意：此过程可以防嗅探，但会被中间人攻击，中间人在双方交换密钥时截获并篡改信息，完全可以伪装成Alice或者Bob给对方发消息，可以使用CA认证防止攻击（必须引入一个可信方）。

CA认证防中间人攻击原理是：当我访问一个网站www.google.com时，谷歌会把由可信CA机构颁发的证书发给客户端，并附带其数字签名。客户端可以认证这个证书的有效性。因为CA机构是可信的，所以证书验证通过也就意味着“对方就是google，不是一个中间攻击人”。因为中间攻击人是拿不出这个证书的数字签名的，私钥只在谷歌手里有，所以能拿出这个证书及数字签名的一定是谷歌。