HTTPS会话恢复技术解析

一、 前言

HTTPS（全称：HyperText Transfer Protocol Secure，常称为HTTP over TLS、HTTP over SSL或HTTP Secure），是一种通过计算机网络进行安全通信的传输协议——经由HTTP进行通信，使用SSL/TLS来加密数据包，以此在不安全的网络上创建一个安全信道。在使用适当的加密套件并且服务器证书被验证为可信的情况下，能够有效防范窃听和中间人攻击。

在传输数据之前，客户端必须与服务端协商密钥、加密算法等信息，服务端还需要将自己的证书发送给客户端表明其身份，即TLS握手过程，如下图所示：

相比HTTP协议，HTTPS协议增加了握手、加密解密等流程，保证了数据传输的安全性。但这些流程都会耗时,如上图所示TLS握手需要两个RTT（Round-Trip Time，往返时间），客户端、服务端处理、数据加解密也需要消耗时间。在下一次客户端访问同一个HTTPS网站，也就是再次访问该服务器时，需要重新进行一次完整的握手过程。当某个网站用户量越来越大后，重复握手过程服务器下发证书（证书一般达到KB级别）会大量占用带宽

二、 会话恢复技术

TLS握手的目的是为了协商出会话密钥，也就是对称加密密钥，若将首次TLS握手协商的对称加密密钥缓存起来，待下次需要建立HTTPS连接时，直接复用这个密钥，如下图所示，就可以将TLS握手所需RTT减少至一个。

这里介绍两种会话恢复的机制，Session ID 和 Session Ticket。Session ID的主要思想是服务端为每一次的会话生成并记录一个ID号发送给客户端，在重新连接的时候，客户端向服务端发送该ID号，服务端查找自己的会话记录，查找成功则重用之前的加密参数信息。Session Ticket 则是将加密参数等连接信息生成ticket并交由客户端进行管理。需要重连的时候，客户端将ticket发送给服务端，从而双方都拥有了重用的加密参数。

下面详细介绍一下这两种方式：

Session ID

Session ID机制——客户端和服务器首次TLS握手连接后，双方会在内存缓存会话密钥，并用唯一的Session ID来标识，Session ID和会话密钥相当于key-value的关系。

当客户端再次连接时，hello消息里会带上Session ID，服务器收到后就会从内存查找，如果找到就直接用该会话密钥恢复会话状态，跳过其余的过程，只用一个消息往返就可以建立安全通信。为了安全性，内存中的会话密钥需要设置有效期。

1、在客户端发起新会话时，将这个ID在Client Hello中发给服务器，用来判断是否恢复之前的会话

2、服务端在缓存中查找此ID，若检索到且服务器愿意重建该会话的话，会在Server Hello消息中携带同样的Session ID。

3、双方开始用之前协商好的加密模式、会话密钥加密传输数据。

Session ID机制存在一个问题，会话状态保存在服务器，若大量用户访问服务器，保存会话状态会占用很大空间，因此需要优化保存周期/机制。另外，RFC 5246 中建议会话的生命周期不应超过24小时，在此之后，服务器应该丢弃缓存的密钥和状态。

Session Ticket

Session Ticket机制——服务器不再保存每个客户端的会话密钥，而是将保存的工作交给了客户端。首次建立连接时，服务器在获取到客户端的密钥协商参数，生成Session key之后，使用Session Ticket Encryption Key(STEK)加密会话状态（Session Status），生成Session Ticket发送给客户端，由客户端来存储。客户端再次连接服务器时，客户端携带Session Ticket，服务器使用STEK解密后获取会话密钥并验证有效期，若没问题，就恢复会话开始加密通信，过程如下图所示。

详细流程说明如下：

第一次建立会话连接

（1）客户端与服务端首次连接时，在Client Hello子消息中使用空的Session Ticket TLS扩展；

（2）服务端解析出Client Hello中的Session Ticket扩展后，如果也支持Session Ticket会话方式，那么在Server Hello中也附带一个空的Session Ticket扩展，告知客户端支持会话恢复；

