ssl协议 Session ticket关联TLS流方法分析

本文主要是介绍ssl协议 Session ticket关联TLS流方法分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

ssl协议握手过程在上一篇中已经写过了现在对比session id与 Session ticket 之间的区别

1.session id 通过ssl握手的时候由service发送给client端,session id 的信息(协商秘钥等)回报存在service端每个session id大概会占用nginx 1m内存.使用它的好处是之后的ssl握手不需要再传证书验证了只需要client端发送session id 服务器端收到后会自动的去内存里面找如果找到则用内存中存储的秘钥信息进行验证,验证通过直接传送数据.

缺点是在对同一域名的两次连接时的抓包，发现Session ID重用失效，重新建立了新的TLS连接。仔细检查发现两次连接到了两个不同的IP。这是因为服务器使用了负载均衡，一个域名对应了多个ip，会根据服务器的负载情况动态调整。Session ID A是保存在服务器A上的，服务器B没有Session ID A的记录。就导致了Session ID复用的失效。

2.Session ticket

　一个会话ticket是一个加密的数据blob，其中包含需要重用的TLS连接信息，如会话key等，它一般是使用ticket key加密，因为ticket key服务器端也知道，在初始握手中服务器发送一个会话ticket到客户端，存储到客户端本地，当重用会话时，客户端发送会话ticket到服务器，服务器解密然后重用会话。

缺点是,

　　会话ticket有潜在的安全问题，一些TLS加密组件如ECDHE-RSA-AES128-SHA256提供一个安全属性成为向前安全forward secrecy，如果黑客获得了服务器的证书私钥，他们也不能获得会话来破解。

　　使用TLS 会话ticket，偷窃了ticket key1后不会允许黑客来解密先前的会话，这是的ticket key非常有价值，为了保持向前安全forward secrecy, ticket key应该经常轮换。

　　会话ticket重用在Apache中可以用SSLTicketKeyDefault 配置，在nginx中使用ssl_session_tickets，它们都没有自动轮换ticket key的自动机制，只能通过重启apache nginx来重新加载或创建新的随机key。