HTTP vs HTTPS
HTTP 主要有以下不足：
- 通信使用明文（不加密），内容可能会被窃听
- 不验证通信方的身份，因此有可能遭遇伪装
- 无法证明报文的完整性，所以有可能已遭篡改
HTTPS 相较于 HTTP 多了一个 S。S 代表 Security🔒，安全。
即拥有加密，身份验证和完整性三个机制。这三个机制为 Web 通信构建了一个安全的环境：
- 加密：混淆数据的机制。不让第三方知晓传输内容
- 身份验证：验证身份标识有效性的机制。允许通信两端互相验明身份，防止被伪装
- 完整性：检测消息是否被篡改或伪造的机制。避免第三方篡改数据
那么 HTTPS 是如何做到拥有这三个特性的呢？依靠 TLS （Transport Layer Security）传输层安全协议。
HTTP vs HTTPS （TLS 为 SSL 的升级版），此图源自《图解HTTP》
加密
在对 TLS 进行讲解之前，我们先来了解一下加密方法。近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。
共享密钥加密
加密和解密同用一个密钥的加密方式叫做共享密钥加密。
以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。
共享密钥加密图示及困境，此图源自《图解HTTP》
怎样才能安全地发送密钥？
公开密钥加密
公开密钥加密方式很好地解决了共享密钥加密的困境。
公开密钥加密的加密和解密的密钥不相同。其中，加密密钥为公开密钥，可以随意发布，任何人都可以获得；解密密钥为私有密钥，不能让其他任何人知道。
公开密钥加密图示，此图源自《图解HTTP》
具体流程：
发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要在公网中暴露私钥，不必担心密钥被攻击者窃听盗走。
混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。
- 共享密钥加密无法保证密钥能被安全送到另一端，从而无法和陌生的对端进行通信，但其处理速度快。
- 公开密钥加密可以利用公钥能随便在网上散播的优势，从而和陌生对端进行安全的通信，但其处理速度慢。
我们可以充分利用两者的优势：在通信前使用公开密钥加密交换密钥，之后的通信则使用共享密钥加密。
混合加密机制，此图源自《图解HTTP》
遗憾的是，公开密钥加密还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
证书
通过上述的混合加密机制，我们实现了 HTTPS 保证安全通信的第一个机制：加密，即混淆数据，不让第三方知晓传输内容。那我们如何实现第二个机制：身份验证呢？如上述混合加密机制存在的问题，我们无法确认对端是我们想通信的对端，而不是伪造的。
我们可以使用由数字证书认证机构（CA，CertificateAuthority）和其相关机关颁发的公开密钥证书。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。
证书 + 混合密钥机制的业务流程如下图所示：
证书 + 混合密钥机制示意图，此图源自《图解HTTP》
此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
TLS 握手🤝
TLS 握手即融合了上述所介绍的所有机制（证书 + 公开密钥加密 + 共享密钥加密），通过 TLS 握手，双端就可以建立加密的安全数据通道。
TLS 握手示意图，此图源自《Web 性能权威指南》
- 0ms：TLS 在 TCP 之上运行，这意味着首先必须完成TCP的“三次握手”
- 56 ms：TCP连接建立之后，客户端再以纯文本形式发送一些规格说明，比如它所运行的TLS协议的版本、它所支持的加密套件列表，以及它支持或希望使用的另外一些TLS选项。
- 84ms：服务器取得TLS协议版本以备将来通信使用，从客户端提供的加密套件列表中选择一个，再附上自己的证书，将响应发送回客户端。作为可选项，服务器也可以发送一个请求，要求客户端提供证书以及其他TLS扩展参数。
- 112ms：假设两端经过协商确定了共同的版本和加密套件，客户端也高高兴兴地把自己的证书提供给了服务器。然后，客户端会生成一个新的对称密钥，用服务器的公钥来加密，加密后发送给服务器，告诉服务器可以开始加密通信了。到目前为止，除子用服务器公钥加密的新对称密钥之外，所有数据都以明文形式发送。
- 140ms：最后，服务器解密出客户端发来的对称密钥，通过验证消息的 MAC 检测消息完整性，再返回给客户端一个加密的 “Finished” 消息。
- 168ms：客户端用它之前生成的对称密钥解密这条消息，验证 MAC，如果一切顺利，则建立信道并开始发送应用数据。
消息认证码 MAC
上述 TLS 握手中提到的 MAC 是什么意思呢？我们通过混合加密机制 + 证书实现了 HTTPS 保证安全通信的前两个机制：加密和身份验证。接下来我们还需要实现第三个机制，完整性：检测消息是否被篡改或伪造，避免第三方篡改数据。
TLS 提供了自己的消息分帧机制，并使用 MAC 签署每一条消息。MAC 算法是一个单向加密的散列函数（本质上是一个校验和），密钥由连接双方协商确定。只要发送 TLS 消息，就会生成一个 MAC 值并附加到改其中。接收端通过计算和验证这个 MAC 值来判断消息的完整性和可靠性。
总结
加密、身份验证、完整性，这三种机制为 Web 通信构建了一个安全的环境。所有现代 Web 浏览器都支持多种加密套件，能够验证客户端和服务器，并能对每条记录进行消息完整性检查。
