Web 性能之 TLS

SSL/TLS

SSL（ Secure Sockets Layer，安全套接字层）协议最初是网景公司为了保障网上交易安全而开发的，该协议通过加密来保护客户个人资料，通过认证和完整性检查来确保交易安全。SSL 不会影响上层协议（如 HTTP、电子邮件、即时通讯），但能够保证上层协议的网络通信安全。

鉴于 SSL 协议是网景公司专有的， IETF 成立了一个小组负责标准化该协议，后来就有了 RFC 2246，即 TLS 1.0，也就是 SSL 3.0 的升级版。

TLS 协议的目标是为在它之上运行的应用提供三个基本服务：

1. 加密：非对称加密、对称加密
2. 身份验证：验证机构信任链
3. 数据完整性：TLS 使用 MAC（Message Authentication Code，消息认证码）签署每一条消息，MAC 算法是一个单向加密的散列函数（本质上是一个校验和），密钥由连接双方协商确定。接收端通过计算和验证这个MAC 值来判断消息的完整性和可靠性。

TLS 握手

客户端与服务器在通过 TLS 交换数据之前，必须协商建立加密信道。协商内容包括 TLS 版本、加密套件，必要时还会验证证书。

上图的关键点有：

1. 三次握手
2. 协商使用的 TLS 版本、加密套件等内容，验证证书
3. 使用非对称密钥交换对称密钥，验证 MAC
4. 使用对称密钥开始通信

应用层协议协商

虽然使用 TLS 保障了可靠性，但我们还需要一种机制来协商协议。作为 HTTPS 会话，当然可以利用 HTTP 的 Upgrade 机制来协商，但这会导致一次额外的往返，造成延迟。顾名思义，应用层协议协商（ALPN， Application Layer Protocol Negotiation）作为TLS 扩展，让我们能在 TLS 握手的同时协商应用协议，从而省掉了 HTTP的 Upgrade 机制所需的额外往返时间。

服务器名称指示

网络上可以建立 TCP 连接的任意两端都可以建立加密 TLS 信道，客户端只需知道另一端的 IP 地址即可建立连接并进行 TLS 握手。然而，如果服务器想在一个 IP 地址为多个站点提供服务，而每个站点都拥有自己的 TLS 证书，那怎么办？为了解决这个问题， SNI（Server Name Indication，服务器名称指示）扩展被引入 TLS 协议，该扩展允许客户端在握手之初就指明要连接的主机名。

TLS 会话恢复

完整 TLS 握手会带来额外的延迟和计算量，从而给所有依赖安全通信的应用造成严重的性能损失。为了挽回某些损失，TLS 提供了恢复功能，即在多个连接间共享协商后的安全密钥。

会话标识符

会话标识符：服务器会为每个客户端保存一个会话 ID 和协商后的会话参数。相应地，客户端也可以保存会话 ID 信息，并将该 ID 包含在后续会话的消息中，从而告诉服务器自己还记着上次握手协商后的加密套件和密钥，可以重用这些数据。

假设客户端和服务器都可以在自己的缓存中找到共享的会话 ID 参数，那么就可以进行简短握手。否则，就要重新启动一次全新的会话协商，生成新的会话 ID。

借助会话标识符可以节省一次往返，还可以省掉用于协商共享加密密钥的公钥加密计算。

但由于服务器必须为每个客户端都创建和维护一段会话缓存，因此“会话标识符”机制在实践中也会遇到问题，特别是对那些每天都要接待几万甚至几百万独立连接的服务器来说，问题就更多了。由于每个打开的 TLS 连接都要占用内存，因此需要一套会话 ID 缓存和清除策略，对于拥有很多服务器而且为获得最佳性能必须使用共享 TLS 会话缓存的热门站点而言，部署这些策略绝非易事。

会话记录单

为了解决上述服务器端部署 TLS 会话缓存的问题，可以使用“会话记录单”机制。它的原理很简单：既然保存会话数据对服务器负担很大，那么把它存放在客户端即可。具体过程如下：如果客户端表明其支持会话记录单，则服务器可以在完整 TLS 握手的最后一次交换中添加一条“新会话记录单”（New Session Ticket）记录，包含只有服务器知道的安全密钥加密过的所有会话数据，然后，客户端将这个会话记录单保存起来，在后续会话的 ClientHello 消息中，可以将其包含在 SessionTicket 扩展中。这样，所有会话数据只保存在客户端，而由于数据被加密过，且密钥只有服务器知道，因此仍然是安全的。

这里所说的会话标识符和会话记录单机制，也经常被人称为“会话缓存”或“无状态恢复”机制。

信任链与证书颁发机构

所谓信任链，即：A 信任 B，B 信任 C，那么 A 也可以信任 C。

对于 Web 以及浏览器而言，它们可以信任的有：

1. 手动指定/导入的证书
2. 证书颁发机构（CA，Certificate Authority）
3. 浏览器和操作系统。每个操作系统和大多数浏览器都会内置一个知名证书颁发机构的名单。

证书撤销

有时候，出于种种原因，证书颁发者需要撤销或作废证书，比如证书的私钥不再安全、证书颁发机构本身被冒名顶替，或者其它原因。

证书撤销名单

CRL（Certificate Revocation List，证书撤销名单）是一种检查所有证书状态的机制：每个证书颁发机构维护并定期发布已撤销证书的序列号名单。这样，任何想验证证书的人都可以下载撤销名单，检查相应证书是否榜上有名。如果有，说明证书已经被撤销了。

但 CRL 也存在一些问题：

1. CRL 名单会随着要撤销的证书增多而变长，每个客户端都必须取得包含所有序列号的完整名单
2. 没有办法立即更新刚刚被撤销的证书序列号，比如客户端先缓存了 CRL，之后某证书被撤销，那到缓存过期之前，该证书将一直被视为有效

在线证书状态协议

为解决 CRL 机制的上述问题，OCSP（Online Certificate StatusProtocol，在线证书状态协议）提供了一种实时检查证书状态的机制。与 CRL 不同，OCSP 支持验证端直接查询证书数据库中的序列号，从而验证证书链是否有效。总之，OCSP 占用带宽更少，支持实时验证。

但 OCSP 也存在问题：

1. 证书颁发机构必须处理实时查询；
2. 证书颁发机构必须确保随时随地可以访问；
3. 客户端在进一步协商之前阻塞 OCSP 请求；
4. 由于证书颁发机构知道客户端要访问哪个站点，因此实时 OCSP 请求可能会泄露客户端的隐私

因此，实践中， CRL 和 OCSP 机制是互补存在的，大多数证书既提供指令也支持查询。

TLS 结构

与位于其下的 IP 或 TCP 层没有什么不同， TLS 会话中交换的所有数据同样使用规格明确的协议进行分帧：

交付应用数据的典型流程如下：

1. 记录协议接收应用数据
2. 接收到的数据被切分为块：最大为每条记录 2^14 字节，即 16 KB
3. 压缩应用数据（可选）
4. 添加 MAC（ Message Authentication Code）或 HMAC
5. 使用商定的加密套件加密数据

以上几步完成后，加密数据就会被交给 TCP 层传输，接收到拿到数据后再进行解密等操作。

参考：《Web 性能权威指南》