reqable / reqable-app

Reqable issue track repo

Home Page:https://reqable.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[feature] 即使 SSL 代理绕行依旧要通过网关过滤请求

cxplay opened this issue · comments

当前版本一旦在 SSL 代理中开启了绕过 HTTPS 流量, 将会使网关中的规则全部失效. 有时只是用 Reqable 作为一个代理服务器简单查看应用中的 HTTP 流量情况, 并不需要进行 HTTPS 解密.

网关功能应该作为流量通过 Reqable 的最后一道「网关」, 不论 SSL 代理是否开启, 应该始终能够使用这个功能对流经 Reqable 的流量进行过滤.

image

@cxplay 网关只对解密后的流量生效,SSL Bypass了就不会经过网关,所以SSL代理里面提供了不显示绕行流量的开关选项。

@cxplay 网关只对解密后的流量生效,SSL Bypass了就不会经过网关,所以SSL代理里面提供了不显示绕行流量的开关选项。

所以我建议 Reqable 的网关能够处理所有 HTTP(s) 流量, HTTP 调试范围并不应该局限于「必须能够 HTTPS 解密」的前置条件. 我现在要处理这种不解密的流量只能在给 Reqable 再套上一个另一个具有防火墙功能的软件, 但很显然这本来应该是 Reqable「网关」这个功能就能做到的事情.

所以我建议 Reqable 的网关能够处理所有 HTTP(s) 流量, HTTP 调试范围并不应该局限于「必须能够 HTTPS 解密」的前置条件. 我现在要处理这种不解密的流量只能在给 Reqable 再套上一个另一个具有防火墙功能的软件, 但很显然这本来应该是 Reqable「网关」这个功能就能做到的事情.

准确来讲呢,这个网关指的是API Gateway,而不是Traffic Gateway或者Firewall Gateway。API Gateway有很多个行为模式,属于应用层,比如屏蔽请求,屏蔽响应,这些都是给API设计的。而SSL Proxy这个是会话层行为,如果SSL Bypass了,就跳过了应用层的行为模式。

准确来讲呢,这个网关指的是API Gateway,而不是Traffic Gateway或者Firewall Gateway。API Gateway有很多个行为模式,属于应用层,比如屏蔽请求,屏蔽响应,这些都是给API设计的。而SSL Proxy这个是会话层行为,如果SSL Bypass了,就跳过了应用层的行为模式。

了解了, 所以 Reqable 有没有可能设计一个 "Traffic Gateway" 组件的打算来实现过滤 SSL Proxy 之后的流量呢? 目前确实有这个需求, 并且没有很好的已有的专门用于 HTTP 调试用的多端产品, 现在我在用的替代办法也没办法保持多端的一致性.

可以参考一下直接竞品, 比如 Proxyman 也同样有 SSL Proxying 以及「网关」(Black List & Allow List).

https://docs.proxyman.io/basic-features/ssl-proxying

即使 SSL 根证书安装完成可以进行解密也能可选地对请求单独的启用和禁用解密, 并且不会影响 Black List 和 Allow List 的拦截和放行(Allow List 的优先级大于 Black List).

已在 SSL Proxying 排除全部请求 已在 Black List 禁止特定域名
image image

这种规则组合的结果是: HTTPS 解密全部禁用, 特定域名依旧能被阻止.
image


希望 Reqable 也能做到这种组合的效果.

扩充下网关规则也可以实现Allow List和Block List,在SSL Proxying前面拦截一道。