SSL/TLS 通信过程

103style

发布于 2022-12-19 13:52:18

1.4K0

文章被收录于专栏：Android开发经验分享Android开发经验分享

转载请以链接形式标明出处：本文出自:103style的博客

Wireshark抓包
Client Hello
Server Hello、Certificate、Server Key Exchange、Server Hello Done
Client 验证 Server 证书
Client Key Exchange、Change Cipher Spec、Encrypted Handshake Message
Server→New Session Ticket
Server→Change Cipher Spec、Encrypted Handshake Message
握手结束
加密通信–Application Data
重建连接
密钥计算
参考文章

Wireshark抓包

首先是 TCP 的三次握手，然后就到 TLS的通信。

Source	Destination	Protocol	Info
Client	Server	TCP	[SYN] Seq=0
Server	Client	TCP	[SYN, ACK] Seq=0 Ack=1
Client	Server	TCP	[ACK] Seq=1 Ack=1
Client	Server	TLSv1.2	Client Hello
Server	Client	TLSv1.2	Server Hello Certificate Server Key Exchange Server Hello Done
Client	Server	TLSv1.2	Client Key Exchange Change Cipher Spec Encrypted Handshake Message
Server	Client	TLSv1.2	New Session Ticket Change Cipher Spec Encrypted Handshake Message
Client	Server	TLSv1.2	Application Data
Server	Client	TLSv1.2	Application Data

Client Hello

客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：

支持的最高 TSL协议 版本 version，从低到高依次 SSLv2 < SSLv3 < TLSv1 < TLSv1.1 < TLSv1.2，当前基本不再使用低于 TLSv1 的版本。
随机数 Random，用于后续的密钥的生成。
客户端支持的加密套件 Cipher Suites 列表，每个加密套件对应前面TLS原理中的四个功能的组合：认证算法(身份验证)、密钥交换算法KeyExchange(密钥协商)、对称加密算法Enc(信息加密)和 信息摘要Mac(完整性校验)。
支持的压缩算法 Compression Methods 列表，用于后续的信息压缩传输。
扩展字段 Extension，支持协议与算法相关参数以及其它辅助信息等，常见的SNI就属于扩展字段。

Server Hello、Certificate、Server Key Exchange、Server Hello Done

Server Hello 服务端返回墒的信息结果，包括选择使用的协议版本Version(TLS 1.2),选择的加密套件 Cipher Suite(TLS_ECDHE_RAS_WITH_AES_128_GCM_SHA256)，选择的压缩算法 Compression Method(null)、随机数 Random 等，其中随机数用于后续的密钥协商。

Certificate 服务器端配置对应的证书链，用于身份认证与密钥交换。

Server Key Exchange Server Hello中选择的 ECDHE 密钥交换算法比 RSA 密钥交换算法多的一个步骤。

Server Hello Done 通知客户端 Server Hello 信息发送结束

Client 验证 Server 证书

客户端验证证书的合法性，如果验证通过才会进行后续的通信，否则根据错误情况做出不同提示和操作，合法性验证包括如下：

证书链的可信性 trusted catificate path（上面Server 端配置的证书链）
证书是否吊销revocation,有两类方式离线CRL与在线OCSP，不同的客户端行为会不同.
有效期expiry date,证书是否在有效时间范围.
域名domain,核查证书域名是否与当前的访问域名匹配，匹配规则后续分析.

Client Key Exchange、Change Cipher Spec、Encrypted Handshake Message

Client Key Exchange 合法性校验通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器。此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 Random_C 和Random_S 与自己计算产生的 Pre-master，计算得到协商密钥:enc_key=Fuc(random_C,random_S,Pre-Master)。
Change Cipher Spec 客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。
Encrypted Handshake Message 结合之前所有通信参数的hash值与其它相关信息生成一段数据，采用协商密钥session secret与算法进行加密，然后发送给服务器用于数据与握手验证。

Server：New Session Ticket

为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS协议有两类会话缓存机制：会话标识Session ID 与 会话记录Session ticket。

Session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中 1M 内存约可以保存 4000个 Session ID 机器相关信息，占用服务器资源较多。
- 如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 Session ID，并保存对应的通信参数在服务器中。
- 如果客户端再次需要和该服务器建立连接，则在 Client Hello 中 Session ID 中携带记录的信息，发送给服务器。
- 服务器根据收到的 Session ID 检索缓存记录，如果没有检索到缓存过期，则按正常的握手过程进行。
- 如果检索到对应的缓存记录，则返回 Change Cipher Spec 与 Encrypted Handshake Message 信息，两个信息作用类似，Encrypted Handshake Message 是到当前的通信参数与 master_secret 的 Hash值。
- 如果客户端能够验证通过服务器加密数据，则客户端同样发送 Change Cipher Spec 与Encrypted Handshake Message 信息。
- 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
Session ticket 需要服务器和客户端都支持，属于一个扩展字段，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务资源很少。
- 如果客户端和服务器之间曾经建立了连接，服务器会在 New Session Ticket 数据中携带加密的 Session ticket 信息，客户端保存。
- 如果客户端再次需要和该服务器建立连接，则在 Client Hello 中扩展字段 Session Ticket 中携带加密信息，一起发送给服务器。
- 服务器解密 Session Ticket 数据，如果解密失败，则按照正常的握手过程进行；
- 如果解密成功，则返回 Change Cipher Spec 与 Encrypted Handshake Message 信息，两个信息作用与 Session ID中类似。
- 如果客户端能够验证通过服务器加密数据，则客户端同样发送 Change Cipher Spec 与Encrypted Handshake Message 信息。
- 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

