http与重放攻击

Posted 2023-03-23

参考技术A

HTTP报文在客户端与服务器之间传输的形式是明文，在传输的过程中，HTTP报文会经过很多网络节点，首先是局域网的路由器（例如家庭的路由器），然后是运营商的交换机或路由器，接着到目标服务器所在局域网的路由器，最终到达目标服务器，被它接收。

之所以说HTTP不安全，是因为传输的数据是明文，在客户端与服务器之间传输的过程中，也就是明文经过中间的网络节点时，存在被嗅探的风险。

攻击方式：

（1）在运营商的交换机或路由器上嗅探流量。

（2）WiFi劫持，假WiFi中间人。

HTTPS的 "S" 是 "SSL"，在HTTP的基础上再增加一个协议，这个协议用于协商加密算法，位于传输层与应用层之间，在应用层的数据（例如 HTTP 报文）往下传给传输层之前，SSL对数据进行加密，然后再把密文封装到传输层协议中。

HTTP报文被加密后，即使攻击者在传输过程中捕获到报文，也无法解密成明文。攻击者无法理解报文的内容，也就无法窃取或篡改数据。这就保证了数据的保密性和完整性。

假设网站的前端与后端的通信协议是 HTTP ，在传输用户的登录口令时，可以在传输之前，前端计算口令的 MD5 值，然后再发送给服务器，这样可以尽可能地保证口令被窃取后不被破解。

攻击者可以截获报文，例如一个登录的请求报文，然后再发送一次给服务器，从而成功登录受害者的账号。

要防御这种攻击，可以在请求报文中加一个随机值（或者 salt），这个随机值可以和口令一起计算 MD5 值，也可以用一个独立的参数存储，被请求报文携带，发送到服务器上。在服务器上，也存储相同的随机值，用于验证从客户端发送过来的随机值。

最重要的一点是，这个随机值最好是一次性的，即使用一次就失效。这样的一次性正好挫败了重放攻击的重复性，也就防御了攻击。

我们先来回忆一下HTTPS的通信流程，HTTPS协议 = HTTP协议 + SSL/TLS协议，摘取一下网上一些八股文的回答(以RSA密钥交换的为例)！

画外音: 是不是贼熟悉，有背过网络八股文的，一看就懂！

关键问题就在步骤(6)，怎么进行加密的？很多文章都没有说明，甚至有的人以为，拿client_random+server_random+pre_master_secret直接拼成一个字符串，然后就是对称加密密钥，客户端和服务端拿这个密钥对数据进行加密通信！！

对此，我只能说:"Too young too simple!离谱啊！！"

那正确的过程是怎么样的呢，我们继续往下看！

我先给本文提到的英文单词，给上我的中文翻译，以防大家混淆:

先大致有个印象，继续往下阅读

