ATS: HTTPS 认证

简介

在 ATS: HTTP/HTTPS 协议介绍中介绍了一些关于 HTTP/HTTPS 的概念以及相关的基本知识。

今天来聊聊关于 HTTPS 的认证方式和过程。

说 HTTPS 认证前，我们先了解一下几个相关概念。

关于加密的几个概念

1. SSL 协议加密方式

SSL 既用了对称加密，也用了非对称加密。

在建立传输链路时, SSL 首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL 对传输内容使用对称加密。

下面是两种加密方式的对比：

1.1、对称加密

对称加密采用了对称密码编码技术，它的特点是文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥，这种方法在密码学中叫做 对称加密算法，对称加密算法使用起来简单快捷，密钥较短，且破译困难，除了数据加密标准（DES），另一个对称密钥加密系统是国际数据加密算法（IDEA），它比 DES 的加密性好，而且对计算机功能要求也没有那么高。
IDEA 加密标准由 PGP（Pretty Good Privacy）系统使用。

该加密方式，速度快，可加密内容较大，用来加密会话过程中的消息。

1.2、非对称加密

1976年，美国学者 Dime 和 Henman 为解决信息公开传送和密钥管理问题，提出一种新的密钥交换协议，允许在不安全的媒体上的通讯双方交换信息，安全地达成一致的密钥，这就是“公开密钥系统”。
相对于 对称加密算法 这种方法也叫做 非对称加密算法。
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）. 公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

该加密方式，速度较慢，能提供更好的身份认证技术，用来加密对称加密的密钥。

2. 数字证书

一种文件的名称，好比一个机构或人的签名就好比一个公司的公章一样，能够证明这个机构或人的真实性，其中包含的信息，用于实现上述功能。

CA 证书（即数字证书）是由 CA（Certification Authority，证书颁发机构）机构发布的数字证书。其内容包含电子签证机关的信息、公钥用户信息、公钥、签名和有效期。这里的公钥是服务端的公钥、签名是指用 hash 散列函数计算公开的明文信息的信息摘要，然后采用 CA 的私钥对信息摘要进行加密，加密完的密文就是签名。即 证书 = 公钥 + 签名 +申请者和颁发者的信息。客户端中因为在操作系统中就预置了 CA 的公钥，所以支持解密签名（因为签名使用 CA 的私钥加密的）。

我们为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造通信方以及窃取网络通信内容，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的中间人攻击（Man-in-the-MiddleAttack，简称 “MITM攻击”）问题。

推荐大家看看网络世界背后的“功臣”——CA 认证这篇文章。

3. 加密和认证

加密是指通信双方为了防止敏感信息在信道上被第三方窃听而泄漏，将明文通过加密变成密文，如果第三方无法解密的话，就算获得密文也无能为力。

认证是指通信双方为了确认对方是值得信任的消息发送或接受方，而不是使用假身份的非法者，采取的确认身份的方式。

只有同时进行了加密和认证才能保证通信的安全，因此在 SSL 通信协议中这两者(加密和认证)都被使用。

加密一般使用 对称加密算法 和 不对称加密算法，最常见的算法非对称加密就是 RSA 加密算法。

4. 消息摘要

这个技术主要是为了避免消息被篡改，消息摘要也称之为数字摘要。

消息摘要是把一段信息通过某种不可逆的算法，得出一串字符串。这个字符串就是消息的摘要，如果消息被篡改(发生了变化)，那么摘要也一定会发生变化，当然了如果两个不同的消息生成的摘要是一样的，那么这就叫发生了 碰撞。好的摘要算法是没有人能从中找到 碰撞 或者说极度难找到。

消息摘要的算法主要有 MD2、MD4、MD5、SHA-1、SHA-256、RIPEMD128、RIPEMD160 等，在证书领域，一般都是用 SHA(安全哈希算法)。消息摘要算法的主要特征是加密过程不需要密钥，并且经过加密的数据无法被解密，只有输入相同的明文数据经过相同的消息摘要算法才能得到相同的密文。

数字证书、加密和认证、消息摘要三个技术结合起来，就是在 HTTPS 中广泛应用的证书（certificate），证书本身携带了加密/解密的信息，并且可以标识自己的身份，也自带消息摘要。

HTTPS 认证方式

分为单向和双向认证。

单向认证

单向认证较简单，只需要客户端校验服务端的证书的合法性即可。换句话说，只需要客户端验证 SSL 服务器身份，不需要服务端验证 SSL 客户端身份。也就是说单向认证不需要客户端保存 CA 证书即单向认证 SSL 协议不需要客户拥有 CA 证书。

