27 | 更好更快的握手:TLS1.3特性解析
该思维导图由 AI 生成,仅供参考
最大化兼容性
- 深入了解
- 翻译
- 解释
- 总结
TLS1.3是一项旨在提高互联网安全性和性能的新协议,于2018年推出。该协议通过扩展协议实现了后向兼容,并引入了新的扩展字段来标记协议版本,以提高兼容性。在安全方面,TLS1.3修补了TLS1.2存在的漏洞和弱点,升级了伪随机数函数,废除了不安全的加密算法和分组模式,只保留了少数安全算法和参数组合。此外,TLS1.3还引入了“前向安全”概念,废除了RSA和DH密钥交换算法,确保通信的安全性。在性能方面,TLS1.3通过简化密码套件和协商流程,将握手时间减少到“1-RTT”,提高了效率。文章还提到了TLS1.3的握手过程,以及与TLS1.2的“False Start”进行了比较。总的来说,TLS1.3的推出标志着信息安全领域的新标准,为互联网安全和性能带来了重大改进。
《透视 HTTP 协议》,新⼈⾸单¥59
全部留言(33)
- 最新
- 精选
- djfhchdh1、TLS1.3精简了加密算法,通过support_groups、key_share、signature_algorithms这些参数就能判断出密钥交换算法和签名算法,不用在cipher suite中协商了 2、RSA握手时,client key exchage会使用RSA公钥加密pre master后传给服务端,一旦私钥被破解,那么之前的信息都会被破译,根本原因还是在于RSA的这一对公钥私钥并不是临时的。 3、相同点:都在未收到Finished确认消息时就已经向对方发送加密信息了,不同点:TLS1.3将change cipher spec合并到了hello中
作者回复: great。
2019-07-29351 - 前端西瓜哥2. 结合上一讲的 RSA 握手过程,解释一下为什么 RSA 密钥交换不具有“前向安全”。 答:RSA 握手中,Server Hello 后,客户端拿到服务器的证书,从中提取出服务器的公钥,然后用这个公钥去加密客户端生成的一个随机数(会话密钥)得到密文,然后将其返回给服务器。虽然每次 TLS 握手中的会话密钥都是不一样的,但服务器的私钥却始终不会变。一旦黑客拿到了服务器私钥,并且截获了之前的所有密文,就能拿到每次会话中的对称密钥,从而得到客户端和服务器的所有“历史会话记录”。 说到底,RSA 握手下,服务器私钥是不变的,从而导致不具有“前向安全”。而 ECDHE 的私钥却是动态的,黑客拿到了一个,也只能解密一个密文。
作者回复: 回答的非常好。
2019-07-3128 - 彦页老师,客户端验证服务器证书,为什么不是pre_master计算出来才检验证书?因为服务器已经把证书加密传输的啊?
作者回复: 这里有个细节没讲,其实tls1.3有多个加密密钥,在握手的时候,服务器发来的数据会用server_handshake_traffic_secret进行加密,而这个密钥也是由HKDF算出来的。 所以客户端先生成server_handshake_traffic_secret,把服务器握手消息解密,取出证书,验证证书,都没问题,才计算pre-master。
2019-07-3128 - 李鑫磊请教老师,一直没看懂,“秘钥交换算法参数”究竟是什么?
作者回复: 可以参考“答疑篇”,讲ecdhe算法,参数就是算法的公钥、曲线定义。
2019-12-065 - Unknown element老师client param不是和具体采用的密码套件有关吗 那tls 1.3中客户端是如何在服务器返回采用的密码套件之前把这个参数发给服务器的?还是说客户端把仅有的几个密码套件都生成了一个参数然后都发给服务器让服务器来选?谢谢老师
作者回复: 是的。 因为tls1.3只有很少的几个密码套件,所以客户端就全生成好,发给服务器,然后服务器再挑一个,这样就省去了来回协商的麻烦。 可以再看看抓包数据。
2021-09-293 - Geek_534344TLS1.3中,服务端的证书有什么作用呢?
作者回复: 和TLS1.2的作用是一样的,验证服务器身份,对握手数据签名。 1.3只是简化了1.2的握手步骤,基本原理还是一样的。
2021-04-062 - 俊伟1.1.3在握手时指定了supported groups和key share和signature algorihms,服务器从这些参数中就能判断出密钥交互算法和摘要算法。 2.因为RSA是客户端算出pre master发送到服务端,算出来的master secret是固定的,随着时间的推移,有被黑客算出来的风险。 3.TLS1.2是客户端率先算出master secret,然后发送Application data 而TLS1.3是服务端优先算出master secret,发送Application data。
作者回复: 经过了认真的思考,回答的非常好!
2020-01-172 - 彩色的沙漠希望老师对TLS1.3增加一篇补充,里面涉及的细节大家不是很清楚怎么回事,网上资料少还容易误导。 1、服务器返回的Encrypted Extensions(被加密的扩展信息),加密的扩展信息里面不包含key_share和support_groups,这两个关键参数因为加密之后,无法计算pre-master。问题是加密的扩展信息使用的是哪个密钥对? 2、原文中“在算出主密钥后,服务器立刻发出“Change Cipher Spec”消息,比 TLS1.2 提早进入加密通信,后面的证书等就都是加密的,减少了握手时的明文信息泄露。问题是,除了证书还有那些参数使用加密传输,以及使用的是个密钥对?客户端不先计算pre-master何master-secret,怎么解密证书,进行验证? 3、server certificate verify,使用证书签名握手数据,Finished也是对握手数据进行摘要签名,它用的是master-secret进行的签名吗?
作者回复: 这些比较细节和底层,如果想要认真研究还是建议去看rfc。 我简单解释一下: 1.tls1.3使用了多个对称密钥,服务器在握手Encrypted Extensions时使用的不是pre-master,而是server_handshake_traffic_secret。 2.可以参考课程里简略流程图,里面列出了那些记录,而具体的扩展字段会因密码套件而变化。 3.Finished消息与tls1.2的一样,是用会话密钥,也就是master secret加密的。
2019-08-052 - geraltlaush老师,我对比了下tls1. 2和1.3,发现pre master根本就是多余的嘛,双方有个公共K, A=a*K发给服务端,服务端生成B=b*K,双方就可以利用a*b*K=b*a*K的相同密钥进行通信了,1.2是需要客户端把premaster发给服务端,然后双方a*b*K*pre master=b*a*K*pre master的对称密钥进行通信,1.3就是少了pre master,可以这样理解吧
作者回复: 不是的。 还是要有pre-master,注意tls通信使用的master key需要三个随机数生成,其中客户端和服务器的随机数是公开的,而pre-master是加密传输。 tls1.3只是简化了握手过程中的密码套件协商,还是要交换密钥参数算pre-master的。 如果是自己内部的系统,当然可以不用tls那么复杂,直接一个随机数当会话密钥。 可以再看一下tls1.3的握手流程图,里面还有pre-master。
2019-07-3032 - ifelse都是干货
作者回复: thanks.
2023-01-31归属地:浙江1