HTTPS的加密通信流程

补充说明几点：

1 协商密钥：客户端/服务端随机数、Client/Server Key

在加密一章节介绍的 ECDH 是停留在原理层面，实际中密钥协商除了 PreMaster-Secret（即 Client/Server Key）之外，还有客户端和服务端随机数参与，参考文章《Https：TLS 握手协议》，引用文中的图来自展示实际 ECDH 秘钥协商的做法：

2 Change Cipher Spec

Change Cipher Spec是通知对方需要加密参数。文章《TLSde 改变密码标准协议(Change Cipher Spec Protocol)》指出：

SSL 修改密文协议的设计目的是为了保障 SSL 传输过程的安全性，因为 SSL 协议要求客户端或服务器端每隔一段时间必须改变其加解密参数。当某一方要改变其加解密参数时，就发送一个简单的消息通知对方下一个要传送的数据将采用新的加解密参数，也就是要求对方改变原来的安全参数。

SSL 修改密文协议是使用 SSL 记录协议服务的 SSL 高层协议的 3 个特定协议之一，也是其中最简单的一个。协议由单个消息组成，该消息只包含一个值为 1 的单个字节。该消息的唯一作用就是使未决状态复制为当前状态，更新用于当前连接的密码组。为了保障 SSL 传输过程的安全性，双方应该每隔一段时间改变加密规范。

3 Encrypted Handshake Message

Encrypted Handshake Message作用就是确认协商出来的对称加密密钥 SK 的正确性，在客户端和服务端协商得到对称加密密钥 SK 之后，互相给对方发了一条用 SK 加密的消息，如果这个加密的消息被解密校验成功，那么就说明对称加密密钥 SK 是正确的。

4 单向验证和双向验证

本章全部所探讨的案例都是基于单向验证，即客户端向服务端请求证书、验证服务端身份。在一些实际场景中，对安全性的要求更高，有服务端要求验证客户端的身份，即双向验证。双向验证在单向验证基础上，增加“在服务端发送证书之后，向客户端发送‘请求证书’请求，接着验证客户端身份”这个步骤。参考下图（图片出处不查）：