通俗易懂的 TLS 协商过程

通俗易懂的 TLS 协商过程

当我们通过 HTTPS 建立安全连接时，会有一次特别的 "握手"，这就是 TLS 协商。它的作用可大啦，要决定用哪种密码给通信加密，验证服务器是不是靠谱，在真正传输数据前把安全连接搭建好。在正式发送内容请求之前，得在客户端和服务器之间来回跑五次呢。

虽说多了这些建立安全连接的步骤，让我们等待页面加载的时间变长了，但为了让浏览器和 web 服务器之间传的数据不被第三方偷偷解开，这点延迟还是很值得的。要是想了解这里面报文交换的详细情况，可以用抓包工具，比如 Charles 或者 wireshark 来一探究竟。

TLS 是建立在 TCP 之上的。所以，肯定得先通过三次 TCP 握手把 TCP 连接建立起来，然后才进行 TLS 的建立。下面详细讲讲 TLS 协商的过程：

1. Client Hello（客户端问候）

   客户端支持的加密算法不一样，所以它得把自己能支持的加密套件（Cipher Suite）发给服务器。打个比方，加密套件就像是一个包含多种加密 "工具" 的工具箱，客户端告诉服务器自己这个 "工具箱" 里都有啥。同时呢，客户端会生成一个随机数，自己留一份，也发给服务器。这个随机数就像一个只有客户端知道的小秘密，现在也分享给服务器一部分，它在后续密钥生成等环节会发挥关键作用。这就像是客户端跟服务器说："嘿，我这儿有这些加密的办法，这是我生成的一个随机小秘密。"

2. Server Hello（服务器问候）

   • ServerCertificate 报文：服务器收到客户端的问候后，会给客户端发送经过 CA 认证的数字证书。这个证书就像是服务器的身份证，用来证明服务器的身份。想象一下，在现实生活中，我们通过身份证证明自己是谁，服务器通过数字证书让客户端确认它的真实身份。同时，服务器也会生成一个随机数，自己存着，也发给客户端。这个服务器生成的随机数同样会参与到后续重要的计算中。
   • Server Hello Done 报文：这就好比服务器跟客户端说："我第一阶段的事儿说完啦。" 意味着服务器宣告第一阶段的客户端服务端握手协商结束。此时，服务器已经向客户端表明了自己的身份，并提供了必要的随机数。
   • 可选：Certificate Request 报文：在有些必要的情况下，服务器会要求客户端也发送证书来验证身份。比如，某些企业内部的网络服务，不仅要确认服务器的合法性，也需要验证客户端是否是企业内部授权的设备，这时就会用到这个报文。
   • 可选：Server Key Exchange 报文：要是 CA 认证的数字证书里的信息不太够，服务器还能再发些补充信息过来。例如，当服务器使用的加密算法需要额外参数时，就可以通过这个报文传递。

3. Client Finish（客户端完成）

   • Client Key Exchange 报文：客户端收到服务器的 CA 数字证书后，会检查证书是不是真的。验证通过后，用 CA 的公钥解密，就能拿到服务器的公钥。在这个报文中，有一个新的随机数，叫 Pre - master key/secret。它就像是一个新的 "秘密拼图碎片"，和之前的随机数一起用来构建最终的加密密钥。还有个通知，告诉服务器之后的信息要用双方商量好的加密方法和密钥来发送。另外，这里面还有用商量好的 HASH 算法，对之前所有信息算出来的 HASH 值，用来给服务器检查。这些内容都会用服务器的公钥加密后发给服务器。这就像是客户端精心准备了一个包裹，里面有新秘密、加密通信通知以及之前信息的 "摘要凭证"，并且用服务器的公钥锁好后寄给服务器。
   • ClientCipherSpec 报文：客户端跟服务器说："从现在起，咱们通信就用商量好的加密算法算出的对称密钥来加密啦。" 这个对称密钥是用之前客户端和服务器各自生成的随机数，再加上这个新的 Pre - master key/secret 一起算出来的。就好像大家一起用各自的拼图碎片（随机数）和新得到的一块（Pre - master key/secret）拼出了一把独特的 "加密钥匙"，之后就用这把钥匙来加密通信内容。
   • Finished 报文：这个报文里有之前所有报文的检验值，并且用服务器的公钥加密了。它就像是一个对之前所有协商过程的 "总结确认书"，经过加密确保其完整性和安全性，让服务器可以验证之前的协商是否正确无误。
   • 可选：ClientCertificate 报文：要是服务器之前要求客户端发证书，那客户端就得把 CA 数字证书发过去。这是客户端向服务器证明自己身份的方式，类似于服务器用数字证书证明自己一样。
   • 可选：CertificateVerify 报文：如果服务器要了 CA 数字证书，客户端就得用 HASH 算法算一个服务器发来信息的摘要。这一步进一步加强了客户端身份验证的可靠性，通过对服务器信息生成摘要，与服务器预期的摘要进行比对，确认客户端的合法性。

