SSL握手流程解析

HTTPS（HTTP Secure）是对HTTP的增强，用于互联网加密通信中。在HTTPS通信中使用TLS或者TLS的前身SSL作为加密协议。所以HTTPS协议也被称为HTTP over TLS或者HTTP over SSL.

在SSL/TLS通信中，首先要通过握手来协商获取客户端和服务器通信要使用的密钥。

在SSL/TLS握手过程中需要协商的内容包括：

• 通信要使用的协议版本
• 选择一种加密算法
• 客户端与服务端通过数字证书来校验对方的身份
• 使用非对称加密算法来生成一个密钥（shared secret key），以此来解决密钥分发问题。然后使用更快的对称加密方式进行通信。

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

1. SSL/TLS客户端发送一个”client hello”消息，其中包括了一些基础信息如客户端要使用的SSL/TLS版本，客户端支持的加密套件。消息中还包含了一个由客户端生成用于后续计算的随机数。协议还允许”client hello”消息中携带客户端支持的数据加密算法
2. SSL/TLS服务端收到客户端的握手消息后，响应一个”server hello”消息，其中包含服务端选择的加密套件，sessionID，和另外一个随机字节串。”server hello” 消息还发送了他的电子证书。如果服务端需要认证客户端的身份，则服务端需要发送一个”client certificate request”请求来获取客户端的证书，请求里包含服务端支持的证书类型和支持的CA的DN信息（如CN=Litware,OU=Docs, Adatum,DC=Fabrikam,DC=COM由一系列RDN组成，常见的RDN如DC, CN, OU, O等）
3. SSL/TLS客户端校验服务端证书的合法性。
4. SSL/TLS客户端发送一个使用服务端证书公钥加密的随机字节串Pre-Master Secret，用于客户端和服务端计算用于后续消息加密的secret key
5. 如果SSL/TLS服务端发送了一个”client certificate request”, 客户端需要发送自己的证书，还有一个使用自己私钥加密的随机串，或者一个”no digital certificate alert”。这个alert只是一个警告，但是如果客户端鉴权是必须的话，握手过程会因此失败。
6. SSL/TLS校验客户端的证书合法性
7. SSL/TLS客户端发给服务端一个”finished”消息，使用最终计算得到的Master key(根据1中的客户端随机数，2中的服务端随机数以及4中的Pre-Master Secret计算得到。因为Pre-Master Secret使用证书公钥加密，所以保证整个密钥的私密性)加密，表示握手过程客户端结束
8. SSL/TLS服务端发送一个使用计算得到的Master secret 信息加密的”finished”消息，表示服务端的握手过程结束。

握手过程中提到的加密套件是指在SSL/TLS通信过程中，客户端和服务端使用的加密算法的组合，这些算法通常包括：密钥交换算法、对称加密算法、消息认证码

其中密钥交换算法 用于双方交换密钥使用的加密算法。

对称加密算法 用于通信过程中的消息加密

消息认证码 带密钥的Hash函数，用于通信双方验证，保证消息完整性。 在发送数据前，发送方使用该算法的散列函数计算数据的摘要值，用户密钥加密摘要值获得消息认证码，然后和数据一起发送。接收方在收到报文后，利用会话密钥还原摘要值，同时利用散列函数计算收到的数据的摘要值，如果相同则认为数据完整未被篡改，报文通过认证。

另外，加密套件也可以包含签名算法和鉴权算法用于帮助客户端和服务端的鉴权。

每一个加密套件都有一个唯一的名字用于标示和描述使用的算法，名字的每一部分都标示不同的加密算法，例如下面一个加密套件：

TLS_RSA_WITH_3DES_EDE_CBC_SHA

• TLS 定义了这个加密套件是为哪个协议提供的，通常都是TLS
• RSA 标示了使用的密钥交换算法。
• 3DES_EDE_CBC 表示消息通信过程中使用的块加密算法。
• SHA 表示通信过程中校验消息合法性的消息认证算法

SSL/TLS握手过程示意图：

下面我们来抓包分析一下SSL的握手过程

以下是一个SSL握手过程的抓包，是我们访问百度的SSL握手过程

其中几个关键的消息截图如下：

Client Hello消息：

Server Hello消息：

其中涉及几个新消息：

**ServerKeyExchange消息：**只有在服务端Certificate证书消息不能包含足够数据来让客户端交换一个pre-master secret的时候才会发送，这是什么意思呢，就是在一些密钥交换算法中如本例中协商使用的TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256加密套件中使用的密钥交换算法ECDHE_RSA算法以及另外一些如DHE_DSS, DHE_RSA,DH_Anon算法，这些算法的公钥不是存在证书中，而是在使用时现生成，防止公钥存放时间过长增加受攻击的风险。

而这样的交换算法需要双方共同来完成。

这个过程下图虽然不太准确但是形象的描述了这个过程

当然在实际过程中不是简单的混合那个简单，混合分离的成本实际上是比较低的，下面的图描述的是DH交换算法：

New Session Ticket消息

实际上SSL/TLS握手的成本比较高，所有SSL/TLS也会保存会话下次连接时不需要再做这么复杂的握手流程，其中有基于Session ID的会话恢复和基于Session Ticket的会话恢复，Session ID就是服务端为每次的会话生成并记录一个ID并发送给客户端，在重新连接的时候，客户端向服务端发送该ID，服务端根据ID查找自己的会话记录，重用之前的加密参数。

而SessionTicket的思想类似于Cookie，服务器将Ticket数据发给客户端，Ticket中包含加密参数，当重连时，客户端将ticket发送给服务端

而New Session Ticket消息就是服务端将生成的Ticket信息加密发送给客户端。