HTTPS协议详解：TLS/SSL握手过程

时间：03-13来源：作者：点击数：

1、握手与密钥协商过程

基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程

再看一张手绘时序图

(1).client_hello

在发送的 Client Hello 中会带上自己支持的加密算法，供服务端从中挑选。由于老旧客户端会支持一些不安全的加密算法，为了提高传输安全，通常会在服务端指定一个可用算法列表，最终使用的加密类型取决于二者的交集，并按服务端优先级取第一个；如果没有交集，直接终止会话。在 Nginx 中这个功能通过将 ssl_prefer_server_ciphers 设置为 on 开启。

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

• 支持的最高Tls协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;

• 客户端支持的加密套件 cipher suites 列表，每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);

• 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;

• 随机数 random_C，用于后续的密钥的生成;

• 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。

SSL报文格式可以大致分为2部分，Record层和 Data层，Record层中指定了后续数据的类型，SSL版本(一般来说固定)，以及后续数据的长度。

例如上图中显示的那样，SSL报文头部是TVL格式：

Content Type: Handshake

Version: TLS 1.0

Length: 121

这些表示后续的Data层是握手报文，TLS1.0格式，总长度是121字节。

而Data层，又有自己的格式，根据不同的类型，比如Client Hello，Certificate，等，有自己的格式（所以Record中的Content Type字段是必要的），并且不同的版本之间也有不同的格式，例如TLS1.0和SSL 3.0对Client key exchange报文有自己的组织方式（所以Record中的Version字段也是必要的）。长度字段有效的确定了单个SSL报文结束的位置，因为SSL报文承载与TCP之上，一个TCP段中存在多个SSL报文是非常常见的事情，如果没有字段描述单个SSL报文的长度，那么解析报文将变得不可能。

（a）Random

随机数，一共32字节，其中前4个字节使用系统当前时间，后28字节使用伪随机函数生成的随机数。4个字节以Unix时间格式记录了客户端的协调世界时间（UTC）。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数，那么时间是不断的上涨的，通过前4字节填写时间方式，有效的避免了周期性的出现一样的随机数。使得“随机”更加“随机”。随机数用来干什么？随机数是用来生成对称密钥的，我们后续讲到生成对称密钥的时候，会再次提到随机数。现在只需要记住“客户端生成了一个随机数，然后发送到的服务器”。

然而在具体的实现上，不同客户端行为不一样，IE会带时间，而Firefox就不带时间，因为它本身的含义就是随机数，而对端也不会校验这个时间（和tcp的时间戳完全不是一回事儿）。

随机数参与了SSL握手的 master key的计算、KDF计算、server_key_exchange的签名值的计算。属于混淆的一部分。

（b）Session id

标识了后面Session id的长度，但是对于一般新建的会话，Session id length都是0，如果Session id length有值，对于 SSL 2.0 Session id length0~16字节，其后的版本扩大到32字节。本报文中Session id length是0，后面就没有跟Session id，直接是Cipher suit length。下面是Session id不是0的报文：

一眼就能看出差别了把！Session id在会话复用中被用到，我们讲到会话复用的时候，会提及Session id，本章分析报文时，不会再提及Session id。

Session id并不一定是32字节，RFC规定可以0~32字节。只是Session id由服务器生成，服务器普遍采用OpenSSL，而OpenSSL基本只生成32字节的session id，如果碰到其他字节长度的Session id，切莫认为是异常client hello。

（c）Cipher Suite

Cipher Suits Length：含义同Session id length

Cipher Suits：加密套件，它列出了客户端能够支持的加密方式、算法等信息。不同的加密套件性能不一样，安全性不一样，也导致了SSL交互报文的不一样。

最常见的如TLS_RSA_WITH_RC4_128_SHA1，它表示我们密钥交换使用RSA，身份认证算法用RSA(咦，怎么和之前说的不一样，身份认证难道不是证书吗？是的，证书是身份认证一部分，我们还需要用RSA去验证证书，后面会讲到)，对称加密算法使用RC4，摘要算法使用SHA1。再举个例子，TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA1，它表示，密钥交换算法使用ECDHE（短暂椭圆曲线），身份认证算法使用ECDSA，对称加密算法使用AES_128_CBC，摘要算法使用SHA1。

客户端把自己所支持的加密套件全部发送给服务器，服务器会从中选择一个加密套件。这个我们将在后面的Server hello中讲到。

每个加密套件用2字节表示，这里一共12个加密套件，所以理所当然的，Cipher Suits Length是12 * 2 = 24字节。

