透视HTTP协议
罗剑锋(Chrono)
奇虎360技术专家,Nginx/OpenResty开源项目贡献者
立即订阅
6077 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|To Be a HTTP Hero
免费
破冰篇 (7讲)
01 | 时势与英雄:HTTP的前世今生
02 | HTTP是什么?HTTP又不是什么?
03 | HTTP世界全览(上):与HTTP相关的各种概念
04 | HTTP世界全览(下):与HTTP相关的各种协议
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
06 | 域名里有哪些门道?
07 | 自己动手,搭建HTTP实验环境
基础篇 (7讲)
08 | 键入网址再按下回车,后面究竟发生了什么?
09 | HTTP报文是什么样子的?
10 | 应该如何理解请求方法?
11 | 你能写出正确的网址吗?
12 | 响应状态码该怎么用?
13 | HTTP有哪些特点?
14 | HTTP有哪些优点?又有哪些缺点?
进阶篇 (8讲)
15 | 海纳百川:HTTP的实体数据
16 | 把大象装进冰箱:HTTP传输大文件的方法
17 | 排队也要讲效率:HTTP的连接管理
18 | 四通八达:HTTP的重定向和跳转
19 | 让我知道你是谁:HTTP的Cookie机制
20 | 生鲜速递:HTTP的缓存控制
21 | 良心中间商:HTTP的代理服务
22 | 冷链周转:HTTP的缓存代理
安全篇 (7讲)
23 | HTTPS是什么?SSL/TLS又是什么?
24 | 固若金汤的根本(上):对称加密与非对称加密
25 | 固若金汤的根本(下):数字签名与证书
26 | 信任始于握手:TLS1.2连接过程解析
27 | 更好更快的握手:TLS1.3特性解析
28 | 连接太慢该怎么办:HTTPS的优化
29 | 我应该迁移到HTTPS吗?
飞翔篇 (4讲)
30 | 时代之风(上):HTTP/2特性概览
31 | 时代之风(下):HTTP/2内核剖析
32 | 未来之路:HTTP/3展望
33 | 我应该迁移到HTTP/2吗?
探索篇 (5讲)
34 | Nginx:高性能的Web服务器
35 | OpenResty:更灵活的Web服务器
36 | WAF:保护我们的网络服务
37 | CDN:加速我们的网络服务
38 | WebSocket:沙盒里的TCP
总结篇 (2讲)
39 | HTTP性能优化面面观(上)
40 | HTTP性能优化面面观(下)
答疑篇 (2讲)
41 | Linux/Mac实验环境搭建与URI查询参数
42 | DHE/ECDHE算法的原理
结束语 (1讲)
结束语 | 做兴趣使然的Hero
透视HTTP协议
登录|注册

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

Chrono 2019-07-29
上一讲中我讲了 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《透视HTTP协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • Geek_54edc1
    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
    13
  • Fstar
    2. 结合上一讲的 RSA 握手过程,解释一下为什么 RSA 密钥交换不具有“前向安全”。

    答:RSA 握手中,Server Hello 后,客户端拿到服务器的证书,从中提取出服务器的公钥,然后用这个公钥去加密客户端生成的一个随机数(会话密钥)得到密文,然后将其返回给服务器。虽然每次 TLS 握手中的会话密钥都是不一样的,但服务器的私钥却始终不会变。一旦黑客拿到了服务器私钥,并且截获了之前的所有密文,就能拿到每次会话中的对称密钥,从而得到客户端和服务器的所有“历史会话记录”。

    说到底,RSA 握手下,服务器私钥是不变的,从而导致不具有“前向安全”。而 ECDHE 的私钥却是动态的,黑客拿到了一个,也只能解密一个密文。

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

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

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

    2019-12-06
  • 张智凯
    1. TLS1.3版本在client hello时,已经指定了摘要算法,列出了所支持的椭圆曲线、基点信息。
    2. RSA做密钥交换算法时,采用的是证书里面公钥对应的私钥来加密会话密钥,一般私钥被破解,就可以得到之前截获信息的会话密钥,解密消息
    3 相同点,都是未收到响应前就把 客户端就把密钥交换算法需要的参数传了过去
    不同点,因为服务器尚未选择密钥交换算法,因此密钥交换算法的参数有多个,false start中是客户端先得到椭圆曲线的两个参数,算出master key并发起 change cipher spec,而TLS1.3则是服务器先得到这两个参数,发起change cipher spec, TLS1.3change cipher spec合并到了clienthello中

    作者回复:
    1.tls1.3用扩展协议列出了支持的密钥交换算法和签名算法,所以不需要用密码套件指定。

    2.对。

    3.对。

    2019-11-03
  • 彩色的沙漠
    希望老师对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
  • 彦页
    老师,客户端验证服务器证书,为什么不是pre_master计算出来才检验证书?因为服务器已经把证书加密传输的啊?

    作者回复: 这里有个细节没讲,其实tls1.3有多个加密密钥,在握手的时候,服务器发来的数据会用server_handshake_traffic_secret进行加密,而这个密钥也是由HKDF算出来的。

    所以客户端先生成server_handshake_traffic_secret,把服务器握手消息解密,取出证书,验证证书,都没问题,才计算pre-master。

    2019-07-31
  • ClassNotFoundException
    有点纠结ECDHE算法,为什么这个算法可以保证pre-master是唯一的,而服务端又能准确的知道呢

    作者回复: 这个涉及到算法的内部细节了,比较复杂,比如离散对数、椭圆曲线什么的,可以看看相关的资料。

    其实如果不是专门做加解密的话,不需要了解太深入的细节。

    2019-07-30
  • Leon📷
    这时只交换了两条消息,客户端和服务器就拿到了四个共享信息:Client Random和Server Random、Client Params和Server Params,两边就可以各自用 ECDHE 算出“Pre-Master”,再用 HKDF 生成主密钥“Master Secret”,这样主密钥的参数都是明文的,不是暴露了吗

    作者回复: 密钥交换算法ECDHE保证了pre-master的安全性,黑客即使截获了Client Params和Server Params,也是无法算出pre-master的。

    2019-07-30
  • Leon📷
    老师,我对比了下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
    1
  • 阿锋
    HTTPS再怎么进行优化,相比于之前的HTTP都增加了性能损耗,但是为什么HTTPS的网页会比HTTP的要快。我是通过下面这个网页测试的。
    https://www.httpvshttps.com/

    作者回复: 有很多因素,不一定https比http要快,如果使用了http/2,还有0-rtt,https是和http/1.1性能上差不多的。

    单从理论上分析,https多了加解密运算,是会慢一点,但可以用一些手段去优化,优化过的https可能会比未优化的http快。

    2019-07-29
  • -W.LI-
    老师,之前比喻的协议和协议之间嵌套关系就和快递一样。子协议之间的嵌套关系也是这样么?还是说这些子协议只是在某几个请求里有。之后就没了。

    作者回复: TLS里的子协议你可以理解成模块,是多个不同的部分,互相协作起作用。

    2019-07-29
  • -W.LI-
    感觉可能和Client Params和Server Params。有关系,具体不知,请老师指点

    作者回复: 不知道你说的是哪个部分,可以补充完善一下问题。

    2019-07-29
    1
收起评论
12
返回
顶部