（3）接下来继续进行握手过程，客户端发送Change Cipher Spec和Finished子消息到服务端；

（4）服务端将上述参数加密生成票据，通过New Session Ticket子消息发送给客户端进行缓存，此时即完成首次会话连接的过程；

会话恢复过程

（7）下一次连接如果想通过会话恢复的方式，则客户端将票据附带到Client Hello的Session Ticket TLS扩展中，此时的扩展不是empty；

（8）服务端收到非空的扩展后，进行解密，校验里面的票据信息，完成简短的握手；通过使用ticket key将Client发送来的Session Ticket解密，获得Session key，并验证有效期；

（9）此时客户端和服务端具有相同的Session key，加密会话恢复；

（10）服务端发送新的New Session Ticket子消息给客户端，更新票据的有效期，防止因票据过期导致会话恢复请求失败。

使用时的注意事项：

1、窃听者或中间人可能获取Session Ticket，并试图使用它与服务器建立会话；但Session Ticket是经过加密的，且STEK存放于服务端，攻击者不知道会话密钥，获取的Session Ticket不能使攻击者恢复会话。所以TLS服务器在生成Session Ticket时需要使用强加密算法，防止攻击者暴力破解Session Ticket获取会话密钥。

2、长期使用STEK是实现Session Ticket机制时最常发生的问题。Session Ticket包含用STEK加密的会话密钥，攻击者获得STEK可以解密Session Ticket，恢复会话密钥，并解密连接内容，因此STEK需要定期更换。

3、攻击者可能伪造或篡改票据，以便恢复会话或延长会话的生命周期，冒充另一个用户或获得额外的特权。因此Session Ticket应使用完整性保护算法(如HMAC-SHA-256)进行保护。

4、攻击者可能存储或生成大量Session Ticket，发送到服务器进行验证，让服务器忙于验证Ticket。RFC5077推荐采用的Ticket结构中key_name字段能帮助服务器有效识别出不是自己签发的票据从而拒绝。

注：RFC 5077 推荐的Ticket结构如下：

5、安全的存储、分发、销毁密钥 。

三、 小结

为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，依靠证书来验证服务器的身份，并为客户端和服务端之间的通信加密。与HTTP相比，HTTPS在建立连接时需要经过多次往返握手协商出会话密钥，还涉及到证书的下发，并且加密算法的计算还会消耗CPU资源。客户端和服务端一旦关闭连接，短时间内再次访问HTTPS网站的时候需要重新下发证书/握手协商密钥，对效率和带宽影响较大。

因此对性能、功耗、带宽有强需求时，可以考虑采用会话复用机制。在实现会话复用机制时，需要采取上一节“使用时的注意事项“中的措施来保证数据传输的安全性。

四、 参考链接

• [1]. RFC 5077: Transport Layer Security(TLS) Session Resumption without Server-sIDe State.  

  https://datatracker.ietf.org/doc/html/rfc5077

• [2]. RFC 5246: The Transport Layer Security(TLS) Protocol Version 1.2  

  https://datatracker.ietf.org/doc/html/rfc5246

• [3]. Measuring the Security Harm of TLS Crypto Shortcuts. 

  https://aaspring.com/imc2016/crypto-shortcuts.pdf

• [4]. 超文本传输安全协议。

  https://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%AE%89%E5%85%A8%E5%8D%8F%E8%AE%AE

• [5]. TLS握手优化详解 https://imququ.com/post/optimize-tls-handshake.html

• [6]. 当我们谈论HTTPS时，我们在谈什么（八）Session Ticket、Session ID和PSK。

  https://juejin.cn/post/6995363748160487461

• [7]. Session会话恢复：两种简短的握手总结SessionID&SessionTicket.

  https://blog.csdn.net/justinzengtm/article/details/105491809

• [8]. TLS简单笔记-Session ID和Session Ticket