计算机网络之 HTTPS 协议

[myLightLin]

为什么需要 HTTPS

HTTP 是明文传输的，一旦请求被截获，数据就泄露了。正因为 HTTP 不安全，于是网景公司在 1994 年搞了一个协议，叫 SSL（Secure Sockets Layer）安全套接层，有 v2 和 v3 两个版本，这个协议可以对传输数据进行加解密。后来 IETF 组织在 1999 年把它标准化了，改名为 TLS（Transport Layer Security）传输层安全，版本号从 1.0 重新算，目前常用的是 TLS1.2。

HTTPS（超文本传输安全协议），相比 HTTP，多了 S，S 是 Secure 的意思，它不是新协议，而是在 HTTP（应用层） 的下层提供了加密、完整性校验和身份验证等功能，所以 HTTPS 可以理解为 HTTP + TLS 的结合。

HTTPS 具有如下特点：

• 加密：用 TLS 对数据进行加密
• 完整性：通过数字签名，确保数据传输过程中不会被篡改
• 身份验证：通过 SSL 证书对服务器进行身份验证，确保客户端连接的是正确的服务器，防范中间人攻击
• 安全性：数据在安全层进行处理，保护密码、银行卡等敏感信息

加密算法

客户端和服务器在传输数据的时候，有两种加密方式：对称加密 和 非对称加密。对称加密就是双方都使用相同的密钥来传输，因而它的效率也比较高，但问题是客户端和服务端两方怎么来约定这个密钥呢？如果在互联网上传输，那密钥被截获了，那相当于白费，黑客可以静静地看着你们传输数据，自己偷偷用截获的密钥来查看数据。所以这时候就需要非对称加密了。非对称加密就是加密和解密使用不同的密钥，称为公钥和私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密，公钥是可以公开传播的，但私钥是存储在特定一方的，不会在互联网上传输，所以即使黑客截获了请求，也有公钥，但是黑客没有私钥，无法解密到信息，这样就保证了安全。

这两种加密算法各有优劣，对称加密传输效率高，但是无法保证密钥的安全；而非对称加密安全性高，但是传输效率低。于是两相权衡下，HTTPS 把这两种算法结合起来：先使用 非对称加密 来传输一个密钥，这个密钥后续用于客户端服务端加解密数据使用，然后正式传输数据时，使用 对称加密 来通信，因此此时双方都有密钥了，且这个密钥是通过非对称加密获得的，保证了安全性。

常见的对称加密算法：DES，AES 等
常见的非对称加密算法：RSA，DSA，ECC，DH 等
常见的散列算法： SHA-256，MD5 等
常见的编码方式：base64，hex 等

TLS1.2 握手过程

握手是为了双方知晓一个共用密钥，过程如下：

1. 客户端发送问候消息，包含自己支持的 TLS 版本，密码套件以及一串客户端随机数
2. 服务器回复问候消息，包含服务器的数字证书，所选择的密码套件以及一串服务端随机数
3. 客户端验证服务器的证书，这是为了确认服务器的身份。然后使用公钥加密一个随机数，称为 premaster secret（预主密钥），这个密钥只有服务器的私钥能解密
4. 现在两方都拿到了三个参数（客户端随机数，服务端随机数以及预主密钥），客户端和服务端根据之前约定的算法生成会话密钥，这个密钥就是用来最终传输的
5. 客户端使用会话密钥加密一条消息「Finished」，发给服务器
6. 服务器也使用会话密钥加密「Finished」，发给客户端
7. 握手完成，接下来双方都使用这个密钥来传输数据

这其中有一个步骤，就是服务器发送证书给客户端，然后客户端验证证书的合法性，为什么要这么做呢？是服务器为了向浏览器证明「我就是我」，否则如果网址被黑客劫持，那浏览器并不知道自己访问的其实是黑客的服务器。通常来说，网站需要向 CA 机构提交一系列本网站的信息，然后 CA 机构验证信息后，首先使用 hash 函数计算网站提交的明文信息，得到信息摘要。接着 CA 用自己的私钥加密摘要，得到该证书的数字签名。当客户端接收到证书后，会按证书上的信息使用相同的 hash 函数计算得到信息摘要 A，再使用 CA 机构的公钥解密数字签名，得到摘要 B，然后对比 A 和 B 两个摘要是否相同，从而验证服务器的身份。

接着问题又来了，客户端在验签的时候怎么保证这个证书是真的，而不是别人假冒权威机构颁发的？所以需要有多级权威机构。
也就是你要校验某个 CA 机构的真实性，那就看它上一级 CA 机构的公钥，能不能解开它的签名，这样一级级往上校验，直到 root CA 也就是最顶级权威的机构。这个过程可以这样类比：你想知道区公安局有没骗人，你就打电话去问市公安局，再打电话去省公安厅，再打电话去公安部，这样层层往上校验，确保了证书的合法性，也就确认了服务端身份的合法性。

TLS1.3

前面的 TLS 握手流程也不是绝对的，在特定的环境下，TLS 握手流程可以缩短，并不是严格像上面这步骤客户端服务端一来一回。比如在 TLS1.3 版本中，就压缩了握手过程，将握手时间减少到了 1 个 RTT 往返。除此之外，TLS1.3 还改进了密码套件，提升了安全性。

TLS1.3 握手过程：

1. 客户端首先发送一个包含协议版本、一个随机生成的数字（客户端随机数）和一系列加密方式的列表信息。TLS1.3 取消了一些不够安全的加密方式，所以这个密码套件列表比之前简短很多。这个问候信息还包括一些用于生成重要的安全码（预主密钥）的参数。客户端通常会猜测服务器偏好的密钥交换方式，这次猜测在 TLS1.3 中很可能是正确的。这种方式有效减少了握手的步骤，这也是 TLS1.3 与早期版本（如 TLS1.0、1.1、1.2）的主要区别之一。
2. 服务器收到客户端的随机数和参数后，结合自己生成的另一个随机数（服务器随机数），就能生成一个会话密钥。
3. 服务器会回复一个包含证书、数字签名、服务器随机数和选择的加密方式的信息。由于它已经生成了主密钥，所以还会发送一个表示握手流程即将结束的「finished」消息。
4. 客户端接着验证服务器的签名和证书，生成与服务器相同的会话密钥，并发送自己的「finished」消息。
   至此，握手就完成了。

0-RTT 模式快速恢复会话

TLS 1.3引入了一种更加迅速的握手机制，它消除了客户端与服务器间的任何等待时间。简而言之，如果用户之前访问过某个网站，他们的设备和网站服务器就能够利用上次连接时建立的一种特殊安全码——我们称之为“恢复主密钥”。在首次连接时，服务器还会给客户端一个“会话票证”。下次用户再访问该网站时，他们的设备就可以使用这个安全码和会话票证，立即在发送的第一条信息中与服务器建立一个加密的通信连接，从而实现即时的会话恢复。这样一来，TLS连接就能在客户端与服务器之间迅速重启。