（d）Compression Methods

目前没见过使用压缩算法的实例。这里不再拓展。

（e）Extension

拓展字段的存在，是因为SSL协议起草之初有些功能没有考虑到，后续这些功能被加进RFC，而为了兼容SSL，把这些功能的描述放到Extension中。Extension很大程度上影响了SSL的流程，很多人觉得某些SSL连接的报文好奇怪、和正常接触的SSL报文不一样，就是因为Extension起的作用。

TLS 1.3 就借助 extension 发送不同curve的pubkey来减少RTT，后续有机会再说。这里介绍主流的一些拓展。

（a）Renegotiation info：

如果是重新协商（即加密的hello），那么会带上上次协商的12字节的finished，如果是新hello请求，那么里面字段为0。

切记及时服务器端不支持renegotiation，在server hello响应时也需要带上这个拓展（前提是客户端有这个拓展或者有等价的EMPTY_SCSV，因为我在实现上碰到过如果不带该拓展，导致客户端结束连接的情况）。

（b）Server_name(SNI):

SSL存在验证证书的时候，有这么一个判断：比较“浏览器输入的地址”和“获取的证书的名称”，如果一样，那么接着验证，如果不一样，那么认为证书是不可信的。

假设有公司的域名存在2个：www.123.com和www.567.com，它们对应的ip都是222.12.34.56，假设服务证书的名字是 ”www.123.com” ，那么从 ”www.567.com” 访问过来的用户无法信任服务器证书，总之，总有一个域名访问会导致客户端无法信任服务器。为了解决这个问题，客户端在client hello中带上server name 拓展（如果使用ip地址进行访问，那么就不会有server name拓展），它会捎带上域名地址，服务器解析到server name后，就会根据server name中的域名，选择合适的证书。

（c）Elliptic_curves/ec_point_formats:

使用椭圆曲线密钥交换算法的时候用到，里面列举了自己支持的椭圆曲线算法，供服务器选择。

（d）application_layer_negotiation(ALPN):

用以描述支持的上层协议，h2、http/1.1、spdy等。可以把他想象成IP头中的protocol，描述了上层是TCP还是UDP还是ICMP。

目前主流浏览器，若要使用HTTP2，则必须使用这个拓展。

（e）status_request

请求OCSP，服务器可以发送cettificate status到客户端，里面带上ocsp的信息。

（f）signature_algorithms

表示自己支持的签名算法，服务器收到这个拓展，在进行例如server key exchange签名等操作时，需要参考客户端这个拓展。

（g）SessionTicket TLS

Session ticket会话复用时使用，讲到session ticket时再说。

注意，老的一些客户端没有extensions length字段，而新的客户端如果不携带extension，他也会有extensions length，只是为0。所以判断有没有extension 存在的方式是compression methods是否在client hello的最后

(2).server_hello+server_certificate+sever_hello_done

• server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;

• server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;

• server_key_exchange, 如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步

• certificate_request, Certificate Request 是服务端要求客户端上报证书，这一步是可选的，对于安全性要求高的场景会用到

• server_hello_done，通知客户端 server_hello 信息发送结束;

主要包含几点重要的信息

1：确定协商使用的TLS版本号（TLS1.0 or TLS 1.1 or TLS 1.2）。

2：随机数（用来生成主密钥和kdf）

3：session id（sessionid会话复用需要带上，当然命中session

ticket时也需要带上）

4：使用的加密套件（根据客户端提供的算法列表、服务器证书类型、服务器配置决定）

5：拓展。一般会带上空的renegotiation info（前提是客户端提供了EMPTY_SCSV加密套件或者有renegotiation

info拓展），以表示自己支持secure renegotiation，我碰到过不带次拓展，客户端直接断开的情况。原因未知。

(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)

(d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;

(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，验证数据和密钥正确性;

(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 等，协商细节略有不同，总体相似;

(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 中携带记录的信息，发送给服务器;

(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 中携带加密信息，一起发送给服务器;

(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) 客户端访问受保护的信息;

(d) 客户端收到 hello_request 信息之后发送 client_hello 信息，开始重新建立连接。

(2).客户端重建连接

客户端重建连接一般是为了更新通信密钥。

(a) 客户端和服务器之间建立了有效 TLS 连接并通信;

(b) 客户端需要更新密钥，主动发出 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;

以下为一些重要的记录，可以解决部分爱深入研究朋友的疑惑，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 master secret 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

(2).密钥使用

Key 经过12轮迭代计算会获取到12个 hash 值，分组成为6个元素，列表如下：