本文从协议层详细描述了 TLS/SSL 的握手过程
TLS 与 SSL
TLS (Transport Layer Safe)是传输层安全的缩写
SSL (Safe Socket Layer)是安全套接字层的缩写
TLS/SSL 都是加密数据和在 Internet 上移动数据时验证连接的加密协议。
那么TLS与 SSL之间有什么区别呢？
TLS 实际上只是SSL的更新版本。它修复了早期SSL协议中的一些安全漏洞。
总结：SSL 和 TLS 协议可以为通信双方提供识别和认证通道，从而保证通信的机密性和数据完整性。TLS 协议是从 Netscape SSL 3.0 协议演变而来的，不过这两种协议并不兼容，SSL 已经逐渐被 TLS 取代。
TLS 握手过程
TLS 握手的目的是为了建立安全连接，具体做的工作可概括为：
- 商定客户端和服务端所使用的 TLS 版本
- 商定双方需要的密码组合
- 客户端通过服务器的公匙和数字证书上的数字签名验证服务端的身份
- 生成会话密匙，用于握手完成后的对称加密密匙
TLS 握手细节
基于 TLS 的双向加密握手过程
- “client hello” 消息：客户端通过发送 “client hello” 消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本，支持的算法列表和密码组合以供服务器进行选择，还有一个 “client random” 随机字符串。
- “server hello” 消息：服务器发送 “server hello” 消息对客户端进行回应，该消息包含了服务器选择的加密算法，服务器选择的密码组合，数字证书和 “server random” 随机字符串。
- 客户端验证：客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程分步骤：
- 检查数字签名：客户端采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法
- 验证证书链
- 检查证书的有效期
- 检查证书状态是否是撤回、吊销状态
- “premaster secret”字符串：3 步解密得到服务器的公匙，使用公钥加密另一个随机字符串 “premaster secret (预主密钥)”后发送给服务器，只有对应的服务器的私钥才能解密。
- 服务器使用私钥：服务器使用私钥解密得到随机字符串 premaster secret。
- 生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
- 客户端就绪：客户端发送经过共享密钥 KEY 加密过的 “finished” 信号，为了防止握手过程遭到篡改，该消息的内容是前一阶段所有握手消息的MAC值。
- 服务器就绪：服务器发送经过共享密钥 KEY 加密过的 “finished” 信号，该消息的内容是前一阶段所有握手消息的 MAC 值。
- 达成安全通信：握手完成，双方使用对称加密进行安全通信。
第 8 与第 9 步用以防止握手本身遭受篡改。
证书链
证书链 (certificate chain)：也称为证书路径，是用于认证实体合法身份的证书列表，具体到 HTTPS 通信中，就是为了验证服务器的合法身份。之所以使用证书链，是为了保证根证书 (root CA certificate) 的安全，中间层可以看做根证书的代理，起到了缓冲的作用。
会话缓存握手
为了加快建立握手的速度，减少协议带来的性能降低和资源消耗(具体分析在后文)，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。
session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中 1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多;
session ticket 需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。
二者对比，主要是保存协商信息的位置与方式不同，类似与 http 中的 session 与 cookie。
二者都存在的情况下，(nginx 实现)优先使用 session_ticket。
- 会话标识 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 中携带加密信息，一起发送给服务器;
- 服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握手过程进行;
- 如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用与 session ID 中类似;
- 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
- 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
这里直接引用了 《HTTPS协议详解(四)：TLS/SSL握手过程》
重建连接
重建连接是指放弃正在使用的 TLS 连接，从新进行身份认证和密钥协商的过程，特点是不需要断开当前的数据传输就可以重新身份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。
服务器重建连接
服务器端重建连接一般情况是客户端访问受保护的数据时发生。基本过程如下：
- 客户端和服务器之间建立了有效 TLS 连接并通信;
- 客户端访问受保护的信息;
- 服务器端返回 hello_request 信息;
- 客户端收到 hello_request 信息之后发送 client_hello 信息，开始重新建立连接。
客户端重建连接
客户端重建连接一般是为了更新通信密钥。基本过程如下：
- 客户端和服务器之间建立了有效 TLS 连接并通信;
- 客户端需要更新密钥，主动发出 client_hello 信息;
- 服务器端收到 client_hello 信息之后无法立即识别出该信息非应用数据，因此会提交给下一步处理，处理完之后会返回通知该信息为要求重建连接;
- 在确定重建连接之前，服务器不会立即停止向客户端发送数据，可能恰好同时或有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器;
- 服务器识别出重建连接请求之后，发送 server_hello 信息至客户端;
- 客户端也同样无法立即判断出该信息非应用数据，同样提交给下一步处理，处理之后会返回通知该信息为要求重建连接;
- 客户端和服务器开始新的重建连接的过程；
密钥计算
- TLS/SSL 加密过程使用了对称加密+非对称加密和散列函数算法
- 对称加密的密匙是由是那个随机数 random_C + random_S + random_secret 生成
为什么要使用随机数？
不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于 SSL 协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于 RSA 密钥交换算法来说，pre-master-key 本身就是一个随机数，再加上 hello 消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。