夜已深,注意休息哦!

编程开发

前后端分离项目接口数据加密的秘钥交换逻辑(补充:MITM中间人攻击)

2020年05月27日 16:46:47 · 本文共 1,252 字阅读时间约 4分钟 · 4,726 次浏览
前后端分离项目接口数据加密的秘钥交换逻辑(补充:MITM中间人攻击)

之前我写到《前后端分离项目接口数据加密的秘钥交换逻辑(RSA、AES)》,解释了前后端在交互数据时候的加解密策略,随着我对网络编程的理解和掌握,两个月后,我必须再写一篇补充的文章,来给我之前的文章打个补丁,因为使用不当还是无法做到绝对安全,上一篇文章没有提中间人攻击,这次我补上。

中间人攻击的产生

上一篇文章《前后端分离项目接口数据加密的秘钥交换逻辑(RSA、AES)》描述了秘钥交换的过程,但这个过程真的绝对安全吗?随着我对网络编程的理解和掌握,我还需要给我之前的文章打个补丁,提醒一下其中的安全隐患,那就是中间人攻击,那中间人攻击是如何产生的呢?我们想象一下如下场景:

我们傻白甜的客户端想要向服务器大哥发起请求服务器「Server公钥」的请求,但这个时候可能DNS被劫持,又或者网络路由被劫持,把我们客户端发出去的数据包劫持到了一个黑山老妖那里,黑山老妖收到信以后仿照着服务器的口气写了一封回信,我们傻白甜的客户端收到这个黑山老妖的回信,但并不知道对方不是服务器大哥,就信以为真,就这样跟黑山老妖交换了秘钥,并且发送了账号和密码,这就导致黑山老妖拿到了用户的账号和密码。后续,黑山老妖把收到的客户端信件拆包解密,然后伪装成客户端给服务器大哥重新装好信封转发过去,这样我们傻白甜的客户端和服务器大哥之间的通信都被黑山老妖解密和收集了。

解决信任问题

根据上面我导演的场景,其实这是个信任的问题,我们傻白甜的客户端为什么要信任收到的信件呢?因为缺少身份证明对吧?那就必须要提一下HTTPS了,使用HTTPS不仅仅能加密流量,还可以识别对方的身份,因为SSL证书里面会有Domain字段,也就是域名,这样可以有效防止有人冒充服务器大哥。

所以,想要安全的传输数据,不仅仅要有正确的加密逻辑,还必须要上HTTPS才可以。

DNS劫持问题

有了SSL证书基本已经可以解决了,但追求完美的我怎么能不把问题解决完呢?上面还提了DNS劫持问题呢。面对DNS污染、DNS劫持,有两个方面的建议。

1.在域名解析那里启用 DNSSec,Domain Name System Security Extensions (DNSSEC)DNS安全扩展,是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535)。它提供了一种来源鉴定和数据完整性的扩展,但不去保障可用性、加密性和证实域名不存在。

由于目前国内的公共DNS服务大部分都不支持DNSSec,所以还有第二条建议。

2.使用HTTPDNS来解析域名,不走传统的DNS解析,而是走基于HTTP协议的DNS服务,当客户端需要DNS解析的时候,直接通过HTTP协议进行请求这个域名的解析结果。

关于HTTPS抓包

我建议使用HTTPS的时候,肯定会有杠精反驳,HTTPS也可以被抓包,是的,如果你自己使用抓包软件,是可以被抓取,但是前提是你得在客户端导入抓包工具的CA证书,如果普通用户的手机或者电脑里没有这个抓包工具的CA证书,那抓包工具重新装包的SSL证书是不被信任的,客户端会拒绝连接。如果硬件设备已经沦陷,你再谈后续的安全,是不是耍流氓呢?

总结

核心内容是使用HTTPS并且不要轻易信任第三方证书,一定要从系统CA证书链中验证,这样就解决了信任问题,再加上我上一篇的文章,这样信任问题和加密问题就都具备了。

商业用途请联系作者获得授权。
版权声明:本文为博主「任霏」原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.renfei.net/posts/1003373
评论与留言

以下内容均由网友提交发布,版权与真实性无法查证,请自行辨别。

微信搜一搜:任霏博客