浏览器关闭https校验_HTTPS如何防止重放攻击？

关注后你就是我的人了

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

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

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

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

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

TLS1.3如何应对？

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

以上就是小编为大家分享的所有内容，有想了解更多资讯或相关知识，可以关注公众号；程序员大咖(CodePush)

技术文章原创，最新视频分享等等，一大批干货正在路上，想看的朋友记得点关注哦!