https的加解密流程_2

1.https的详细流程图

2.tls的四次握手

1.TLS 第一次握手

1.浏览器发送Client Hello给服务器。

​ 浏览器首先会发送Client Hello消息，消息里面有浏览器使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数Client Random，这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

2.TLS 第二次握手

1.服务器回应浏览器Server Hello消息。

​ 当服务端收到浏览器的Client Hello消息后，会确认 TLS 版本号是否支持，并从密码套件列表中选择一个密码套件，以及生成随机数Server Random。接着返回Server Hello消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数Server Random，以及选择出的密码套件。

注意：

如果服务端选择的密码套件是：Cipher Suite:TLS_RSA_WITH_AES_128_GCM_SHA256。
密码套件的基本形式是：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法
1. 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。比如刚才的密码套件的意思就是：由于 WITH 之前单词只有一个 RSA，则说明握手时密钥交换算法和签名算法都是使用 RSA。
2. 握手后的通信使用 AES 对称算法，密钥长度 128 位，分组模式是 GCM。
3. 摘要算法 SHA256 用于消息认证和产生随机数。

就前面这两个浏览器和服务端相互打招呼的过程，浏览器和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现浏览器和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。那这个随机数有啥用呢？其实这两个随机数是后续作为生成会话密钥的条件，所谓的会话密钥就是数据传输时，所使用的对称加密密钥。然后，服务端为了证明自己的身份，会发送Server Certificate给浏览器，这个消息里含有数字证书。

2.服务器传输证书给浏览器

服务器会发送证书给浏览器，证书包含证书指纹，证书的签名信息，以及证书是针对于那个域名签发的，和签发机构；证书的过期时间，证书签发的主体，公钥证书的key。

3.服务器传输ServerKeyExchange给浏览器

​ 该消息的目的是携带密钥交换的额外数据，消息内容对于不同的协商算法套件都会存在差异。由于这里采用的是AES，所以需要密钥交换阶段，RSA算法是没有这步的。

4.服务器发送Server Hello Done消息

​ 服务端发了Server Hello Done消息，目的是告诉浏览器，我已经把该给你的东西都给你了，本次打招呼完毕。

3.TLS 第三次握手

1.浏览器发送Client Key Exchange消息给服务端。

​ 浏览器验证完证书后，认为可信则继续往下走。接着，浏览器就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过client Key Exchange消息传给服务端。

​ 服务端收到后，用 RSA 私钥解密，得到浏览器发来的随机数 (pre-master)。至此，浏览器和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。于是，双方根据已经得到的三个随机数，生成会话密钥Master Secret，它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

2.浏览器发送Change Cipher Spec消息给服务端。

​ 生成完会话密钥后，然后浏览器发一个Change Cipher Spec，告诉服务端开始使用加密方式发送消息。

3.浏览器发送Encrypted Handshake Message（Finishd）给服务器。

​ 浏览器发一个Encrypted Handshake Message（Finishd）消息给服务器，把之前所有发送的数据做个摘要，再用会话密钥master secret加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

可以发现，Change Cipher Spec之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

4.TLS 第四次握手

服务器也是同样的操作，发Change Cipher Spec和Encrypted Handshake Message消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用会话密钥加解密 HTTP 请求和响应了。

3.详解证书链

1.证书链校验过程

证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：

对于这种三级层级关系的证书验证过程如下：

• 浏览器收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，浏览器根据 baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 请求该中间证书。

• 请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，如果发现验证通过，就认为该中间证书是可信的。

• “GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性，如果验证通过，就可以信任 baidu.com 证书。

在这四个步骤中，最开始浏览器只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是浏览器也信任 baidu.com证书。总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

2.为什么需要中间证书？

为什么需要证书链这么麻烦的流程？Root CA 为什么不直接颁发证书，而是要搞那么多中间层级呢？
这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。