WEB性能--TLS

一、传输层安全（TLS）介绍

SSL（Secure Sockets Layer，安全套接层）协议最初是网景公司为了保障网上交易安全而开发的，SSL协议在直接位于TCP上一层的应用层被实现。SSL不会影响上层协议（HTTP），但能够保证上层协议的网络通信安全。

IETF后来在标准化SSL协议时，将其改名为TLS（Transport Layer Security，传输层安全）。TLS1.0和SSL3.0版本的区别并不大。

二、加密、身份验证与完整性

TLS协议的目标是为在它之上运行的应用提供三个基本服务：加密、身份验证和数据完整性。从技术角度讲，并不是所有情况下都需要同时使用这三个服务。

1. 加密 混淆数据的机制。
2. 身份验证 验证身份标识有效性的机制。
3. 完整性 检测消息是否被篡改或伪造的机制。

这三种机制为Web通信构建了一个安全的环境。所有现代Web浏览器都支持多种加密套件，能够验证客户端和服务器，并能对每条记录进行消息完整性检查。

三、TLS握手

客户端与服务器在通过TLS交换数据之前，必须协商建立加密信道。协商内容包括TLS版本、加密套件，必要时还会验证证书。然而，协商过程的每一步都需要一个分组在客户端和服务器之间往返一次，因而所有TLS连接启动时都要经历一定的延迟。

1. 公钥加密和对称加密

公钥加密只在建立TLS信道的回话中使用。再次期间，服务器向客户端提供它的公钥，客户端生成对称密钥并使用服务器的公钥对其进行加密，然后再将加密之后的对称密钥返回服务器。服务器继而用自己的私钥解密出客户端发来的对称密钥。

接下来，客户端和服务器之间的通信就会全部使用客户端生成的共享密钥加密，这就是对称加密。之所以这样设计，很大程度是处于性能考虑，因为公钥加密需要很大的计算量。

协商建立TLS安全信道是一个复杂的过程，很容易出错，好在服务器和浏览器会替我们做这些工作。总之，尽管我们的Web应用不一定参与上述过程，但最重要的是知道每一个TLS连接在TCP握手基础上最多还需要两次额外的往返。这些都会增加实际交换数据之前的等待时间。

四、TLS会话恢复

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

1. 会话标识符

最早的会话标识符是在SSL2.0中引入的，支持服务器创建32位的会话标识符。在内部，服务器会为每个客户端保存一个会话ID和协商后的会话参数。相应地，客户端也可以保存会话ID，并将该ID包含在后续会话消息中，从而告诉服务器自己还记着上次握手协商后的加密套件和密钥，这些都可以重用。

借用会话标识符可以节省一次往返，还可以节省掉用于协商共享密钥的公钥加密计算。由于重用了之前协商过的会话数据，就可以迅速建立一个加密连接，而且同样安全。

由于服务器必须为每个客户端都创建和维护一端会话缓存，特别是用户量很大的情况下，问题就变得复杂起来，因此需要一套会话ID缓存和清除策略。

2. 会话记录单

为了解决上述服务器端TLS会话缓存的问题，会话记录单机制应运而生，该机制不用服务器保存每个客户端的会话状态。相反，如果客户端表明其支持会话记录单，则服务器可以在完整TLS握手的最后一次交换数据中添加一条新会话记录单记录，包含只有服务器知道的安全密钥加密过得所有会话数据。

然后客户端将这个会话记录单保存起来，在后续会话的消息中，可以将其包含在内。这样，所有会话数据只保存在客户端，而由于数据被加密过，且密钥只有服务器知道，因此仍然是安全的。

五、信任链与证书颁发机构

身份验证是建立每个TLS连接必不可少的部分。毕竟，加密信道两端可以是任何机器，包括攻击者的机器。下面我以张三和李四之间的验证为例：

1. 张三和李四分别生成自己的公钥和私钥；
2. 张三和李四分别隐藏自己的私钥；
3. 张三和李四向对方公开自己的公钥；
4. 张三向李四发送一条新消息，并用自己的私钥签名；
5. 李四使用张三的公钥验证收到的消息签名。

信任是上述交流的关键。公钥加密可以让我们使用发送端的公钥验证消息是否使用了正确的私钥签名，但认可发送端仍然是基于信任。在上述交流中，张三和李四可以当面交换自己的密钥，因为他们互相认识，能够保证不被冒名顶替。可以说，他们已经通过之前安全的握手确认了对方。

接下来，张三收到王五发来的一条消息。张三从未见过王五，但王五自称是李四的朋友。事实上，王五为了证明自己是李四的朋友，王五还请李四用李四的私钥签署了自己的公钥，并在消息中附上了签名。此时，张三首先检查王五公钥中李四的签名。他知道李四的私钥，因而可以验证李四确实签署了王五的公钥。由于他信任李四对王五的签名，所以就接收了王五的消息，并对消息进行完整性检查，以确保消息确实来自王五。

