2020-05-13 HTTPS专栏

[sl1673495]

SSL TLS 协议握手阶段

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
总览：

（1） 客户端向服务器端索要并验证公钥。

（2） 双方协商生成"对话密钥"。

（3） 双方采用"对话密钥"进行加密通信。

1. 客户端发起请求（确认协议、算法）

客户端需要像服务端提供：

（1） 支持的协议版本，比如 TLS 1.0 版。

（2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。

（3） 支持的加密方法，比如 RSA 公钥加密。

（4） 支持的压缩方法。

2. 服务器回应（确认协议、算法、给证书）

（1） 确认使用的加密通信协议版本，比如 TLS 1.0 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。

（3） 确认使用的加密方法，比如 RSA 公钥加密。

（4） 服务器证书（包含公钥）。

3. 客户端回应（验证证书，用证书里取出的公钥加密第三个随机数）

验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供服务器校验。

4.服务器的最后回应（生成会话密钥，后续完全使用此加密内容）

服务器收到客户端的第三个随机数 pre-master key 之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。

（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用"会话密钥"加密内容。

[sl1673495]

图解SSL

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

在握手过程中，其实总共生成了三个随机数：

1. Client random
2. Server random
3. Premaster secret（会用服务器公钥加密）

3个注意点：

1. 生成对话密钥一共需要三个随机数。
2. 握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
3. 服务器公钥放在服务器的数字证书之中。

[sl1673495]

浏览器工作原理版

http://blog.poetries.top/browser-working-principle/guide/part6/lesson36.html#%E7%AC%AC%E4%B8%80%E7%89%88%EF%BC%9A%E4%BD%BF%E7%94%A8%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86

选择加密方式

使用对称加密传输数据

虽然对称加密可以服务端和客户端商议加密方式后，加密 client random 和 server random 生成密钥，但是由于这个过程是明文传输的，第三方在中间拦截也可以看到这些信息，它也可以利用这些信息生成出同样的密钥。

非对称加密传输数据

使用非对称加密直接来进行数据传输。这样是可以保证安全问题，浏览器用服务器公钥加密的数据中间人是无法解密的，因为他没有公钥。但是如果每次数据传输都这样加密和解密的话，效率太低。

非对称加密会话，对称加密传输数据（HTTPS 采用）

1. 首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random；
   服务器保存随机数 client-random，选择对称加密和非对称加密的套件，然后生成随机数 service-random，向浏览器发送选择的加密套件、service-random 和公钥；
2. 浏览器保存公钥，并利用 client-random 和 service-random 计算出来 pre-master，然后利用公钥对 pre-master 加密，并向服务器发送加密后的数据；
3. 最后服务器拿出自己的私钥，解密出 pre-master 数据，并返回确认消息。

需要特别注意的一点，pre-master 是经过公钥加密之后传输的，所以黑客无法获取到 pre-master，这样黑客就无法生成密钥，也就保证了黑客无法破解传输过程中的数据了

添加数字证书

到此为止，传输过程中的安全已经可以保证了。但是考虑一下黑客劫持了你的 DNS 服务，你访问某个网站其实转到了黑客的网站，黑客自己也实现了一套公钥和私钥。你并不知道你是在和黑客通信。

所以就要引入数字证书这个概念。

对于浏览器来说，数字证书有两个作用：一个是通过数字证书向浏览器证明服务器的身份，另一个是数字证书里面包含了服务器公钥。

相较于上面第三版的 HTTPS 协议，这里主要有两点改变：

1. 服务器没有直接返回公钥给浏览器，而是返回了数字证书，而公钥正是包含在数字证书中的；
2. 在浏览器端多了一个证书验证的操作，验证了证书之后，才继续后续流程。

通过引入数字证书，我们就实现了服务器的身份认证功能，这样即便黑客伪造了服务器，但是由于证书是没有办法伪造的，所以依然无法欺骗用户。

数字证书的申请和验证

申请数字证书

1. 准备一套公钥和私钥。
2. 向 CA 机构提供公钥、私钥、站点等信息，等待认证。
3. CA 通过各种渠道验证信息真实性。
4. 信息审核通过后，CA 会给你签发认证的数字证书，包含公钥、组织信息、CA 信息、有效时间、证书序列等等，信息都是明文的，同时会包含一个CA 生成的签名。

数字签名的生成

1. 首先 CA 使用 hash 函数计算我们提交的明文信息，得出信息摘要。
2. CA 使用它的私钥加密，这就是数字签名。

验证数字证书

1. 浏览器向服务器发出请求的时候，服务器会返回数字签名。
2. 浏览器首先读取证书中的明文信息，采用 CA 签名相同的 hash 算法得到「信息摘要 A」，然后利用 CA 的公钥解密「数字签名」，得到「信息摘要 B」。
3. 「信息摘要 A」的生成方式和 CA 生成方式一模一样，而用 CA 的公钥对证书上的「数字签名」解密得到的「信息摘要 B」应当等同于这个「信息摘要 A」，因为数字签名 = 私钥加密(信息摘要A)。

经过这个验证过程，就相当于和 CA 确认过通信安全了，但是怎么确认这个 CA 不是假的呢？CA 上面还会有 CA，直到顶级的 CA 为止。

[sl1673495]

对网站证书校验的过程

1. CA 机构利用 hash 算法，把网站提供的明文信息生成「信息摘要」。
2. CA 机构利用自己的「私钥」，加密信息摘要，生成「数字签名」，放在证书中。服务端把这个证书返回给浏览器。
3. 浏览器利用同样的 hash 算法，把网站提供的明文信息生成「信息摘要 A」。
4. 浏览器利用 CA 机构的「公钥」，解密「数字签名」，生成「信息摘要 B」，如果信息摘要 A 和信息摘要 B 是一致的，说明这是 CA 证书认可的网站。

[sl1673495]

证书体系的弱点证书体系（PKI，Public Key Infrastructure）

虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点，还是关键的“信任”二字。如果 CA 失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。

还有一种更危险的情况，CA 被黑客攻陷，或者 CA 有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。这两种事情并不是“耸人听闻”，都曾经实际出现过。所以，需要再给证书体系打上一些补丁。

针对第一种，开发出了 CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。

对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对 CA 的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的。