HTTP
# HTTP
HTTP代理 涉及了三个问题。
- HOST 路由问题
- HTTPS 请求认证问题
- 链式代理
- 底层转发http.client.do()问题
依次在原理部分解释月海是如何处理上述问题的
# 效果
# 原理
# HOST 路由问题
最早接触云函数就是大佬们的文章：通过云函数进行动态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 请求认证问题
其实基于上面的架构。HTTPS 的问题已经很好解决了。
因为我们的 云函数HTTP代理，并不是一个实际意义上的代理，而是一个模拟代理。 云函数模拟的请求是可以发送https的。
那么问题就变成了，如何信任我们的client端，参照大多proxy和burp的模式，可以通过信任根路径的证书来解决这个问题。
可以参考这篇文章
实现基于 HTTPS 代理的中间人攻击 (opens new window)
HTTPS 迎刃而解。
# 链式代理
待开发
# 底层逻辑问题
月海测试beta版本，使用的方式是通过net.http 直接发送从header获取的完整路径请求。
这和现有的一些工具逻辑完全一致。 但是在测试时，很容易出现：http redirect request 、 js/css加载失败或直接失效的场景，这相比socks5的舒适度差了一大截。
因此，基于完美主义，后续将会重构一版底层net转发的逻辑。