刚才这个过程建立了一个信任链：张三信任李四，李四信任王五，通过信任的传递，张三信任王五。只要这条链上的人不会被冒名顶替，我们就可以继续扩展这个信任网络。在Web应用中如何信任？信任谁？

1. 手工指定证书 所有浏览器和操作系统都提供了一种手工导入证书的机制。
2. 证书颁发机构 CA（Certificate Authority，证书颁发机构）是被证书接收者和依赖证书的一方共同信任的第三方。
3. 浏览器和操作系统 每个操作系统和大多数浏览器都会内置一个知名证书机构的名单。

六、证书撤销

有时候，出于种种原因，证书颁发者需要撤销或作废证书，比如证书的私钥不再安全、证书颁发机构本身被冒名顶替，或者其他各种正常的原因，像以旧换新更替等。为此，证书本身会包含如何检测其是否过期的指令。为确保信任链不被破坏，通信的任何一端都可以根据嵌入的指令和签名检查信任链中每个证书的状态。

1. 证书撤销名单（CRL）

CRL（Certificate Revocation List，证书撤销名单）是RFC 5280规定的一种检查所有证书状态的简单机制：每个证书颁发机构维护并定期发布已撤销证书的序列号名单。这样任何想验证证书的人都可以下载撤销名单，检查相应证书是否榜上有名。 CRL也会有一些问题：

1. CRL名单会越来越长；
2. 没有办法立即更新刚刚被撤销的证书序列号。

2. 在线证书状态协议（OCSP）

为了解决CRL的问题，RFC 2560定义了OCSP（Online Certificate Status Protocol，在线证书状态协议），提供了一种实时检查证书状态的机制。与CRL包含被撤销证书的序列号不同，OCSP支持验证端直接查询证书数据库中的序列号，从而验证证书是否有效。

七、TLS记录协议

与位于其下的IP或TCP没有什么不同，TLS会话中交换的所有数据同样使用规格明确的协议进行分帧。TLS记录协议负责识别不同的消息类型（握手、警告或数据，通过“内容类型”字段），以及每条消息的安全和完整性验证。

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

1. 记录协议接收应用数据；
2. 接收到的数据被切分为块：最大为每条记录16kb；
3. 压缩应用数据（可选）；
4. 添加MAC（Message Authentication Code）；
5. 使用商定的加密套件加密数据。

以上几步完成后，加密数据就会被交给TCP传输。接收端的流程相同，顺序相反：使用商定的加密套件解密、验证MAC、提取并把数据转交给上层的应用。

八、针对TCP的优化建议

鉴于网络协议的分层结构，在TLS之上运行应用与直接通过TCP通信没有什么不同。正因为如此，只需要对应用进行很少改动甚至不需要改动就可以支持TLS通信。

1. 计算成本 建立和维护加密信道给收发两端带来了额外的计算复杂度。特别是非对称加密。
2. 尽早完成握手 建立连接的延迟体现在每个TLS连接上，包括新连接和恢复的连接，因此是优化的重点。我们知道TCP首次需要三次握手，两端用通过一次完整的往返交换SYN/SYN-ACK分组。其次，TLS握手需要额外两次往返，即使在TLS会话恢复的情况下，也需要一次额外的往返。因此需要尽早完成握手，比如利用CDN等手段。
3. 会话缓存与无状态恢复 无论什么情况，在接近用户的地方终止连接都有助于减少延迟，但有延迟终归快不过没有延迟。启动TLS会话缓存和无状态恢复可以完全消除“回头客”的往返时间。
4. TLS记录大小 所有通过TLS交付的数据都会根据记录协议传输。每条记录的上限为16kb，每条记录还可能额外带有20到40字节的首部。如果记录可以封装在一个TCP分组内，在还会增加相应的IP和TCP字段。由于MTU通常为1500字节，因此分组占比最小的情况下只相当于帧大小的6%。 记录越小，分帧越浪费。小记录会造成浪费，大记录会造成延迟。因此，记录到底多大合适没有唯一的标准。
5. TLS压缩 TLS还有一个内置的功能，就是支持对记录协议传输的数据进行无损压缩。压缩算法在TLS握手期间商定，压缩操作在对记录加密之前执行。 但是实践中，却会禁止服务器上的TLS压缩功能：
   1. 2012年的“CRIME”攻击会利用TLS压缩恢复加密认证cookie，实施会话劫持。
   2. 传输级的TLS压缩不关心内容，可能会再次压缩已经压缩过的数据
6. 证书链的长度 验证信任链需要浏览器遍历链中的每个节点，会浪费很多时间。因此信任链长度不能过长。