现在我们已经有三个参数client_random，pre_master_secret，server_random，服务端和客户端分别会根据这三个参数，推导出master_secret，一旦master_secret被推导出来，会立刻删除pre_master_secret。( 摘自rfc2246,section8.1 ）

当master_secret计算出以后，立刻计算key_block( 摘自rfc2246,section6.3 )，这个密钥块，有的文章里又说他是会话密钥！计算公式如下，

如公式所示，PRF是一个Hash算法，如SHA256这些，具体用哪一个取决于TLS协议的版本！我们得到key_block后，可以基于到key_block继续推导出6个密钥值，分别是

整个过程用一张图来说明，注意了这六把密钥是根据key_block推导而出，也就是意味着这六把密钥是服务端和客户端共同持有的！

[图片上传失败...(image-dd960a-1651718824022)]

大家一定也发现了，你的密钥前都带有client或者server前缀，这代表密钥是服务端使用还是客户端使用！例如，客户端用client_write_key进行数据加密，发送数据，服务端收到消息后利用client_write_key进行解密。而后服务端使用server_write_key进行数据加密回复信息，客户端收到消息后用server_write_key解密服务端发来的信息！

OK，我们继续往下看！
现在我们已经有了6把密钥了，已经需要发送的消息data，那么加密流程具体怎么样的呢？
TLS一共有三种加密模式，流加密模式、分组模式、 AEAD 模式，我以流加密模式来进行说明，如下图所示

[图片上传失败...(image-2ae534-1651718824022)]

我们现在来看上面的第二步，利用write_mac_key对数据加密，加上MAC验证码，利用MAC码来保证完整性。

那么，这个MAC验证码的生成公式又是怎么样的呢？

在流加密模式下，MAC验证码公式为( 摘自rfc2246,section6.2.3.1 )

[图片上传失败...(image-f2482f-1651718824022)]

看到入参中的seq_num了么？ 这就是数据的序列号，这个序号就是用来防止重放攻击的！ 那这个序列号怎么用的呢？
假设，此时服务端和客户端连接成功后 (1) 客户端会在内存中记录 client_send 和 client_recv，默认值为0.客户端每发送一条消息，client_send 会加1，每接收一条服务端发来的消息，client_recv 会加1。 (2) 服务端也会在内存中记录 server_send 和 server_recv，作用和客户端的作用一样。服务端每发送一条消息，server_send 会加1，每接收一条客户端发来的消息，server_recv 会加1。 (3) 客户端发送数据时，以当前client_send作为seq_num,计算mac值，发送给服务端，然后client_send加1。 (4) 服务端收到消息后，先以当前server_recv值，进行完整校验，校验成功后server_recv加1。然后以server_send为作为seq_num,计算mac值，发送给客户端，然后server_send加1。 (5) 也就是说，如果发送和接收都正常，那么 client_send = server_recv、client_recv = server_send

假设，客户端和服务端相互通信了4次，client_send = server_recv=3(从0开始，所以是3)，服务端检验完第4次消息后，server_recv加1，此时server_recv=4。攻击者如果想重放第4次消息，第4次消息中的client_send值是3，就会出现校验失败的情况！从而能够抵挡住重放攻击！

OK，讲到这里，基本上能回答最开始提出的问题了！

当然，TLS协议本身的内容比较多，我在这里放上TLS协议的地址，大家有兴趣可以自己去查看:
https://www.rfc-editor.org/rfc/rfc2246.html

假设，我们用符号[]表示一次TCP连接，0,1,2,...代表数据包序号，根据上面的分析，对于这种形式的重放攻击，[0,0,0,1,1,2,2,3,3,3….]，HTTPS协议是能够拦截的！
那如果不是一次请求里的重放攻击呢？例如形式是[0,1,2,3….],[0,1,2,3….]，这种形式的重放攻击，HTTPS协议能够拦截么？有答案，可以在留言区进行回复！

提示 :想一想看，最开始的客户端随机数和服务端随机数的作用!

在 HTTP 连接中使用基于令牌的身份验证时如何防止重放攻击

【中文标题】在 HTTP 连接中使用基于令牌的身份验证时如何防止重放攻击

【英文标题】：How to prevent replay attacks when using token based authentification in an HTTP connection

【发布时间】：2017-09-05 18:32:16

【问题描述】：

在使用基于令牌的身份验证（例如：JSON Web 身份验证）时，如何防止重放攻击并向我的应用程序添加另一层加密？

【参考方案1】：

如果您想保护您的应用程序身份验证免受重放攻击，您可以包含随机数 (jti)、到期时间 (exp) 和发布时间 (iat)。

有关详细信息，请参阅spec。

更多细节。

重放攻击（也称为回放攻击）是一种网络形式 恶意或恶意有效数据传输的攻击 欺诈性地重复或延迟。 [wikipedia]

因此，如果您使用随机数，则数据只能传输一次，因此无法重新传输。这可以防止经典的重放攻击。

为了避免延迟攻击，使用了过期时间和发布时间。这种攻击不仅包括捕获数据流量，还包括中断受害者的流量。中断交通需要时间。当然，使用到期时间和发布时间并不是 100% 的解决方案，但如果您明智地选择这些值，则可以将风险降至最低。

【讨论】：

我不明白这如何防止重放攻击，因为攻击者可以在到期时间到达之前拦截数据包并发送到服务器，声称他是合法用户。尽管如此，我什至看不到 https 是如何阻止这种事情的，即使请求被加密，攻击者也可以随时拦截请求并发送它以从服务器获得正确的响应！

@salutent 请查看我的更新答案我添加了一些细节。

我知道了。如果攻击者中断流量并将数据包发送到声称他是合法发件人的服务器，如果我的到期时间设置为 3-4 分钟，这应该不是一个真正的问题？

@salutent，您选择的时间取决于您的基础架构和网络等因素。例如，如果您在本地网络中操作，则到期时间可能比在移动网络中操作要短得多。在我看来，您应该根据自己的环境凭经验确定到期时间。

【参考方案2】：

您可以使用 https。你应该使用 https。