密钥协商算法的演变 —— RSA算法 - DH算法 - DHE算法 - ECDHE算法

可以看到，服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个密码套件看起来真让⼈头晕，好⼀⼤串，但是其实它是有固定格式和规范的。基本的形式是「密钥交换算法 +签名算法 + 对称加密算法 + 摘要算法」， ⼀般 WITH 单词前⾯有两个单词，第⼀个单词是约定密钥交换的算法，第⼆个单词是约定证书的验证算法。

⽐如刚才的密码套件的意思就是：由于 WITH 单词只有⼀个 RSA，则说明握⼿时密钥交换算法和签名算法都是使⽤ RSA；握⼿后的通信使⽤ AES 对称算法，密钥⻓度 128 位，分组模式是 GCM；摘要算法 SHA384 ⽤于消息认证和产⽣随机数；就前⾯这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使⽤的密码套件，⽽且你可能发现客户端和服务端都会各⾃⽣成⼀个随机数，并且还会把随机数传递给对⽅。

然后，服务端为了证明⾃⼰的身份，会发送「Server Certificate」给客户端，这个消息⾥含有数字证书。

随后，服务端发了「Server Hello Done」消息，⽬的是告诉客户端，我已经把该给你的东⻄都给你了，本次打招呼完毕。

【补充】：

CA 签发证书的过程：

• ⾸先 CA 会把持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包，然后对这些信息进行 Hash 计算，得到⼀个 Hash 值；

• 然后 CA 会使⽤自己的私钥将该 Hash 值加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名；

• 最后将 Certificate Signature 添加在⽂件证书上，形成数字证书；

客户端校验服务端的数字证书的过程：

• ⾸先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1(数字摘要)；

• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使⽤ CA 的公钥解密 Certificate

Signature 内容，得到⼀个 Hash 值 H2(数字摘要)。

• 最后⽐较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

TLS第三次握手：

客户端验证完证书后，认为可信则继续往下⾛。接着，客户端就会⽣成⼀个新的随机数 (pre-master预主秘钥)，⽤服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。

服务端收到后，⽤ RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

⾄此，客户端和服务端双⽅都共享了三个随机数，分别是 Client Random、Server Random、pre-master。

于是，双⽅根据已经得到的三个随机数，⽣成会话密钥（Master Secret），它是