这是我参与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
