Transport Layer Security (TLS)

2017-06-02  本文已影响66人  zac4j

摘选自 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

正如上面的描述,新的 TLS 连接需要两次往返的回路实现 "full handshake"——这是个坏消息。然而实际上,优化的部署可以做的更好并提供一致的一次往返 TLS 握手:

结合上述两种优化可以使我们为新的或者重来的访问提供一致的 1-RTT TLS 握手,加上重用之前协商的会话参数减少计算资源的开销。确保在您的部署中利用好这些优化。

TLS 1.3 的设计目标就是减少延迟开销:新设置的安全连接为 1-RTT,重用会话的为 0-RTT!

上一篇 下一篇

猜你喜欢

热点阅读