SSL/TLS 握手过程中的一些细节 -- RSA 和 数字证书
作者：互联网
密钥交换算法 RSA 握手过程
在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。
根据非对称加密算法，服务端公钥加密的消息仅能通过服务端私钥解密。 这样服务端解密后，双⽅就得到了相同的密钥，再⽤它加密应⽤消息。
TLS 第一次握手
Client Hello
TLS 第二次握手
一、Server Hello
密码套件格式：【密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法】
⼀般 WITH 单词前⾯有两个单词，第⼀个单词是约定密钥交换的算法， 第⼆个单词是约定证书的验证算法。
⽐如刚才的密码套件的意思就是：
由于 WITH 单词只有⼀个 RSA，则说明握⼿时密钥交换算法和签名算法都是使⽤ RSA；
握⼿后的通信使⽤ AES 对称算法，密钥⻓度 128 位，分组模式是 GCM；
摘要算法 SHA384 ⽤于消息认证和产⽣随机数；
二、Server Certificate
三、Server Hello Done
客户端验证证书
数字证书作用：
认证公钥持有者的身份，以防止第三方进行冒充。
数字证书内容：
- 公钥；
- 持有者信息；
- 证书认证机构（CA）的信息；
- CA 对这份文件的数字签名及使用的算法；
- 证书有效期；
- 其他的额外信息；
CA 签发证书的过程：
- CA把持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包 ，对这些信息进行 Hash 计算得到一个 Hash 值；
- CA 使用自己的私钥将该 Hash 值加密，生成 Certificate Signature （证书签名）；
- 将 Certificate Signature 添加到文件证书上，形成数字证书。
客户端校验服务端数字证书的过程：
- 客户端使用同样的 Hash 算法计算出该证书的 Hash 值 H1；
- （通常浏览器和操作系统中集成了 CA 的公钥信息）浏览器收到证书以后使用 CA 的公钥解密 Certificate Signature 内容，得到第二个 Hash 值 H2；
- 比较 H1 和 H2，相同则可信赖。
证书信任链：
如百度的证书层级：
由于⽤户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于⽤户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。
TLS 第三次握手
一、Change Cipher Key Exchange（called：密钥交换）
至此， 客户端和服务端双⽅都共享了三个随机数，分别是 Client Random、Server Random、pre-master。双方都⽣成会话密钥（Master Secret），它是对称密钥，⽤于对后续的 HTTP 请求/响应的数据加解密。
二、Change Cipher Spec （called：更改密码规格）
告诉服务端开始使⽤加密⽅式发送消息。
从这里开始，之后都是对称密钥加密的密文。
三、Encrypted Handshake Message （Finished）（called：加密握手信息）
把之前所有发送的数据做个摘要，再用会话密钥加密一下，让服务器验证加密通信是否可⽤和之前握⼿信息是否有被中途篡改过。
TLS 第四次握手
一、Change Cipher Spec（called：更改密码规格）
二、Encrypted Handshake Message（called：加密握手信息）
RSA 算法缺陷
问题所在：
RSA 密钥协商算法不⽀持前向保密 。
因为客户端传递随机数给服务端时使用的是公钥加密的， ⼀旦服务端的私钥泄漏 了，过去被第三⽅截获的所有 TLS 通讯密⽂都会被破解。
解决办法：
DH 密钥协商算法
具体过程：
客户端和服务端各⾃会⽣成随机数，并以此作为私钥，然后根据公开的 DH 计算公示算出各⾃的公钥，通过 TLS 握⼿双⽅交换各⾃的公钥，这样双⽅都有⾃⼰的私钥和对⽅的公钥，然后双⽅根据各⾃持有的材料算出⼀个随机 数，这个随机数的值双⽅都是⼀样的，这就可以作为后续对称加密时使⽤的密钥。
DH 密钥交换过程中，即使第三⽅截获了 TLS 握⼿阶段传递的公钥，在不知道的私钥的情况下，也是⽆法计算出 密钥的，⽽且每⼀次对称加密密钥都是实时⽣成的，实现前向保密。
标签：TLS,公钥,加密,证书,--,RSA,算法,密钥,服务端 来源： https://www.cnblogs.com/tiddler/p/16647872.html