TLS/SSL(十) session缓存、ticket 票据、TLS 1.3的0-RTT

一  TLS优化手段

TLS 为了提升'握手速度'而提出'优化'手段,主要是减少TLS握手中'RTT'消耗的时间
 
关于'session cache'和'session ticket',nginx关于'ssl'握手的地方都有'影子 [指令]'

https面经

①  session 缓存

resume: '重用','复用'

案例： 第二次访问'www.baidu.com' 
 
说明： 第二次访问是没有'Session ID'的

细节点： 没有'Server Key Exchange'的过程

1、第一次握手后,服务器会生成一个session id,这个session id 会传给'浏览器'
 
2、当在'一定'时间之内,浏览器或'客户端'携带这个'session id'访问服务器
 
3、服务器从'自己的内存'或'其它缓存中'获取到这个'session id'对应的'加密密钥'
 
4、服务端给'客户端'说就使用'上一次'的'加密密钥'就可以,不需要使用'DH|ECDH'再次生成新的密钥
 
备注： 
 
  1、对'client'的要求: 在一定的时间内缓存'session id'以及自身所对应的'加密密钥'
 
  2、对'server'的要求：在一定的时间内缓存'session id'以及自身所对应的'加密密钥'

②  session ticke

+++++++++++++  'session 缓存'具有'两个'问题  +++++++++++++
 
问题1： 负载均衡导致'session id'不生效
 
  1、server端往往是在'内存'中存放'session id' 和对应的'密钥'信息
 
  2、对于不同主机的server是'没有办法分享'session id 和对应的密钥信息
 
  备注： server往往是以'反向代理集群'的方式提供'服务'的
 
  3、A为client 生成一个session id,当B访问时候,请求到Server B上,Server B需要重新握手
 
问题2：  session id存储在内存中,是有'内存消耗'的,到底'缓存多长时间'呢?
 
思考： server 之间如何共享复用session id 呢?  --> '引出了session ticket'

1、 session ticket的处理方式与'session id 缓存'完全不同的
 
2、 server端不需要'耗费'内存来存放session信息 'session id'和'密钥'
 
3、 而是基于一个'独有'的密码,这个密码是'server 集群'共同分享的密码
 
4、 基于这个密码把'相关的信息'加密,发送给'client'
 
5、 客户端'下一次'需要握手的时候,把相关的'加密信息'发送给'server端'
 
6、 只有这个'server 集群'内的机器才知道这个'密码',然后解密,获取上一次握手成功后的'密钥'
 
7、 基于此,server端就可以与'基于内存中保存的密钥的client'进行通信

③  TLS1.3的0-RTT握手

TLS 1.3和0-RTT

特点： 第一次'握手'的时候就'携带'相关数据,第二次握手才能实现'0-RTT'
 
备注： TLS1.3 中是省去了'安全套件的协商',直接'把五种密钥'都发过去

④  0-RTT 面临的重放攻击  了解

 TLS与量子通讯的原理    量子通讯BB84协议的执行流程