title: HTTP date: 2022-08-30 19:47:20 permalink: /tech/net/http/ article: false

HTTP

HTTP代理涉及了三个问题。

依次在原理部分解释月海是如何处理上述问题的

speed

最早接触云函数就是大佬们的文章：通过云函数进行动态IP池的代理。开启了大家探索云函数的历程。

其基本原理在于: 通过本地代理拦截 http请求进行解析，将分析出来的参数提供给云函数执行。

而云函数端仅提供一个类似request的方法，把获取到的参数重组HTTP请求，请求过后将数据返回而已。

在设计月海时，我对这种模式实在是难以苟同，太不优雅了，先不提各种编码可能导致的问题，光是要在本地开一个client端，就已经很难受了。

(月海最初的目标是实现本地端不需要任何工具，拿到一台机器，连接到云函数就能进行渗透工作)

但是经过一番折腾，发现截止至目前，云函数的支持力度仅能够存在这一种利用的方式。

问题就出在了HTTP的代理模式。

我们正常使用HTTP代理(浏览器插件、burp、bash终端的export HTTP_PROXY)等，实际上是将HTTP数据包原封不动的发给了我们配置的代理服务器。

实际上，等效于这种请求: curl -H "HOST: Dest-HOST" example.proxy.com

但是在云函数的实现都是通过API网关来寻找对应的FC，来确定触发器到底是由哪个函数执行。

而这就用到了这个HOST头字段，导致无法直接在云函数开启一个HTTP代理，用插件配置上使用。

"不要在已有的模式上造轮子"，因此，基于FC的特性，针对HTTP模式，就不再做更多思考与尝试了。

这里仍可以做的，就是优化HTTP请求的优雅程度，比如，通信方式，字段规范，以及编码问题的处理。

其实基于上面的架构。HTTPS 的问题已经很好解决了。

因为我们的云函数HTTP代理，并不是一个实际意义上的代理，而是一个模拟代理。云函数模拟的请求是可以发送https的。

那么问题就变成了，如何信任我们的client端，参照大多proxy和burp的模式，可以通过信任根路径的证书来解决这个问题。

可以参考这篇文章

HTTPS 迎刃而解。

待开发

月海测试beta版本，使用的方式是通过net.http 直接发送从header获取的完整路径请求。

这和现有的一些工具逻辑完全一致。但是在测试时，很容易出现：http redirect request 、 js/css加载失败或直接失效的场景，这相比socks5的舒适度差了一大截。

因此，基于完美主义，后续将会重构一版底层net转发的逻辑。