会话快速恢复
客户端和服务器端建立 SSL/TLS 握手时,需要完成很多步骤:密钥协商出会话密钥,数字签名身份验证,消息验证码 MAC 等。
整个握手阶段比较耗时的是密钥协商,需要密集的 CPU 处理。当客户端和服务器断开了本次会话连接,那么它们之前连接时协商好的会话密钥就消失了。在下一次客户端连接服务器时,便要进行一次新的完整的握手阶段,这似乎没什么问题,但是当系统中某一时间段里有大量的连接请求提交时,就会占用大量服务器资源,导致网络延迟增加。
为了解决上面的问题,TLS/SSL 协议中提供了会话恢复的方式,允许客户端和服务器端在某次关闭连接后,下一次客户端访问时恢复上一次的会话连接。会话恢复有两种,一种是基于 Session ID 的恢复,一种是使用 Session Ticket TLS 扩展。
1. Session ID 会话恢复
一次完整的握手阶段结束后,客户端和服务器端都保存有这个 Session ID,在本次会话关闭,下一次再次连接时,客户端在 Client Hello 子消息中附带这个 Session ID 值,服务器端接收到请求后,将 Session ID 与自己在 Server Cache 中保存的 Session ID 进行匹配。
如果匹配成功,那么服务器端就会恢复上一次的 TLS 连接,使用之前协商过的密钥,不重新进行密钥协商,服务器收到带 Session ID 的 Client Hello 且匹配成功后,直接发送 ChangeCipherSpec 子协议,告诉 TLS 记录层将连接状态切换成可读和可写,就完成会话的恢复。
(Session ID 会话恢复)
虽然使用 Session ID 进行会话恢复可以减少耗时的步骤,但由于 Session ID 主要保存在服务器 Server Cache 中,若再次连接请求时由于负载均衡设定将请求重定位到了其他服务器上,此时新的服务器 Server Cache 中没有缓存与客户端匹配的 Session ID,会导致会话无法恢复无法进行。因此不建议选用 Session ID 方式进行会话恢复。
2. SessionTicket 会话恢复
一次完整的握手过程后,服务器端将本次的会话数据(会话标识符、证书、密码套件和主密钥等)进行加密,加密后生成一个 ticket ,并将 ticket 通过 NewSessionTicket 子消息发送给客户端,由客户端来保存,下一次连接时客户端就将 ticket 一起发送给服务器端,待服务器端解密校验无误后,就可以恢复上一次会话。
(SessionTicket 会话恢复)
由于加解密都是在服务端闭环进行,多服务只需要共享密钥就可以完成此过程,相较于 Session ID 的方式,可以不依赖 Server Cache,因此 SessionTicket 会话恢复方式更有利于大型分布式系统使用。
本文主要分享了两方面内容,首先,在互联网通信系统中使用具备 CA 认证的 SSL/TLS 证书可以保证传输安全,防止传输过程被监听、防止数据被窃取,确认连接的真实性;其次,利用 SessionTicket 快速地进行会话恢复可以提高整体系统性能,降低连接延时。
针对与开发者密切相关的互联网通信安全话题,本系列文章接下来还将从其他方面展开深度分享,请持续关注。