二者对比，主要是保存协议信息的位置与方式不同，类似于 http 的 sessin 与 cookie。二者都存在的情况下,(nginx实现)优先使用 Session Ticket。

Server：Change Cipher Spec、Encrypted Handshake Message

服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 Random_C和 Random_S，计算得到协商密钥：enc_key=Fuc(random_C,random_S,Pre-Master)。计算之前所有接收信息的hash值，然后解密客户端发送的 Encrypted Handshake Message，验证数据和密钥的正确性。

Change Cipher Spec 验证通过之后，服务器同样发送 Change Cipher Spec 以告知客户端后续的通信都采用协商的密钥与算法进行通信。
Encrypted Handshake Message 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 Session Secret 与算法加密并发送到客户端。

握手结束

客户端计算所有接收信息的 Hash 值，并采用协商密钥解密 Encrypted Handshake Message，验证服务器发送的数据和密钥，验证通过则握手完成。

加密通信–Application Data

开始使用协商密钥与算法进行加密通信。注意：

服务器也可以要求验证客户端，即双向认证，可以在 Server Hello 过程要求发送 Client Certificate Request 信息，客户端在 Client Key Exchange 过程中先发送 Client Certificate 与 Certificate Verify Message 信息，证书的验证方式基本相同， Certificate Verify Message 是采用 Client 的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证。
根据使用的密钥交换算法的不同，如 ECC 等，协商细节略有不同，总体相似。
Sever Key Exchange 的作用是 Server Certificate 没有携带足够的信息时，发送给客户端以计算 pre-master，如基于 DH 的证书，公钥不被证书中包含，需要单独发送。
Change Cipher Spec 实际可用于通知对端改变当前使用的加密通信方式。
Alter message 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。

重建连接

重建连接(renegotiation) 即放弃正在使用的 TLS 连接，重新进行身份认证和密钥协商的过程，特点是不需要断开当前的数据传输就可以重新身份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程，当前 windows 2000 & XP 与 SSL 2.0不支持。

服务器重建连接服务器端重建连接一般情况是客户端访问受保护的数据时发生。基本过程如下：
- 客户端和服务器之间建立了有效 TLS 连接并通信。
- 客户端访问受保护的信息。
- 服务器端返回 Hello Request 信息。
- 客户端收到 Hello Request 信息之后发送 Client Hello 信息，开始重新建立连接。

客户端重建连接客户端重建连接一般是为了更新通信密钥。
- 客户端和服务器之间建立了有效 TLS 连接并通信。
- 客户端需要更新密钥，主动发出 Client Hello 信息。
- 服务器端收到 Client Hello 信息之后无法立即识别出该信息非应用数据，因此会提交给下一步处理，处理完之后会返回通知该信息为要求重建连接。
- 在确定重建连接之前，服务器不会立即停止向客户端发送数据，可能恰好同时或有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器。
- 服务器识别出重建连接请求之后，发送 Server Hello 信息至客户端。
- 客户端也同样无法立即判断出该信息非应用数据，同样提交给下一步处理，处理之后会返回通知该信息为要求重建连接。
- 客户端和服务器开始新的重建连接的过程。

密钥计算

上节提到了两个明文传输的随机数 Random_C 和 Random_S 与通过加密在服务器和客户端之间交换的 Pre-master，三个参数作为密钥协商的基础。本节讨论说明密钥协商的基本计算过程以及通信过程中的密钥使用。

计算 Key 涉及参数 Random Client 和 Random Server, Pre-master, Master secret, key material, 计算密钥时，服务器和客户端都具有这些基本信息，交换方式在上节中有说明，计算流程如下：

以下为一些重要的记录，可以解决部分爱深入研究朋友的疑惑：

PreMaster secret 前两个字节是 TLS 的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在 Client Hello 阶段，客户端会发送一份加密套件列表和当前支持的 SSL/TLS 的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能篡改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的 PreMaster 版本号跟之前 Client Hello 阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。
不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于 SSL 协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于 RSA 密钥交换算法来说，pre-master-key 本身就是一个随机数，再加上 hello 消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。 pre master 的存在在于 SSL 协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么 pre master secret 就有可能被猜出来，那么仅适用 pre master secret 作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master secret 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。