HTTPS如何防止重放攻击?

来自:车小胖谈网络 (微信号:chexiaopangnetwork),作者:车小胖谈网络

HTTPS是否实现了Diffie–Hellman秘钥交互算法来防重放攻击?

看了很多回答HTTPS原理的文章,都说HTTPS主要是通过RSA+AES来加密数据的,而这个AES秘钥是浏览器端随机生成的,是否是真的这样,如果是如何防止重复攻击?还是通过Diffie–Hellman来交换秘钥的?

 


这个问题描述让人无法看懂,让我来帮助提问者理理思路。

 

TLS握手协商阶段

 

  1. 浏览器发送Client Hello消息,包含明文的Client Nonce。

  2. 服务器将自己的RSA公钥、随机产生的Server Nonce一同推送给浏览器。

  3. 浏览器用服务器的RSA公钥,加密一个48字节的随机字符串(Secret),发给服务器。

  4. 服务器用RSA私钥解密,得到Secret。

 

成功交换以上两次消息,双方共同拥有三个参数:

 

  • Secret

  • Client Nonce

  • Server Nonce

 

双方使用相同的推导函数,会得到相同的数据加密密钥、校验密钥,就可以快乐而私密的聊天了。

 

现在轮到小黑登场了,小黑捕获过上文的消息13,小黑要假冒浏览器。

 

  1. 小黑将消息1原封不动发出去(Replay)。

  2. 服务器不以为诈,当做正常握手包处理,回复消息2,但是要注意,Server Nonce变了,假设为Server Nonce 2。

  3. 小黑将消息3原封不动发出去(Replay)。

  4. 服务器用RSA私钥解密,得到Secret。

 

很显然,三个参数有一个已经改变了,最后推导出的密钥信息也会响应变化。

 

此外,小黑无法得到明文的Secret,所以小黑无法成功推导密钥信息。

 

使用DH交换密钥,同样可以克服重放攻击威胁。

 

数据传输阶段

小黑铩羽而归,闷闷不乐,既然无法攻击TLS的握手阶段,那就重放攻击数据发送阶段。小黑将刚捕获的加密报文M,发送给服务器。

 

小黑复制报文到达服务器之前,原始的报文M已经到达服务器,编号为N,处理完成。

 

当服务器将再次收到报文M时,编号为N + 1。服务器需要先进行校验,最终校验失败。

 

为何会校验失败?

浏览器发出校验码的时候,是以序号N计算的,而服务器是以序号N + 1计算的,怎么可能校验通过?

 

TLS历经了1.01.11.21.3版本的升级,始终把重放攻击当做一个重大的威胁,但是为了减少握手阶段的延迟,通常会做出一些妥协。TLS 1.3允许在第一个消息里携带Data,这样就意味着0 RTT极速通信。通常使用0 RTT通信的场景,是重复使用历史加密参数(类似Session ID),意味着服务器可以立马解密报文,并将Data提交给应用程序。

 

应用程序可能还会响应,小黑能不能接到、小黑能不能解密响应报文都不重要,重要的是,小黑已经成功让服务器做出了动作,这是一次成功的重放攻击。

 

TLS1.3如何应对?

TLS 1.3建议,凡是一些重要的写、修改操作,不允许0RTT访问。服务器还可以将0RTT通信彻底关闭,以杜绝重放攻击的威胁。

 

为什么会写这篇文章,答案全在这篇文章里:如何看待思科取消CCIE Routing& Switching?

推荐↓↓↓
黑客技术与网络安全
上一篇:https到底把什么加密了? 下一篇:真船借箭:盘点行动中攻击者的绝密武器