这是我参与8月更文挑战的第12天,活动详情查看:8月更文挑战
Session Resumption会话恢复,是TLS握手流程的重要部分,有了它的存在,可以大幅的缩短握手流程。TLS中主要依靠session id, session ticket和PSK三种方式进行会话恢复,我们今天就来整体介绍一下。
Session id & Ticket
这两者都是在TLS1.2中用到的机制,首先看一下引入他们后的效果
可以看到红框里的session resumption流程,将TLS握手的9步缩短到了4步。
Session ID
Session id是由服务器分配的,发给客户端让客户端保存,在客户端发起新会话时,会将这个ID在client hello中发给服务器,用来判断是否恢复之前的session。
服务器在缓存中查找该id,如果找到了,并且服务器愿意重建该会话的话,那么就会在Sever Hello消息中发送同样的session id
之后双方就可以开始用之前协商过的加密模式开始传输数据。
Session id是最传统的方式,它的主要问题是,会话状态保存在服务器端,当大量用户访问服务器时,服务器用来保存会话状态的空间占用就会很大,需要对保存时间,保存机制做优化。
为了解决这个问题,TLS1.2引入了session ticket机制
Session Ticket
Session Ticket的工作原理很简单:
-
服务器在获取到客户端的密钥协商参数,并生成session key之后,会将完整的会话状态(session status)进行加密,生成session ticket,注意,这个信息只有服务器才能够解密
-
Sever验证了客户端发送Finished消息后,通过"New session ticket"消息将session ticket发给客户端进行保存,服务器端就不再保存会话状态了,下图是这条消息所在的流程步骤:
- 客户端在下次发起会话时,就可以将Session Ticket放入client hello中,服务器收到后进行解密验证,并从ticket的内容中提取会话状态,用来恢复会话。
New Session Ticket
- Session Ticket LIfetime Hint: 保存时间指示,当时间到期时,客户端必须删除该ticket.
- Session Ticket: 加密后的session status信息,包含了master key,以及cipher suite,这些信息会被用来生成新的session key,保证前向安全。同时这个信息只有服务器才能解密。
- Change Cipher Spec: 告知客户端,开始使用加密传输数据。按照协议,new session ticket消息必须在服务器验证了客户端发送的finished消息后,并在自己发送的change cipher spec之前进行发送
- 按照协议,当客户端收到session ticket后,必须将之前受到过的session id删除
Cient Hello
在客户端在发起新会话的时候,会将上次会话收到的session ticket通过client hello发给服务器,让服务器进行解密校验.
客户端通过Extension: session_ticket来发送session tick,这个信息是加密的,只有服务器才能解密。
可以看到,客户端同时发送了session id。按照协议,当session id与ticket并存时,服务器会忽略session id.
Sever Hello
服务器在收到session ticket后,首先会发送响应server hello
这条消息和平时没有什么不同,但是其中包含一个重要信息,就是Random.
按照协议,用作恢复session的密钥,会根据session ticket中的master key + 新会话中的client random + server random生成。
所以这条server hello,实际上是把server random发给了客户端。
安全风险
- 之前会话的master key是否泄密,否则新的session key也不安全。
- 缺乏身份验证机制,无法防止中间人攻击。
- TLS给出的方案是,恢复会话必须双方都同意,如果有一方认为会话不安全,就都需要重新走一遍完整的握手流程;另外客户端保存session ticket的有效期最长不要超过24小时;
PSK
在TLS1.3中,引入新的session resumption机制代替了session id和ticket.
PSK--Pre-shared-key预分享密钥。工作机制如下:
- 双方经过握手和密钥协商,和身份验证之后,生成对称的密钥session key。
- 在收到客户端的finished消息之后,服务器通过"new session ticket"消息,携带PSK发送给客户端,注意这条消息是使用session key加密的,这就保证了只有通信双方才能读取里面的信息。
- 服务器可能会发送多个new session ticket,包含不同的PSK;
- 在建立新会话时,客户端将PSK信息放入client Hello消息中发送给服务器,报文如下:
- 如果服务器验证了该PSK的真实性,则会在server hello中的pre_shared_key中将加密的PSK发送给客户端;
- 那么之前的PSK就会被用来生成新的session key,并开始加密传输数据,不需要再发送CA证书等验证消息了。
- 只要证明了双方都持有相同的PSK,不再需要证书认证,就可以证明双方的身份,因此,PSK也是一种身份认证机制。
感谢阅读,如有不准确和错误之处请留言指正,我会立即修正,感谢!
总结不易,请勿私自转载,否则别怪老大爷不客气
欢迎喜欢技术的小伙伴和我交流,微信1296386616
参考资料:
《TLS Session Resumption》 by Anastasios Arampatzis www.venafi.com/blog/tls-se…
rfc5246 - IETF Tools datatracker.ietf.org/doc/html/rf…
rfc5077 - IETF Tools datatracker.ietf.org/doc/html/rf…
《The Transport Layer Security (TLS) Protocol Version 1.3》 datatracker.ietf.org/doc/html/rf…
《TLS 1.3科普——新特性与协议实现》 Wangrange zhuanlan.zhihu.com/p/28850798