C24af5d62dc1b7bd38454e5c87184757
说人话的 HTTPS 协议简述——TLS1.2 瓶颈与 TLS1.3 的设计优化

说人话的HTTPS协议简述——TLS1.2瓶颈与TLS1.3的设计优化

最近因为痛风发作,加上右手腕软组织挫伤,大概有一个多月没写过长文了。停更了很久,非常抱歉。但是后面该更新还是会继续更新的。

上一篇文章讲了TLS1.2协议的握手过程,也是目前应用最广泛的过程。实际上我认为,理解这个过程的价值不在于“面试需要”,而是整个设计的思想非常值得学习,它向我们展示了一种在不安全的通道基础上,如何通过2-RTT的握手,建立安全通道的过程。这个协议的设计兼顾了性能(对数据body对称加密,对秘钥非对称加密)和安全(确认加密套件、证书验证等),随着逐渐理解的加深,会十分感慨设计之精妙。

另外,其中涉及的密码学基础,比如对称加密、非对称加密、消息摘要、证书验证等内容,易于理解,但极难精通,属于可以入门,也可以深挖的方向,我个人在学习过程中收益颇丰。工作中也经常会遇到需要设计加密协议的地方,因为虽然HTTPS【正确使用】安全,但是TLS1.3在TLS1.2的基础上,结合实际TLS1.2的使用情况,又进一步的将协议优化,支持了1-RTT的握手和0-RTT的Session恢复。

回顾

回头回顾一下TLS1.2上秘钥交换的过程:

可以看到,实际上TLS确认秘钥是一个2-RTT的过程,第一个RTT确认双端支持的加密套件,第二个RTT才真正开始生成Premaster Secret,然后才开始TCP包的加密。

需要特别提醒的是,这里不要与TCP的三次握手混淆,TLS的握手过程,并没有“取代”TCP的Syn-Ack过程。

对于具体细节想要进一步理解,可以详细阅读这一篇文章:SSL Handshake and HTTPS Bindings on IIS,非常详尽的描述了握手阶段,客户端和服务端每一步做的工作,几乎是网上能找到的最精辟易懂的文章。

第一个图里面,红框的部分之所以设计成双端需要交换支持的秘钥套件,是因为一开始TLS协议需要考虑足够的扩展性。但在十几年来的使用中,随着计算机性能的提升(暴力破解)和黑客技术的提升(side Channel攻击等)一些加密手段逐渐开始暴露出弱点,逐渐的,主流的配置基本固化成了

0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

这一行配置如果拆解开一个一个解释,可能会容易理解一点:

  • 名字为ECDHE-RSA-AES128-GCM-SHA256 的加密套件(也就是CipherSuite )
  • 用于 TLSv1.2版本
  • 使用 ECDHE 做密钥交换
  • 使用RSA做认证
  • 使用AES-128-gcm做加密算法
  • MAC 由于AES-GCM作为一种aead模式,并不需要额外做一次MAC,所以显示为aead,使用SHA256做PRF算法。

其中关于AEAD,可以参考第一篇《密码学与TLS协议结构篇》中的介绍。
关于ECDH,可以参考第一篇,或者更早之前的这一篇:https://xiaozhuanlan.com/topic/0361578492
关于PRF算法,可以参考前一篇文章中,从Premaster Key到Master key的过程。

TLS1.3的优化修改

top Created with Sketch.