SSL/TLS(4): TLS连接握手过程详细分析

SSL/TLS(1):基本概念通俗解释
SSL/TLS (2)：通俗解释SSL/TLS为什么安全
SSL/TLS(3): CA证书解释

前言

在前面的文章中，我们讲述了SSL/TLS相关概念和CA证书，本文通过wireshark抓取日志，来查看一下TLS的连接握手流程。握手的含义就是当client与server建立连接后，client和server需要针对TLS进行握手动作，握手的目的是为了商量加密算法和一些初始化，只有握手成功后，后面的对话才能加密和解密。

测试工具

我们以mqtt+TLS连接 mqtt broker为例，MQTT broker中已经配置好TLS和证书，mqtt client使用mqtt.fx工具模拟，由于是公网，为了安全，我们将 公网IP的部分地址打马赛克，整个连接过程如下图所示：

1. TCP连接过程

正如前面的文章介绍，SSL/TLS是一个加密协议，用于加密传输层，所以SSL/TLS是介于TCP和应用层之间的，所以TLS连接的开始，一定是TCP的3次握手，与服务器建立连接，如下图所示：

就是普通的TCP 3次握手，建立连接

2. SSL/TLS 握手过程

SSL/TLS的 握手过程基本如下图所示：

我们总结握手流程，客户端名称为Client，服务器名称为 Server，流程如下：

• 第1步：client给出协议版本号、1个客户端生成的随机数（client random），以及客户端支持的加密方法。
• 第2步：server选择一种client支持的加密算法，并给出数字证书CA，以及1个由服务器生成的随机数（server random）。
• 第3步：client确认数字证书CA的合法性，是否有效，然后根据前面两个随机数，生成1个新的随机数（premaster secret），并使用数字证书中的公钥，加密这个随机数，发送给client。
• 第4步： server使用自己的私钥，解密获取client发送过来的随机数（premaster secret）
• 第5步： client和server根据预定的加密方法，使用前面的3个随机数，生成对话密钥(session key)，后面client 和server就使用 对话密钥来 加密整个对话过程。

在SSL/TLS (2)：通俗解释SSL/TLS为什么安全 中我们分析了为什么SSL/TLS 安全，从上面的步骤也能看出，第1和2步都是明文传输，从第3步开始，第3个随机数通过公钥加密给server，因为采用了神奇的不对称加密算法，通过公钥加密的报文，必须通过私钥才能解开，所以对于监听者，只要没有私钥，就拿不到第3个随机数，那么后面的对话密钥，就更难破解了，再加上，上面的3个随机数，是随机生成的，就更增加了破解难度了。

上面的讲解，可能还是不够详细，接下来我们结合日志报文来进一步说明：

2.1 client hello

这是握手的第1步，抓包如下所示：

包含了随机数client random、客户端支持的加密算法（support ciphers）和SSL version等信息。

2.2 Server Hello、Certificate、Request、Done

2.2.1 Server Hello

这是第2步中的 server hello部分，server向client发送 server hello消息，这个消息会从client hello传过来支持的support ciphers中选择确定一份加密条件，另外还会生成一份随机数server random。

2.2.2 Certificate

这一步中，服务器将自己的公钥证书发给客户端，让客户端验证自己的身份，公钥证书里包含的内容，在前面的文章中已经讲过，这里不赘述。

2.2.3 Server Key Exchange

如果服务器使用DH算法，还会发送服务器使用的DH参数，RSA算法不需要这一步

2.2.4 Certificate Request

当我们采用SSL/TLS的双向认证时，服务器还会要求客户端上报自己的证书，对于安全性要求高的场景会用到，如下图所示：

注意： 这一步是可选的，对于SSL/TLS单向认证，就不需要这一步。

2.2.5 Server Hello Done

Server通知客户端 server hello 过程结束

2.3 certificate reply、client key exchange

2.3.1 certificate reply

在上一步中，server 会请求 client的证书，所以下一步，client理所应当的就要上报自己的证书，如下图所示：

可以看到，client 已经把自己的证书上报给server了，我们可以很容易的想到，server端应该会对client的证书做校验，一旦client的证书是非法的，会触发alert，终止连接。

2.3.2 client key exchange

这一步，client会 基于前面提到的两个随机数，再生成第3个随机数，然后通过server证书中的公钥，对第3个随机数加密，声称该一个密码PreMaster Key，然后传送给server，这里的关系如下：

• 随机数3 = f(随机数1， 随机数2）
• PreMaster = 公钥加密（随机数3）
  服务器收到PreMaster后，会使用自己的私钥解密，获取到随机数3的值，至此，client和server都知道了 这3个随机数了。
  有3个随机数来生成的秘钥不容易被暴力破解

2.4 Certificate Vertify

客户端会验证证书，比如验证证书的CN、证书时间等等，验证不通过会立刻发送 alert事件给服务器，终止握手过程。这个过程是客户端程序自动计算的，所以不会有抓包记录。
注意：我们在开发调试时，一般会采用mbedtls等开源库，加密、解密部分我们一般不会太深究，因为太复杂了，我们遇到问题的时候，大概率是证书验证这部分，因为要求证书的CN、证书时间等准确信息，后面我们会专门文章分析，如何调试这部分。

2.5 Change cipher spec （client）

这一步是客户端通知服务器，后面再发送的消息都会使用前面协商出来的秘钥进行加密，所以这个消息是一个事件消息。

2.6 Encrypted handshake message（client）

这一步对应的是Cleint的Finish消息，client将前面握手的消息生成摘要，再用协商好的秘钥进行加密，这是客户端发出的第一条加密消息， 服务端接收后会用秘钥解密，能解出来说明前面协商的秘钥是一致的，至此握手完成。

2.7 change cipher spec（server）

这一步是server通知客户端，后面再发送的消息使用加密，这也是一条事件消息，与前面的相对应。

2.8 Encrypted handshake message（server）

这一步是server的finish消息，服务端会将握手过程消息生成摘要，然后再用秘钥加密，这是服务器发出的第一条加密消息，客户端接收后会用秘钥解密，能解出来就说明协商成功。

3 Application Data

至此，双方已经完成了SSL/TLS的握手，已经协商出秘钥，后面所有应用层数据都会用这个秘钥加密后，再通过TCP进行传输。

小结

双向认证的完整流程如下：

• 1、TCP三次握手，建立连接。
• 2、client发送 client hello
• 3、server返回 server hello
• 4、server 返回 CA证书，server Key Exchange、请求客户端证书， server hello Done
• 5、client上报自己的证书给server，client key exchange，传输协商后的秘钥给server。
• 6、client验证server的证书，change cipher spec、encrypted handshake
• 7、server 发送 change cipher spec、encrypted handshake
• 8、握手协商完成，进行应用层面交互，通过前面的协商秘钥来加密。

单向认证会少几步，主要是服务器请求客户端证书部分，基本流程是一致的。