摘选自 High Performance Browser Networking
SSL 协议最初是由 Netscape 开发，以便实现电子商务交易安全，这需要加密个人数据，身份验证以及完整性保证。为了实现这些功能，SSL 协议在应用层实现，直接在 TCP 之上，确保为其上的协议（HTTP, email, 即时通讯等）提供安全，不变的通信。
一旦 SSL 正确使用，第三方观察者（中间人）只能推测连接的端点，加密的类型，以及数据传输的频率和大致的规模，但是无法读取或者修改实际的数据。
tls.PNG
当 SSL 协议被 IETF 标准化时，它被重新命名为 Transport Layer Security(TLS)。许多人互换使用 SSL 和 TSL 名称，但技术上来说，它们是不同的，因为它们描述了协议的不同版本。
SSL 2.0 第一个公开发布的协议版本，但很快就由于被发现一系列安全漏洞而被 SSL 3.0 所替代。由于 SSL 协议的所有权归属于 Netscape，在 IETF 的努力下形成了一个标准化的协议—— RFC 2246，于 1999 年 1 月发布，被称为 TLS 1.0。从那时起，IETF 一直在持续迭代协议来解决安全漏洞，并增加它的能力：TLS 1.1 (RFC 2246) 发布于 2006 年 4 月，TLS 1.2 (RFC 5246) 发布于 2008 年 8 月，目前 TLS 1.3 也已经释出。
也就是说，不要被丰富的数字版本所迷惑：你的服务器应始终使用最新的稳定的 TLS 协议版本以确保最佳的安全性，功能和性能保证。实际上，一些关键性的功能，比如 HTTP/2，明确要求 TLS 1.2 或更高版本否则终止连接。高安全性和高性能并存。
TLS 被设计在可靠的传输协议 （TCP） 之上运行，然而，它同样可以在数据报协议之上运行，如 UDP。Datagram Transport Layer Security (DTLS) 协议，定义在 RFC 6347，建立在 TLS 协议的基础上并且在保留数据报传输模型的同时提供相似的安全保证。
TLS 握手
在客户端和服务器开始利用 TLS 交换应用数据之前，必须协商好加密隧道：客户端和服务器必须确定使用的 TLS 协议版本，选择加密套件（ciphersuite），以及验证证书是否有效。不幸的是，每个步骤都需要新的数据包往返客户端和服务器，这将为所有 TLS 连接增加启动延迟。
tls_handshake.PNG
-
0 ms
TLS 运行在可靠的传输层之上（TCP），这意味着我们必须先实现 TCP 三次握手，需要一个完整的往返。 -
56 ms
TCP 连接就位，客户端向服务器发送一些纯文本的规范，比如正在运行的 TLS 协议版本，支持的加密套件列表，以及其他可能要使用的 TLS 选项。 -
84 ms
服务器选择 TLS 协议版本进行下一步的通信，根据客户端提供的列表决定加密套件，然后发送响应到客户端。或者可选的，服务器还可以发送客户端证书请求和其他 TLS 扩展参数。 -
112 ms
假设两端协商好相同的协议版本和加密方式，并且客户端对服务器提供的证书表示满意，客户端将启动 RSA 或 Diffie-Hellman 密钥交换，用于建立随后会话的对称密钥。 -
140 ms
服务器处理客户端发送来的密钥交换参数，通过验证 MAC 来检查消息的完整性，并返回加密后的 Finished 消息给客户端。 -
168 ms
客户端通过协商好的对称性密钥解密消息，验证 MAC，假如一切顺利，则隧道建立并且可以发送应用数据。
正如上面的描述，新的 TLS 连接需要两次往返的回路实现 "full handshake"——这是个坏消息。然而实际上，优化的部署可以做的更好并提供一致的一次往返 TLS 握手：
- False Start 是一个 TLS 协议的扩展，允许客户端和服务器在握手部分完成时就可以传输加密后的应用数据。例如，一旦发送了 ChangeCipherSpec 和 Finished 信息，而不用等待对方执行相同的操作。这种优化可以减少新的 TLS 连接的开销到一次往返；可以参考 Enable False Start。
- 假如客户端之前与服务器通信过，可以使用 "abbreviated handshake"，这需要一次往返，并且允许客户端和服务器通过重新使用之前协商好的安全会话参数来减少 CPU 开销；可以参考 TLS Session Resumption。
结合上述两种优化可以使我们为新的或者重来的访问提供一致的 1-RTT TLS 握手，加上重用之前协商的会话参数减少计算资源的开销。确保在您的部署中利用好这些优化。
TLS 1.3 的设计目标就是减少延迟开销：新设置的安全连接为 1-RTT，重用会话的为 0-RTT!
网友评论