4. Server Finish（服务器完成）

   • 服务器用自己的私钥解密客户端发来的 Finished 报文，检查里面的检验值对不对。这就像是服务器收到客户端的 "总结确认书" 后，用自己的 "私钥钥匙" 打开，看看里面的内容是否与自己的预期一致，以此确认整个协商过程的准确性。
   • ClientCipherSpec 报文：这里服务器也再次确认，之后通信要用那个对称密钥 session key/secret 加密啦。这是服务器对客户端提出的加密方式和密钥的再次确认，确保双方在加密通信的规则上达成一致。
   • Finished 报文：这就标志着 TLS 连接成功建立好啦。此时，客户端和服务器都完成了复杂的协商过程，准备好使用共同确定的加密方式和密钥进行安全通信。

5. TLS 握手成功：从这之后，客户端和服务器就通过那个对称密钥 session key/secert 加密来通信啦。所有传输的数据都会被这把 "加密钥匙" 加密，在网络中传输时即使被第三方截获，没有正确密钥也无法解密查看内容。

其实还有个小知识，在datatracker.ietf.org/doc/html/rf...里提到，客户端在发 Client key Exchange 的时候，就可以顺便把应用数据发出去，这样 TLS 就只需要 1RTT（往返时间）啦。这种优化方式能够在一定程度上减少 TLS 协商带来的延迟，提高数据传输的效率。

为什么 TLS 协商需要三个随机数呢？

1. 从密码学的角度来说：很多像 ISO/IEC、RFC 这样的标准协议都规定，在认证和密钥协商的时候，得有好几个随机数参与计算。客户端和服务器各自生成的随机数，会用来算会话密钥。再加上协议里其他的一些随机因素，就能让攻击者更难预测和攻击我们的通信。例如，如果没有随机数，攻击者可能更容易通过分析大量通信数据，找到加密模式的规律从而破解加密。而随机数的加入就像给加密过程添加了无数的 "变量"，大大增加了破解难度。

2. 从协商的三个阶段来看

   • 服务器生成一个随机数（比如叫 R1），它让客户端用这个随机数去参与加密或者签名计算，这样就能看看客户端是不是真的是它说的那个客户端。这就好像服务器给客户端出了一道 "加密小考题"，里面包含了这个随机数，只有真正合法的客户端才能按照正确的方式解答（完成加密或签名计算）。
   • 客户端也生成一个随机数（比如叫 R2），让服务器用这个随机数去计算，这样能保证服务器给的回应是新算出来的，不是之前存好的旧回应。例如，防止攻击者重放之前截取的服务器回应来欺骗客户端，客户端通过让服务器基于新随机数计算，确保每次得到的都是实时、有效的回应。
   • 还有一个共享的会话随机数（比如叫 R3），这个在后续通信里会作为会话密钥的一部分，保证每次会话加密的内容都不一样。即使攻击者破解了一次会话的密钥，由于每次会话的随机数不同，后续会话依然安全，就像每次都换一把新的 "加密锁"。

3. 对于密钥协商很重要：这些随机数能确保每次会话的密钥都是独一无二的。要是没有这些随机数，攻击者可能就能通过分析不同会话密钥之间的关系，把密钥给破解了，有了这些随机数，就能很好地防止这种情况发生。 比如，攻击者试图通过观察多个会话中固定部分的加密数据，猜测密钥规律，但由于随机数的存在，每次加密数据的起始点和变化规律都不同，让攻击者无从下手。