- 2019-08-28session tiket 没听明白，服务端和客户端如何得到对称密钥？使用什么解密的？谢谢
作者回复: 1、首次握手正常生成对称密钥，server将其放入ticket中，加密后发给client，client解密后保存。
2、后续握手时，client将加密ticket发给server，server解密后获得对称密钥。此时双方都有对称密钥，可以通讯。
3、为防止client恶意修改ticket信息，实际server还有一个加密hash，防止client延长ticket超时时间。具体参见https://tools.ietf.org/html/rfc5077第4部分。 1 1 
2019-08-15TLS1.3的 0RTT, 和 session 都需要服务器端为每个连接缓存一些信息，当连接数量级非常大的时候，需要消耗的服务端资源就非常多了
是不是应为这个弊端会导致现在 TLS1.3的 0RTT, 和 session 用的不是很多的？作者回复: 也有安全性上面临重放攻击的原因
1
2019-12-30老师好，
关于重放攻击我有个疑问，如果只是拦截加密封包，然后再次传输给server去更改DB资料的状态，是不是不需要0RTT就可以做到了？在没有密钥的情况下，任何时候拦截到的封包应该都是无法解密密的封包，只需要把这封包一直丢给server是不是就可以实现重放攻击，未必要通过0RTT才能实现？
谢谢老师的解答^^作者回复: TLS通讯过程中是有加密后的序列号保护的，如果不是从握手处做重放攻击是无法生效的。
2019-12-29老师我的理解默认每一个TCP链接都需要一个SSL握手，如果多个链接是同一个事务。就需要复用SSL SESSION ID。这样理解对吗？在哪个连接上复用SL SESSION ID是服务器控制还是浏览器控制呢？作者回复: 同一个事务为什么要使用多个TCP连接呢？
浏览器控制的，服务器只要接收到有效的session id，就复用之前的加密参数。
2019-08-09老师，服务器会保留每个连接的客户端的公钥吗作者回复: 公钥是配置在服务器的，不用保留