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 性能权威指南》