通信 / HTTPS 过程详解

一、诞生原因

传统的 HTTP 是明文传输数据，容易被黑客截获，甚至产生中间人攻击。

二、大致过程

1. client 和 server 确定通信使用的加密算法、数据压缩算法、对称密钥。
2. 双方使用对称密钥进行数据加密传输。

由上述描述可知，https 最终使用的依然是对称密钥加密，因为对称加密算法较非对称计算速度快并且本身也足够安全。唯一麻烦的事是双方如何安全地确定对称密钥，在这个过程中需要使用非对称密钥进行过度。

三、流程图

不考虑 server 校验 client 证书、限制 client 连接 server 的目的是开启一个全新的连接。

四、过程说明

1、Client Hello：通知 Server 开启一个新的 Session 并传入以下数据：

（1）SSL/TLS 版本号。version 2 表示的是 SSL 2.0，version 3 表示的是 SSL 3.0，version 3.1 表示的是 TLS 1.0。

（2）随机数 Random C1。一共 32 个字节。前面 4 个字节是当前时间戳，后面 28 个字节是一个随机数。后面协商对称加密的 Session Key 会用到。

（3）Cipher Suite。支持的加密组件列表。例如 TLS_RSA_WITH_DES_CBC_SHA，TLS  是 TLS 协议版本，TLS 表示 TLS1.0，RSA 是密钥交换算法，DES_CBC 是加密算法，SHA 是摘要算法。

（4）压缩算法。表示建议选用的是哪种压缩算法。

栗子：

ClientVersion 3,1
ClientRandom[32]
SessionID: None (new session)
Suggested Cipher Suites:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_RSA_WITH_DES_CBC_SHA
Suggested Compression Algorithm: NONE

2、Server Hello：服务器收到客户端的 Client Hello 消息会响应一个 Server Hello 消息，包括以下字段：

（1）SSL / TLS 版本，客户端和服务器都支持的 SSL / TLS 最高版本。

（2）随机数 Random S，一共 32 个字节，前面 4 个字节是当前时间戳，后面 28 个字节是一个随机数。后面协商对称加密的 Session Key 会用到。

（3）Cipher Suite，服务器从刚才 Client Hello 消息的 Cipher Suite 加密列表中选中的加密组件。

（4）压缩算法，表示选中的是哪种压缩算法。

Version 3,1
ServerRandom[32]
SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77
Use Cipher Suite:TLS_RSA_WITH_3DES_EDE_CBC_SHA
Compression Algorithm: NONE

3、Server Certificate：Server 发给 Client 的证书，包含公钥。Client 校验证书的合法性，比如证书包含的域名是否就是客户端正在访问的域名。

4、Server Hello Done：表示 Server 已经发送消息完毕并且在等待 Client 回复。Client 收到上述数据之后，进行如下操作：

（1）生成 Random C2，用 Server 的公钥对其进行非对称加密生成 PreMaster Secret；

（2）运用算法，通过 Random C1、PreMaster Secret 和 Random S 生成 Session Key。Session Key 就是之后 HTTPS 正常通信时使用的对称加密的 key 。

5、Client Key Exchange：该消息包含 PreMaster Secret 以及 TLS 版本。

再次带上版本号是因为之前的版本号是明文传输的，攻击者可能会恶意修改为较低的版本号，从而降低连接的安全系数方便发起攻击。该消息字段会用公钥加密。

现在 Server 一共有 Random C1、PreMaster Secret 和 Random S 三个随机数，Server 会运用和 Client 相同的算法，将这三个随机数作为参数，计算得到另外的一个随机数，即后面对称加密的密钥 Session Key。

6、Change Cipher Spec：该消息通知 Server 接下来的 Client Finished 消息将会用刚才协商的密钥 Session Key 来加密。

7、Encrypted Handshake Message（Client Finished）：该消息会列举 Client 上面用到的所有加密字段，并且算出他们的 HASH 值，然后用 Session Key 加密。

8、Change Cipher Spec：该消息通知客户端接下来的消息会用Session Key来加密。

9、Encrypted Handshake Message（Server Finished）：对整个协商阶段用到的字段算一个 HASH，然后用 Session Key 加密。

10、Application Data：双方使用 Session Key 进行对称加密进行数据的传输。

五、拓展

1、生成 Session Key 为什么需要三个随机数？

理论上 Server 无法信任 Client 产生的随机数，该随机数可能是固定值，有可能是通过随机函数生成，都是由规律的，所以需要加入 Server 自己的随机值。这样随机数变成了 2 个，2 个也是不够的，因为上述过程中，随机数是明文传输的，需要加入一个密文传输的随机数，故计算 Session Key 理论上需要的随机数的数量至少为 3 个。

2、校验 CA 证书的过程是什么？

要明白校验过程，需要先明白证书中包含的内容是否什么，如下所示：

上述图片是 CSDN 的授权证书。 指明了证书的颁发机构、证书的使用机构、有效期以及匹配的域名。总的来说，CA 机构会将证书使用者的信息放入证书中，生成 hash 值放入后面，并用 CA 自己的私钥对 hash 值进行非对称加密，这样就产生了 CA 机构的数字签名。

所以根据上述内容，Client 校验 CA 证书的内容大致如下：

• SSL证书是否由受信任的CA机构颁发的。
• 证书是否过期。
• 访问的网站域名与证书绑定的域名是否一致。
• 用 CA 的公钥解密数字签名生成 hash 1，并通过证书中的 hash 算法生成 hash 2，比对 hash 1 和 hash 2，则该证书内容没有改动。

通过上述 4 条的校验，若均通过，则认为该证书合法。

（SAW：Game Over！）