MITM 与 HTTPS 流量劫持


VPS 硬盘挂之前,blog 里留了一篇文章,如何使用 redsocks + linux policy based routing 实现对手机 HTTPS 流量的劫持。具体方案懒得再写了。简单描述一下原理,后边的文章会需要引用。

An illustration of the man-in-the-middle attack

上图是引用自 Wikipedia 的中间人攻击的页面

最古老的年代,通信缺少加密,所以中间传信的人可能能看到并篡改内容。后来,从算法保密,到算法公开密钥保密,再到后来 PKI 的出现,逐渐实现了相对安全的加密通信。

但是,从开发、调试和安全研究的角度看,在拿不到 SSL/TLS 通信密钥的情况下,中间人攻击是协议调试的一个重要手段。(当然,如果能拿到 SSL/TLS 通信密钥,例如可以修改 SSL/TLS 握手的库,记录下来,就可以直接 tcpdump/wireshark 抓包,再用 wireshark 填入密钥就可以解密了。)

加密通讯的中间人攻击,第一个典型场景的必要手段是让客户端信任中间人的证书,常见的手段:

  • 例如客户端不校验证书(签发者,时间,Common Name等),
  • 或者当客户端使用系统的方法和系统的 CA 库去校验的时候,安装自签的 CA 证书再用这个 CA 去签发被劫持的证书,
  • 甚至 Patch 的方式替换原有程序里写死的证书或证书策略(例如 Android)。

第二个典型的必要手段是劫持流量,或者信道。常见的做法:

  • 如果被劫持的目标对象使用系统的代理,或者有代理设置的选项,修改这个选项。
  • 如果该目标不使用代理,但是系统平台有方法劫持,例如 proxifier(一个值得买的 win/mac 代理工具),使用 proxifier 可以按通讯地址端口或者进程名称将应用的流量。
  • 如果是不认代理设置的运行在封闭系统(iOS / Android)下的程序,就可以考虑网络设备上 NAT + redsocks 的方案将流量转到 Charles Proxy 或者 Fiddler 的 socks 代理上。
  • 其他的,例如 iOS/mac 的 Network Extension。。。

近些年有些麻烦,一个是 Certificate Pinning,一个是 TLS 1.3。遇到自己实现的 Certificate Pinning,时间成本会上去,这里在越狱的 iOS 设备上推荐 https://github.com/nabla-c0d3/ssl-kill-switch2,可能大部分程序的检查都能绕过,FB 家的不行。TLS 1.3,如果自己实现的客户端不接受降级到 TLS 1.2或者更低,目前我无解,不知道有没有best practice。


Leave a Reply

Your email address will not be published.