TLS交互

Thank Zhihao Tao for your hard work. The document spent countless nights and weekends, using his hard work to make it convenient for everyone.
If you have any questions, please send a email to zhihao.tao@outlook.com

---

1. 基本过程

1. 客户端向服务器端索要并验证公钥。
2. 双方协商生成"对话密钥"。
3. 双方采用"对话密钥"进行加密通信。

2. 握手阶段

协商对话密钥的过程，又称为"握手阶段"（handshake）。"握手阶段"涉及四次通信，所有通信都是明文的。握手协议是一系列顺序消息，它们协商数据传输会话的安全参数。

后文以浏览器访问https://www.baidu.com/为例。

2.1 ClientHello

客户端先向服务器发出加密通信的请求，ClientHello请求。客户端主要向服务器提供以下信息：

• 版本号。客户端发送其支持的最高版本相对应的版本号。版本2用于SSL 2.0，版本3用于SSL 3.0，版本3.1用于TLS。
  

• 随机生成的数据。ClientRandom[32]，一个随机值，是一个4字节的客户端的日期时间和一个28字节的随机生成的数字组成，该数字最终将与服务器随机值一起使用，以生成一个主密钥，从该密钥中进行加密密钥将被派生。
  

• 会话标识（如果有）。包含有sessionID可以使客户端能够恢复先前的会话。恢复上一个会话可能很有用，因为创建新会话需要进行占用大量处理器资源的公钥操作，可以通过恢复具有已建立会话密钥的现有会话来避免这种情况。由sessionID标识的先前的会话信息存储在相应的客户端和服务器会话缓存中。
  

• 密码套件。客户端上可用的密码套件列表。密码套件的示例是TLS_RSA_WITH_DES_CBC_SHA，其中TLS是协议版本，RSA是将用于密钥交换的算法，DES_CBC是加密算法（在CBC模式下使用56位密钥），而SHA是哈希函数。
  

• 压缩算法。请求的压缩算法（当前不支持）。
  

• 拓展信息。本文不再详细描述。
  

2.2 SeverHello

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容:

• 版本号。服务器发送双方都支持的最高版本号。这是较低的值：服务器支持的最高版本号和客户端问候消息中发送的版本。
  

• 随机生成的数据。ServerRandom[32]（随机值）是服务器日期和时间的4字节数字加上28字节的随机生成数字，该数字最终将与客户机随机值一起使用，以生成一个主密钥，从中导出加密密钥。

• 会话标识（如果有）。这可以是下面三个选择之一:

  • 新的会话ID。客户端未指示要恢复的会话，因此生成了新的ID。当客户端指示要恢复的会话但服务器无法或不会恢复该会话时，也会生成新的会话ID。后一种情况也会导致产生新的会话ID。
  • 恢复的会话ID。ID与客户端问候中的ID相同。客户端指示要恢复的会话ID，服务器愿意恢复该会话。
  • 空。这是一个新会话，但是服务器不愿意在以后恢复它，因此不会返回ID。

• 密码套件。服务器将选择客户端和服务器均支持的最强密码。如果没有双方都支持的密码套件，则会话以握手失败告警结束。

• 压缩算法。指定要使用的压缩算法（当前不支持）。

• 拓展信息。本文不再详细描述。

2.3 ServerCertificate

服务器将其证书发送给客户端。服务器证书包含服务器的公钥。客户端将使用此密钥对服务器进行身份验证并加密主密码。一般而言，该消息紧跟着ServerHello消息。

客户端还检查证书中的服务器名称，以验证它与客户端用于连接的名称匹配。

2.3.1 消息格式

• 证书链所占用的字节，用3bytes表示；
  

• X509证书列表。列表中的第一个证书为TLS/SSL会话采用的证书，从该证书从获取公钥作为会话的公钥；
  

2.3.2 证书格式

• 证书长度。用3bytes表示证书内容长度，获取长度之后再根据长度获取证书内容；

• 证书内容。
  

2.4 ServerKeyExchange

服务器密钥交换是一个可选步骤，其中服务器创建一个临时密钥并将其发送给客户端。客户端可以使用此密钥在此过程的后面加密客户端密钥交换消息。仅当公共密钥算法未提供加密客户端密钥交换消息所需的密钥材料时（例如，服务器的证书不包含公共密钥时），才需要执行此步骤。

2.5 ClientCertificateRequest

客户证书申请是一个可选步骤，其中服务器请求客户端的身份验证。此步骤可能用于网站（例如银行网站），在该网站中服务器在提供敏感信息之前必须确认客户端的身份。

2.6 ServerHelloDone

ServerHelloDone消息表明服务器已完成，正在等待客户端的响应。

2.7 ClientCertificate

如果服务器发送了客户端证书请求，则客户端会将其证书发送到服务器以进行客户端身份验证。客户的证书包含客户的公钥。

2.8 ClientKeyExchange

客户端使用两个随机值计算了主密码后，将发送客户端密钥交换消息。在将预主密钥传输到服务器之前，它会使用服务器证书中的公钥加密。双方将在本地计算主密钥并从中获取会话密钥。

如果服务器可以解密此数据并完成协议，那么客户端就可以确信服务器拥有正确的私钥。此步骤对于证明服务器的真实性至关重要。只有具有与证书中的公钥匹配的私钥的服务器才能解密此数据并继续进行协议协商。

此消息还将包括协议版本。服务器将验证它是否与ClientHello消息中发送的原始值匹配。此措施可防止回滚攻击。回滚攻击通过操纵消息来工作，以便使服务器和客户端使用不太安全的早期版本的协议。

2.9 CertificateVerify

仅当客户端先前发送了客户端证书消息时，才发送此消息。客户端通过使用其私钥对到目前为止所有消息的哈希签名来进行身份验证。接收者使用签名者的公钥来验证签名，从而确保使用客户的私钥对签名进行签名。

2.10 ChangeCipherSpec

此消息通知服务器，将使用刚刚协商的密钥和算法，对ClientFinished消息之后的所有消息进行加密。

2.11 ClientFinished

客户端已完成。该消息是整个会话的哈希值，用于提供客户端的进一步身份验证。该消息是记录层加密和散列的第一条消息。

2.12 ChangeCipherSpecMessage

该消息通知客户端，服务器将开始使用刚刚协商的密钥对消息进行加密。

2.13 ServerFinishedMessage

该消息是使用会话密钥和MAC加密到目前为止的整个交换的哈希。如果客户端能够成功解密此消息并验证包含的哈希，则可以确保SSL/TLS握手成功，并且客户端计算机上计算出的密钥与服务器上计算出的密钥匹配。

2.14 告警子协议

告警子协议是握手协议的组件，该协议包括可以从任何一方发送的事件驱动的告警消息。收到告警消息后，会话将结束，或者可以选择是否结束会话。告警是在RFC 2246的TLS规范中定义的。

3. 记录协议

记录协议从应用程序层接收数据，并且：

• 将数据分段成块或将分段数据重新组合成其原始结构。
• 为消息中的数据块顺序编号，以防止尝试重新排序数据的攻击。
• 使用在握手协议中协商的压缩算法压缩或解压缩数据。
• 使用在握手协议期间协商的加密密钥和加密算法对数据进行加密或解密。
• 将HMAC（或用于SSL 3.0的MAC）应用于传出数据。计算HMAC并验证它是否与发送的值相同，以便在收到消息时检查数据完整性。

记录协议完成对数据的操作后，会将数据发送到TCP/IP传输层进行传输。如果数据进入，则将其发送到适当的进程进行接收。