2023年7月3日发(作者：)

ssl协议wireshark抓包分析1、握⼿与密钥协商过程基于RSA握⼿和密钥交换的客户端验证服务器为⽰例详解TLS/SSL握⼿过程

再看⼀张⼿绘时序图(1).client_hello 客户端发起请求，以明⽂传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下： · ⽀持的最⾼TSL协议版本version，从低到⾼依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使⽤低于 TLSv1 的版本; · 客户端⽀持的加密套件 cipher suites 列表， 每个加密套件对应前⾯ TLS 原理中的四个功能的组合：认证算法 Au (⾝份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验); · ⽀持的压缩算法 compression methods 列表，⽤于后续的信息压缩传输; · 随机数 random_C，⽤于后续的密钥的⽣成; · 扩展字段 extensions，⽀持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作⽤。(2).server_hello+server_certificate+sever_hello_done · server_hello, 服务端返回协商的信息结果，包括选择使⽤的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法compression method、随机数 random_S 等，其中随机数⽤于后续的密钥协商; · server_certificates, 服务器端配置对应的证书链，⽤于⾝份验证与密钥交换; · server_hello_done，通知客户端 server_hello 信息发送结束;(3).证书校验 客户端验证证书的合法性，如果验证通过才会进⾏后续通信，否则根据错误情况不同做出提⽰和操作，合法性验证包括如下： · 的可信性 trusted certificate path，⽅法如前⽂所述; · 证书是否吊销 revocation，有两类⽅式离线 CRL 与在线 OCSP，不同的客户端⾏为会不同; · 有效期 expiry date，证书是否在有效时间范围; · 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message (a) client_key_exchange，合法性验证通过之后，客户端计算产⽣随机数字 Pre-master，并⽤证书公钥加密，发送给服务器; (b) 此时客户端已经获取全部的计算协商密钥需要的信息：两个明⽂随机数 random_C 和 random_S 与⾃⼰计算产⽣的 Pre-master，计算得到协商密钥; enc_key=Fuc(random_C, random_S, Pre-Master) (c) change_cipher_spec，客户端通知服务器后续的通信都采⽤协商的通信密钥和加密算法进⾏加密通信; (d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息⽣成⼀段数据，采⽤协商密钥 sessionsecret 与算法进⾏加密，然后发送给服务器⽤于数据与握⼿验证;(5).change_cipher_spec+encrypted_handshake_message (a) 服务器⽤私钥解密加密的 Pre-master 数据，基于之前交换的两个明⽂随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master); (b) 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性; (c) change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采⽤协商的密钥与算法进⾏加密通信; (d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息⽣成⼀段数据并采⽤协商密钥 session secret 与算法加密并发送到客户端;(6).握⼿结束 客户端计算所有接收信息的 hash 值，并采⽤协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握⼿完成;(7).加密通信 开始使⽤协商密钥与算法进⾏加密通信。注意： (a) 服务器也可以要求验证客户端，即双向认证，可以在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送client_certificate与certificate_verify_message 信息，证书的验证⽅式基本相同，certificate_verify_message 是采⽤client的私钥加密的⼀段基于已经协商的通信信息得到数据，服务器可以采⽤对应的公钥解密并验证; (b) 根据使⽤的密钥交换算法的不同，如 ECC 等，协商细节略有不同，总体相似; (c) sever key exchange 的作⽤是 server certificate 没有携带⾜够的信息时，发送给客户端以计算 pre-master，如基于 DH 的证书，公钥不被证书中包含，需要单独发送; (d) change cipher spec 实际可⽤于通知对端改版当前使⽤的加密通信⽅式，当前没有深⼊解析; (e) alter message ⽤于指明在握⼿或通信过程中的状态改变或错误信息，⼀般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，⽤户取消操作等，收到告警信息之后，通信会被断开或者由接收⽅决定是否断开连接。2、会话缓存握⼿过程 为了加快建⽴握⼿的速度，减少协议带来的性能降低和资源消耗(具体分析在后⽂)，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录session ticket。

session ID 由服务器端⽀持，协议中的标准字段，因此基本所有服务器都⽀持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占⽤服务器资源较多;

session ticket 需要服务器和客户端都⽀持，属于⼀个扩展字段，⽀持范围约60%(⽆可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占⽤服务器资源很少。

⼆者对⽐，主要是保存协商信息的位置与⽅式不同，类似与 http 中的 session 与 cookie。

⼆者都存在的情况下，(nginx 实现)优先使⽤ session_ticket。

握⼿过程如下图: 注意：虽然握⼿过程有1.5个来回，但是最后客户端向服务器发送的第⼀条应⽤数据不需要等待服务器返回的信息，因此握⼿延时是1*RTT。(1).会话标识 session ID (a) 如果客户端和服务器之间曾经建⽴了连接，服务器会在握⼿成功后返回 session ID，并保存对应的通信参数在服务器中; (b) 如果客户端再次需要和该服务器建⽴连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器; (c) 服务器根据收到的 session ID 检索缓存记录，如果没有检索到货缓存过期，则按照正常的握⼿过程进⾏; (d) 如果检索到对应的缓存记录，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作⽤类似，encrypted_handshake_message 是到当前的通信参数与 master_secret的hash 值; (f) 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息; (g) 服务器验证数据通过，则握⼿建⽴成功，开始进⾏正常的加密数据通信。(2).会话记录 session ticket (a) 如果客户端和服务器之间曾经建⽴了连接，服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息，客户端保存; (b) 如果客户端再次需要和该服务器建⽴连接，则在 client_hello 中扩展字段 session_ticket 中携带加密信息，⼀起发送给服务器; (c) 服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握⼿过程进⾏; (d) 如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作⽤与 session ID 中类似; (f)如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息; (g) 服务器验证数据通过，则握⼿建⽴成功，开始进⾏正常的加密数据通信。3、重建连接 重建连接 renegotiation 即放弃正在使⽤的 TLS 连接，从新进⾏⾝份认证和密钥协商的过程，特点是不需要断开当前的数据传输就可以重新⾝份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程，当前 windows 2000 & XP 与 SSL 2.0不⽀持。

(1).服务器重建连接 服务器端重建连接⼀般情况是客户端访问受保护的数据时发⽣。基本过程如下： (a) 客户端和服务器之间建⽴了有效 TLS 连接并通信; (b) 客户端访问受保护的信息; (c) 服务器端返回 hello_request 信息; (d) 客户端收到 hello_request 信息之后发送 client_hello 信息，开始重新建⽴连接。(2).客户端重建连接客户端重建连接⼀般是为了更新通信密钥。 (a) 客户端和服务器之间建⽴了有效 TLS 连接并通信; (b) 客户端需要更新密钥，主动发出 client_hello 信息; (c) 服务器端收到 client_hello 信息之后⽆法⽴即识别出该信息⾮应⽤数据，因此会提交给下⼀步处理，处理完之后会返回通知该信息为要求重建连接; (d) 在确定重建连接之前，服务器不会⽴即停⽌向客户端发送数据，可能恰好同时或有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器; (e) 服务器识别出重建连接请求之后，发送 server_hello 信息⾄客户端; (f) 客户端也同样⽆法⽴即判断出该信息⾮应⽤数据，同样提交给下⼀步处理，处理之后会返回通知该信息为要求重建连接; (g) 客户端和服务器开始新的重建连接的过程。4、密钥计算上节提到了两个明⽂传输的随机数 random_C 和 random_S 与通过加密在服务器和客户端之间交换的 Pre-master，三个参数作为密钥协商的基础。本节讨论说明密钥协商的基本计算过程以及通信过程中的密钥使⽤。

(1).计算 Key

涉及参数 random client 和 random server, Pre-master, Master secret, key material, 计算密钥时，服务器和客户端都具有这些基本信息，交换⽅式在上节中有说明，计算流程如下： (a) 客户端采⽤ RSA 或 Diffie-Hellman 等加密算法⽣成 Pre-master; (b) Pre-master 结合 random client 和 random server 两个随机数通过 PseudoRandomFunction(PRF)计算得到 Master secret; (c) Master secret 结合 random client 和 random server 两个随机数通过迭代计算得到 Key material;以下为⼀些重要的记录，可以解决部分爱深⼊研究朋友的疑惑，copy的材料，分享给⼤家： (a) PreMaster secret 前两个字节是 TLS 的版本号，这是⼀个⽐较重要的⽤来核对握⼿数据的版本号，因为在 Client Hello 阶段，客户端会发送⼀份加密套件列表和当前⽀持的 SSL/TLS 的版本号给服务端，⽽且是使⽤明⽂传送的，如果握⼿的数据包被破解之后，攻击者很有可能串改数据包，选择⼀个安全性较低的加密套件和版本给服务端，从⽽对数据进⾏破解。所以，服务端需要对密⽂中解密出来对的PreMaster 版本号跟之前 Client Hello 阶段的版本号进⾏对⽐，如果版本号变低，则说明被串改，则⽴即停⽌发送任何消息。(copy) (b) 不管是客户端还是服务器，都需要随机数，这样⽣成的密钥才不会每次都⼀样。由于 SSL 协议中证书是静态的，因此⼗分有必要引⼊⼀种随机因素来保证协商出来的密钥的随机性。 对于 RSA 密钥交换算法来说，pre-master-key 本⾝就是⼀个随机数，再加上 hello 消息中的随机，三个随机数通过⼀个密钥导出器最终导出⼀个对称密钥。 pre master 的存在在于 SSL 协议不信任每个主机都能产⽣完全随机的随机数，如果随机数不随机，那么 pre master secret 就有可能被猜出来，那么仅适⽤ pre master secret 作为密钥就不合适了，因此必须引⼊新的随机因素，那么客户端和服务器加上 pre mastersecret 三个随机数⼀同⽣成的密钥就不容易被猜出了，⼀个伪随机可能完全不随机，可是三个伪随机就⼗分接近随机了，每增加⼀个⾃由度，随机性增加的可不是⼀。(2).密钥使⽤ Key 经过12轮迭代计算会获取到12个 hash 值，分组成为6个元素，列表如下： (a) mac key、encryption key 和 IV 是⼀组加密元素，分别被客户端和服务器使⽤，但是这两组元素都被两边同时获取; (b) 客户端使⽤ client 组元素加密数据，服务器使⽤ client 元素解密;服务器使⽤ server 元素加密，client 使⽤ server 元素解密; (c) 双向通信的不同⽅向使⽤的密钥不同，破解通信⾄少需要破解两次; (d) encryption key ⽤于对称加密数据; (e) IV 作为很多加密算法的初始化向量使⽤，具体可以研究对称加密算法; (f) Mac key ⽤于数据的完整性校验;（3）.数据加密通信过程 (a) 对应⽤层数据进⾏分⽚成合适的 block; (b) 为分⽚数据编号，防⽌重放攻击; (c) 使⽤协商的压缩算法压缩数据; (d) 计算 MAC 值和压缩数据组成传输数据; (e) 使⽤ client encryption key 加密数据，发送给服务器 server; (f) server 收到数据之后使⽤ client encrytion key 解密，校验数据，解压缩数据，重新组装。注：MAC值的计算包括两个 Hash 值：client Mac key 和 Hash (编号、包类型、长度、压缩数据)。5、抓包分析关于抓包不再详细分析，按照前⾯的分析，基本的情况都能够匹配，根据平常定位问题的过程，个⼈提些认为需要注意的地⽅：

(1).抓包 HTTP 通信，能够清晰的看到通信的头部和信息的明⽂，但是 HTTPS 是加密通信，⽆法看到 HTTP 协议的相关头部和数据的明⽂信息，

(2).抓包 HTTPS 通信主要包括三个过程：TCP 建⽴连接、TLS 握⼿、TLS 加密通信，主要分析 HTTPS 通信的握⼿建⽴和状态等信息。

(3).client_hello

根据 version 信息能够知道客户端⽀持的最⾼的协议版本号，如果是 SSL 3.0 或 TLS 1.0 等低版本协议，⾮常注意可能因为版本低引起⼀些握⼿失败的情况;

根据 extension 字段中的 server_name 字段判断是否⽀持SNI，存在则⽀持，否则不⽀持，对于定位握⼿失败或证书返回错误⾮常有⽤;

会话标识 session ID 是标准协议部分，如果没有建⽴过连接则对应值为空，不为空则说明之前建⽴过对应的连接并缓存;

会话记录 session ticke t是扩展协议部分，存在该字段说明协议⽀持 sesssion ticket，否则不⽀持，存在且值为空，说明之前未建⽴并缓存连接，存在且值不为空，说明有缓存连接。

(4).server_hello

根据 TLS version 字段能够推测出服务器⽀持的协议的最⾼版本，版本不同可能造成握⼿失败; 基于 cipher_suite 信息判断出服务器优先⽀持的加密协议;

(5).ceritficate

服务器配置并返回的证书链，根据证书信息并于服务器配置⽂件对⽐，判断请求与期望是否⼀致，如果不⼀致，是否返回的默认证书。

(6).alert

告警信息 alert 会说明建⽴连接失败的原因即告警类型，对于定位问题⾮常重要。