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