透视 HTTP 协议
罗剑锋(Chrono)
前奇虎 360 技术专家,Nginx/OpenResty 开源项目贡献者
63943 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 48 讲
开篇词 (1讲)
透视 HTTP 协议
15
15
1.0x
00:00/00:00
登录|注册

27 | 更好更快的握手:TLS1.3特性解析

TLS1.3握手与TLS1.2的False Start异同
RSA密钥交换的前向安全性
密码套件问题
安全强化措施
主密钥生成
服务器Hello消息
客户端Hello消息
0-RTT握手
1-RTT握手
前向安全
算法精简
修补不安全因素
扩展协议
伪装成TLS1.2
课下作业
握手分析
性能提升
安全性
兼容性
TLS1.3新特性

该思维导图由 AI 生成,仅供参考

上一讲中我讲了 TLS1.2 的握手过程,你是不是已经完全掌握了呢?
不过 TLS1.2 已经是 10 年前(2008 年)的“老”协议了,虽然历经考验,但毕竟“岁月不饶人”,在安全、性能等方面已经跟不上如今的互联网了。
于是经过四年、近 30 个草案的反复打磨,TLS1.3 终于在去年(2018 年)“粉墨登场”,再次确立了信息安全领域的新标准。
在抓包分析握手之前,我们先来快速浏览一下 TLS1.3 的三个主要改进目标:兼容安全与性能

最大化兼容性

由于 1.1、1.2 等协议已经出现了很多年,很多应用软件、中间代理(官方称为“MiddleBox”)只认老的记录协议格式,更新改造很困难,甚至是不可行(设备僵化)。
在早期的试验中发现,一旦变更了记录头字段里的版本号,也就是由 0x303(TLS1.2)改为 0x304(TLS1.3)的话,大量的代理服务器、网关都无法正确处理,最终导致 TLS 握手失败。
为了保证这些被广泛部署的“老设备”能够继续使用,避免新协议带来的“冲击”,TLS1.3 不得不做出妥协,保持现有的记录格式不变,通过“伪装”来实现兼容,使得 TLS1.3 看上去“像是”TLS1.2。
那么,该怎么区分 1.2 和 1.3 呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
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)

  • 最新
  • 精选
  • djfhchdh
    1、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-29
    3
    51
  • 前端西瓜哥
    2. 结合上一讲的 RSA 握手过程,解释一下为什么 RSA 密钥交换不具有“前向安全”。 答:RSA 握手中,Server Hello 后,客户端拿到服务器的证书,从中提取出服务器的公钥,然后用这个公钥去加密客户端生成的一个随机数(会话密钥)得到密文,然后将其返回给服务器。虽然每次 TLS 握手中的会话密钥都是不一样的,但服务器的私钥却始终不会变。一旦黑客拿到了服务器私钥,并且截获了之前的所有密文,就能拿到每次会话中的对称密钥,从而得到客户端和服务器的所有“历史会话记录”。 说到底,RSA 握手下,服务器私钥是不变的,从而导致不具有“前向安全”。而 ECDHE 的私钥却是动态的,黑客拿到了一个,也只能解密一个密文。

    作者回复: 回答的非常好。

    2019-07-31
    28
  • 彦页
    老师,客户端验证服务器证书,为什么不是pre_master计算出来才检验证书?因为服务器已经把证书加密传输的啊?

    作者回复: 这里有个细节没讲,其实tls1.3有多个加密密钥,在握手的时候,服务器发来的数据会用server_handshake_traffic_secret进行加密,而这个密钥也是由HKDF算出来的。 所以客户端先生成server_handshake_traffic_secret,把服务器握手消息解密,取出证书,验证证书,都没问题,才计算pre-master。

    2019-07-31
    2
    8
  • 李鑫磊
    请教老师,一直没看懂,“秘钥交换算法参数”究竟是什么?

    作者回复: 可以参考“答疑篇”,讲ecdhe算法,参数就是算法的公钥、曲线定义。

    2019-12-06
    5
  • Unknown element
    老师client param不是和具体采用的密码套件有关吗 那tls 1.3中客户端是如何在服务器返回采用的密码套件之前把这个参数发给服务器的?还是说客户端把仅有的几个密码套件都生成了一个参数然后都发给服务器让服务器来选?谢谢老师

    作者回复: 是的。 因为tls1.3只有很少的几个密码套件,所以客户端就全生成好,发给服务器,然后服务器再挑一个,这样就省去了来回协商的麻烦。 可以再看看抓包数据。

    2021-09-29
    3
  • Geek_534344
    TLS1.3中,服务端的证书有什么作用呢?

    作者回复: 和TLS1.2的作用是一样的,验证服务器身份,对握手数据签名。 1.3只是简化了1.2的握手步骤,基本原理还是一样的。

    2021-04-06
    2
  • 俊伟
    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-17
    2
  • 彩色的沙漠
    希望老师对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-05
    2
  • 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-30
    3
    2
  • ifelse
    都是干货

    作者回复: thanks.

    2023-01-31归属地:浙江
    1
收起评论
显示
设置
留言
33
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部