friendlyfriendlier

@myqqai 最近我也遇到了类似需求：requestBody和responseBody都是经过密钥加密的。 我的解决方案是，部署三套anyproxy, 比如A, B和C A负责把request解密，response加密；然后用端口转发工具（或其他方法）把request转发给B。用某种方式把B的request转发到C上。C负责把request加密，response解密。这样B的request和response都是明文。浏览器或者手机设置代理到A上。我们只需要访问B就可以看到所有的明文http报文。 这是我思考了一段时间的解决方案，目前还没时间实践，不知可行不可行，等我实践过后再回来留个言。 另外一个方案是直接改anproxy，但是这对使用者的素质要求比较高。我没有选这个方案，原因是： 一、技术积累不够 二、不通用，之后有可能涉及到维护。目前的趋势是能够通过架构（方案一）解决的问题一般不用自己开发（我观察得到的观点）。 三、时间成本不一定比方案一少，万一改完不稳定或者不能用，那不完蛋了吗。 所以我会多花点时间折腾方案一，实在不行，再回过头来考虑其他方案。目测方案一没有可能会失败吧 (:-0

> > @myqqai 最近我也遇到了类似需求：requestBody和responseBody都是经过密钥加密的。 我的解决方案是，部署三套anyproxy, 比如A, B和C A负责把request解密，response加密；然后用端口转发工具（或其他方法）把request转发给B。用某种方式把B的request转发到C上。C负责把request加密，response解密。这样B的request和response都是明文。浏览器或者手机设置代理到A上。我们只需要访问B就可以看到所有的明文http报文。 这是我思考了一段时间的解决方案，目前还没时间实践，不知可行不可行，等我实践过后再回来留个言。 > > 另外一个方案是直接改anproxy，但是这对使用者的素质要求比较高。我没有选这个方案，原因是： 一、技术积累不够 二、不通用，之后有可能涉及到维护。目前的趋势是能够通过架构（方案一）解决的问题一般不用自己开发（我观察得到的观点）。 三、时间成本不一定比方案一少，万一改完不稳定或者不能用，那不完蛋了吗。 > > 所以我会多花点时间折腾方案一，实在不行，再回过头来考虑其他方案。目测方案一没有可能会失败吧 (:-0 > > 话说你解决了吗。 不好意思回的比较晚 Anyproxy有两年没更新了，应该是人散了没人维护了，而且之前用anyproxy遇到过一些问题，已经放弃，现在在用 https://github.com/mitmproxy/mitmproxy 之前用ABC那个方案折腾过程中遇到很多问题已经放弃了，现在用mitmproxy实现了一下方案二，已经完成了，代码写的不多，当然和你的加密方式有关，现在我们加密方式是对称加密，密钥是固定的很好处理，如果你们是非对称加密可能要多花些功夫 看了下你的需求，和我的差不多，都是只修改展示层面的，实际的请求流不动，这个可以实现，如果想要用anyproxy实现的话，应该也是可以的，anyproxy和mitmproxy整个架构应该是类似的，应该都有修改的地方