klzgrad/naiveproxy
GitHub: klzgrad/naiveproxy
利用 Chromium 网络栈进行流量伪装，具备高抗审查能力和低可检测性的代理工具。
Stars: 7766 | Forks: 953
# NaïveProxy 
NaïveProxy 使用 Chromium 的网络栈来伪装流量，具有强大的抗审查能力和低可检测性。复用 Chrome 的网络栈也确保了在性能和安全性方面的最佳实践。
通过使用 Chromium 的网络栈，缓解了以下流量攻击：
* 网站指纹识别 / 流量分类：通过 HTTP/2 中的流量多路复用[得到缓解](https://arxiv.org/abs/1707.00641)。
* [TLS 参数指纹识别](https://arxiv.org/abs/1607.01639)：通过复用 [Chrome 的网络栈](https://www.chromium.org/developers/design-documents/network-stack)来击败。
* [主动探测](https://ensa.fi/active-probing/)：通过*应用前置*（application fronting）来击败，即将代理服务器隐藏在具有应用层路由的常用前端服务器之后。
* 基于长度的流量分析：通过长度填充来缓解。
## 架构
[浏览器 → Naïve 客户端] ⟶ 审查者 ⟶ [前端 → Naïve 服务器] ⟶ 互联网
NaïveProxy 使用 Chromium 的网络栈来模仿常规 Chrome 浏览器与标准前端服务器之间的流量。
前端服务器可以是任何知名的反向代理，能够根据 HTTP 授权头路由 HTTP/2 流量，从而防止对代理存在的主动探测。已知的有带有 forwardproxy 插件的 Caddy 和 HAProxy。
这里的 Naïve 服务器充当转发代理和数据包长度填充层。Caddy forwardproxy 也是一个转发代理，但它缺少填充层。一个[分叉](https://github.com/klzgrad/forwardproxy)将 NaïveProxy 填充层添加到了 forwardproxy 中，将两者合二为一。
## 下载 NaïveProxy
在[此处](https://github.com/klzgrad/naiveproxy/releases/latest)下载。支持的平台包括：Windows、Android（通过 [Exclave](https://github.com/dyhkwong/Exclave)、[husi](https://github.com/xchacha20-poly1305/husi)、[NekoBox](https://github.com/MatsuriDayo/NekoBoxForAndroid)）、Linux、Mac OS 和 OpenWrt（[支持状态](https://github.com/klzgrad/naiveproxy/wiki/OpenWrt-Support)）。
用户应始终使用最新版本，以保持签名与 Chrome 一致。
从源代码构建：请参阅 [.github/workflows/build.yml](https://github.com/klzgrad/naiveproxy/blob/master/.github/workflows/build.yml)。
## 服务器设置
以下描述了 Caddy forwardproxy 的 naïve 分叉设置。
在[此处](https://github.com/klzgrad/forwardproxy/releases/latest)下载或从源代码构建：
```
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=github.com/klzgrad/forwardproxy@naive
```
示例 Caddyfile（相应地替换 `user` 和 `pass`）：
```
{
order forward_proxy before file_server
}
:443, example.com {
tls me@example.com
forward_proxy {
basic_auth user pass
hide_ip
hide_via
probe_resistance
}
file_server {
root /var/www/html
}
}
```
`:443` 必须出现在最前面，此 Caddyfile 才能工作。有关自定义 TLS 证书，请参阅 Caddyfile [文档](https://caddyserver.com/docs/caddyfile/directives/tls)。对于更高级的用法，请考虑使用 [JSON 作为 Caddy 2 的配置](https://caddyserver.com/docs/json/)。
使用 Caddyfile 运行：
```
sudo setcap cap_net_bind_service=+ep ./caddy
./caddy start
```
另请参阅 [Systemd 单元示例](https://github.com/klzgrad/naiveproxy/wiki/Run-Caddy-as-a-daemon)和 [HAProxy 设置](https://github.com/klzgrad/naiveproxy/wiki/HAProxy-Setup)。
## 客户端设置
使用以下 `config.json` 运行 `./naive`，以便在本地端口 1080 获取 SOCKS5 代理。
```
{
"listen": "socks://127.0.0.1:1080",
"proxy": "https://user:pass@example.com"
}
```
或者使用 `quic://user:pass@example.com`，如果效果更好的话。另请参阅[参数用法](https://github.com/klzgrad/naiveproxy/blob/master/USAGE.txt)和[性能调优](https://github.com/klzgrad/naiveproxy/wiki/Performance-Tuning)。
## 第三方集成
* [v2rayN](https://github.com/2dust/v2rayN)，GUI 客户端
## 下游注意事项
不要使用 master 分支来跟踪更新，因为每次 Chrome 新版本发布时，它都会从一个新的根提交进行变基。请使用稳定版本和关联的标签来跟踪新版本，其中也提供了简短的发行说明。
## 填充协议，非正式规范
此填充协议的设计选择了低开销和更易于实现，因为人们认为，可消耗的、临时性的规避协议设计的激增，对于审查研究来说，比复杂的设计是更好的后勤障碍。
### 代理负载填充
NaïveProxy 通过 HTTP/2（或 HTTP/3）CONNECT 隧道代理双向流。双向流按一系列数据读取和写入操作运行。建立流之后的单向流中前 `kFirstPaddings`（8）次读取和写入按以下格式填充：
```
struct PaddedData {
uint8_t original_data_size_high; // original_data_size / 256
uint8_t original_data_size_low; // original_data_size % 256
uint8_t padding_size;
uint8_t original_data[original_data_size];
uint8_t zeros[padding_size];
};
```
`padding_size` 是一个在 [0, `kMaxPaddingSize`]（`kMaxPaddingSize`：255）范围内均匀分布的随机整数。`original_data_size` 不能大于 65535，否则必须将其拆分为多次读取或写入。
选择 `kFirstPaddings` 为 8 是为了平滑由常见初始握手形成的包长分布尖峰：
- 常见客户端初始序列：1. TLS ClientHello；2. TLS ChangeCipherSpec, Finished；3. H2 Magic, SETTINGS, WINDOW_UPDATE；4. H2 HEADERS GET；5. H2 SETTINGS ACK。
- 常见服务器初始序列：1. TLS ServerHello, ChangeCipherSpec, ...；2. TLS Certificate, ...；3. H2 SETTINGS；4. H2 WINDOW_UPDATE；5. H2 SETTINGS ACK；6. H2 HEADERS 200 OK。
`kFirstPaddings` 之后的进一步读取和写入不进行填充，以避免性能开销。此外，后面的数据包长度通常被认为信息量较少。
### H2 RST_STREAM 帧填充
在实验中，NaïveProxy 倾向于在每个会话中发送过多的 RST_STREAM 帧，这是常规浏览器不常见的行为。为了解决这个问题，在 RST_STREAM 帧前 prepend 一个总长度分布在 [48, 72] 范围内的填充了 END_STREAM 的 DATA 帧，使其看起来像一个 HEADERS 帧。服务器对此通常会回复一个 WINDOW_UPDATE，因为填充被计入流量控制。这是否会导致新的不常见行为仍不清楚。
### H2 HEADERS 帧填充
CONNECT 请求和响应帧太短且太不常见。为了使其长度类似于真实的 HEADERS 帧，填充了一个 `padding` 头部，其中包含一串未经过 Huffman 编码且伪随机性足够强以避免被索引的符号。填充序列的长度随机分布在 [16, 32]（请求）或 [30, 62]（响应）之间。
### 填充协议的选择加入
NaïveProxy 客户端应能与任何不知道此填充协议的常规 HTTP/2 代理互操作。NaïveProxy 服务器（即任何能够处理此填充协议的代理服务器）应能与任何不知道此填充协议的常规 HTTP/2 客户端（例如常规浏览器）互操作。
NaïveProxy 服务器和客户端分别通过 CONNECT 请求和响应中是否存在 `padding` 头来确定对方是否能够支持此填充协议。只有当 `padding` 头存在时，才会启用填充协议。
发送到服务器的第一个 CONNECT 请求不能使用“Fast Open”在响应之前发送负载，因为尚未从第一个响应中确定服务器的填充能力，并且不知道是发送填充还是未填充的负载进行 Fast Open。
## 相对于 Chromium 上游的更改
- 最小化源代码和构建大小（为原始大小的 0.3%）
- 禁用异常和 RTTI，Mac 和 Android 除外。
- 支持 OpenWrt 构建
- (Android, Linux) 使用内置验证器而不是系统验证器（在 Linux 上移除对 NSS 的依赖），并从以下位置读取系统信任存储（遵循 Go 在 crypto/x509/root_unix.go 和 crypto/x509/root_linux.go 中的行为）：
- 环境变量 SSL_CERT_FILE 中的文件
- 以下第一个可用的文件
- /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Gentoo 等)
- /etc/pki/tls/certs/ca-bundle.crt (Fedora/RHEL 6)
- /etc/ssl/ca-bundle.pem (OpenSUSE)
- /etc/pki/tls/cacert.pem (OpenELEC)
- /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (CentOS/RHEL 7)
- /etc/ssl/cert.pem (Alpine Linux)
- 环境变量 SSL_CERT_DIR 目录中的文件
- 以下第一个可用的目录中的文件
- /etc/ssl/certs (SLES10/SLES11, https://golang.org/issue/12139)
- /etc/pki/tls/certs (Fedora/RHEL)
- /system/etc/security/cacerts (Android)
- 处理 PKCS#7 格式的 AIA 响应
- 允许代理具有更高的套接字限制
- 强制所有套接字通过隧道传输
- 使用 `fastopen` 头支持 HTTP/2 和 HTTP/3 CONNECT 隧道 Fast Open
- 填充 RST_STREAM 帧
## 已知的弱点
* HTTP CONNECT Fast Open 持续产生背靠背的 h2 数据包，这种情况不应如此频繁出现。这可以通过一点点 corking 来修复，但需要在 Chromium h2 栈深处进行精细的修改，这不太容易做到。
* TLS over TLS 比常见的 h2 请求需要更多的握手往返次数，也就是说，没有 h2 请求需要这么多次来回握手。除了进行 MITM 代理（破坏 E2E 加密）之外，没有简单的方法可以避免这种情况。
* TLS over TLS 开销导致可见的数据包长度增大和缺乏小数据包。移除此开销也需要 MITM 代理。
* TLS over TLS 开销还导致数据包持续超过 MTU 限制，这对于发起请求的用户代理来说是不应该发生的。修复此问题需要重新分段，而且这不容易做到。
* 数据包长度混淆部分依赖于 h2 多路复用，但如果只有一个连接，这就无法工作，这种情况并不罕见。目前尚不清楚如何有机地（即非硬编码）创建覆盖性的并发连接。
* 多路复用需要使用少量长寿命的隧道连接。目前尚不清楚多长时间适合模仿行为，如果存在年龄限制，如何令人信服地轮换连接，或者如何令人信服地检测和恢复卡住的隧道连接。
标签：Beacon Object File, Caddy, Chromium, GFW, Homebrew安装, HTTP/2, IP 地址批量处理, NaiveProxy, Radare2, SOCKS5, TLS指纹, 匿名上网, 反向代理, 安全合规, 应用前沿, 抗封锁, 日志审计, 流量伪装, 流量填充, 科学上网, 网络代理, 网络安全, 网络安全, 网络审查规避, 翻墙工具, 隐私保护, 隐私保护, 隐私安全