该认证过程使用下面的流程图来表示:

双向认证

双向认证和单向认证原理基本一致，但是需要双方都校验对方的证书的合法性。换句话说，要求服务器和客户端双方都有证书，客户端需要校验服务端，服务端也需要校验客户端。也就是说双向认证需要客户端、服务端都要保存证书。

该认证过程使用下面的流程图来表示：

这里总结一下双向通信的流程🤦‍。

第1步：客户端向服务端发起请求

这个过程主要做了下面两件事情：

①、客户端生成随机数 R1 发送给服务端；

②、告诉服务端自己支持哪些加密算法；

第2步：服务器向客户端发送数字证书

①、服务端生成随机数 R2；

②、从客户端支持的加密算法中选择一种双方都支持的加密算法（此算法用于后面的会话密钥生成）;

③、服务端把证书、随机数 R2 和会话密钥生成算法，一起发给客户端；

第3步：客户端验证数字证书

①、验证证书的可靠性，先用 CA 的公钥解密被加密过后的证书，能解密则说明证书没有问题，然后通过证书里提供的摘要算法对数据进行摘要计算，然后通过自己生成的摘要与服务端发送的摘要比对，比对如果一致表示通信内容没有被修改；

②、验证证书合法性，包括证书是否吊销、是否到期、域名是否匹配，通过后则进行后面的流程；

③、获得证书的公钥、会话密钥生成算法、随机数 R2（服务端生成的）；

④、客户端生成第三个随机数 R3；

⑤、根据会话秘钥算法使用 R1、R2、R3 生成会话秘钥；

⑥、用服务端证书的公钥加密随机数 R3 并发送给服务端；

第4步：服务器得到会话密钥

①、服务器用私钥解密客户端发过来的随机数 R3；

②、根据会话秘钥算法使用 R1、R2、R3 生成会话秘钥；

第5步：客户端与服务端进行加密会话

①、客户端发送加密数据给服务端，客户端加密数据后发送给服务端。

②、服务端响应客户端，服务端用会话密钥解密客户端发送的数据，然后用会话密钥把响应的数据加密发送给客户端；

③、客户端用会话密钥解密服务端响应的数据；

从上面可以看出，前4步属于双方的通信握手过程，第5步才进行真正的通信。在握手的过程中使用了 非对称加密 主要用于生成后续通信的密钥，在后续的数据通信中使用了 对称加密。

随机数的产生

不管是单向认证，还是双向认证，都有随机数的产生和发送，其中 R1、R2 都是明文传输，只有 R3 是加密传输的。

R1：Client Random，是由客户端产生的随机数；

R2：Server Random，是由服务端产生的随机数；

R3：是客户端产生的且使用密钥加密的随机数，也称之为 Premaster secret；

主密钥（Master Secret）是由预备主密钥 Premaster secret 即 R3、R1 和 R2 通过 PRF（PredoRandomFunction，伪随机数函数）函数生成的（不过在 TLS 1.3 中，不再使用 PRF 这种算法了，而是采用更标准的 HKDF 算法来进行密钥的推导），后续客户端、服务端使用的 会话密钥 则是由主密钥根据一定的算法生成的。另外要注意的是，会话密钥也会变的，只是在当前某个会话中它是不变的另外建立会话后它又改变了。

随机数的产生流程图:

无论是单向认证还是双向认证都会生成三个随机数即上述流程中的 R1、R2、R3，根据三个随机数创建一个对称加密的秘钥。前两个随机数可以被抓包拿到，但第三个随机数已经使用非对称加密算法加密过，所以最终生成的秘钥是保密的。对称秘钥的安全靠第三个随机数的不可破解来保证。理论上来说，只要服务器的公钥足够长，那么 R3（也被称之为 Premaster secret）可以保证不被破解。但是为了足够安全，可以考虑把握手阶段的算法从默认的 RSA 算法改为 Diffie-Hellman 算法（简称 DH 算法）。

我们思考一个问题：为何需要生成3个随机数，1个不行吗？

1、并不是每个主机都能产生完全的随机数，有很多产生的随机数只是弱随机数而已如范围小可能被猜测，这样就不安全了；

2、用 3 个随机数一起生成密钥能使得伪随机数更接近随机；

大家可以看看 TLS 中的密钥计算这篇文章，里面详细的讲解了随机数生成的原理以及不同 TLS 版本生成会话密钥的差异。