NaïveProxy uses Chromium's network stack to camouflage traffic with strong censorship resistence and low detectablility. Reusing Chrome's stack also ensures best practices in performance and security.
The following traffic attacks are mitigated by using Chromium's network stack:
[Browser → Naïve client] ⟶ Censor ⟶ [Frontend → Naïve server] ⟶ Internet
NaïveProxy uses Chromium's network stack to parrot traffic between regular Chrome browsers and standard frontend servers.
The frontend server can be any well-known reverse proxy that is able to route HTTP/2 traffic based on HTTP authorization headers, preventing active probing of proxy existence. Known ones include Caddy with its forwardproxy plugin and HAProxy.
The Naïve server here works as a forward proxy and a packet length padding layer. Caddy forwardproxy is also a forward proxy but it lacks a padding layer. A fork adds the NaïveProxy padding layer to forwardproxy, combining both in one.
Download here. Supported platforms include: Windows, Android (with Exclave, NekoBox), Linux, Mac OS, and OpenWrt (support status).
Users should always use the latest version to keep signatures identical to Chrome.
Build from source: Please see .github/workflows/build.yml.
The following describes the naïve fork of Caddy forwardproxy setup.
Download here or build from source:
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=github.com/klzgrad/forwardproxy@naive
Example Caddyfile (replace user
and pass
accordingly):
{
order forward_proxy before file_server
}
:443, example.com {
tls [email protected]
forward_proxy {
basic_auth user pass
hide_ip
hide_via
probe_resistance
}
file_server {
root /var/www/html
}
}
:443
must appear first for this Caddyfile to work. See Caddyfile docs for customizing TLS certificates. For more advanced usage consider using JSON for Caddy 2's config.
Run with the Caddyfile:
sudo setcap cap_net_bind_service=+ep ./caddy
./caddy start
See also Systemd unit example and HAProxy setup.
Run ./naive
with the following config.json
to get a SOCKS5 proxy at local port 1080.
{
"listen": "socks://127.0.0.1:1080",
"proxy": "https://user:[email protected]"
}
Or quic://user:[email protected]
, if it works better. See also parameter usage and performance tuning.
Do not use the master branch to track updates, as it rebases from a new root commit for every new Chrome release. Use stable releases and the associated tags to track new versions, where short release notes are also provided.
The design of this padding protocol opts for low overhead and easier implementation, in the belief that proliferation of expendable, improvised circumvention protocol designs is a better logistical impediment to censorship research than sophisicated designs.
NaïveProxy proxies bidirectional streams through HTTP/2 (or HTTP/3) CONNECT tunnels. The bidirectional streams operate in a sequence of reads and writes of data. The first kFirstPaddings
(8) reads and writes in a bidirectional stream after the stream is established are padded in this format:
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
is a random integer uniformally distributed in [0, kMaxPaddingSize
] (kMaxPaddingSize
: 255). original_data_size
cannot be greater than 65535, or it has to be split into several reads or writes.
kFirstPaddings
is chosen to be 8 to flatten the packet length distribution spikes formed from common initial handshakes:
Further reads and writes after kFirstPaddings
are unpadded to avoid performance overhead. Also later packet lengths are usually considered less informative.
In experiments, NaïveProxy tends to send too many RST_STREAM frames per session, an uncommon behavior from regular browsers. To solve this, an END_STREAM DATA frame padded with total length distributed in [48, 72] is prepended to the RST_STREAM frame so it looks like a HEADERS frame. The server often replies to this with a WINDOW_UPDATE because padding is accounted in flow control. Whether this results in a new uncommon behavior is still unclear.
The CONNECT request and response frames are too short and too uncommon. To make its length similar to realistic HEADERS frames, a padding
header is filled with a sequence of symbols that are not Huffman coded and are pseudo-random enough to avoid being indexed. The length of the padding sequence is randomly distributed in [16, 32] (request) or [30, 62] (response).
NaïveProxy clients should interoperate with any regular HTTP/2 proxies unaware of this padding protocol. NaïveProxy servers (i.e. any proxy server capable of the this padding protocol) should interoperate with any regular HTTP/2 clients (e.g. regular browsers) unaware of this padding protocol.
NaïveProxy servers and clients determines whether the counterpart is capable of this padding protocol by the presence of the padding
header in the CONNECT request and response respectively. The padding procotol is enabled only if the padding
header exists.
The first CONNECT request to a server cannot use "Fast Open" to send payload before response, because the server's padding capability has not been determined from the first response and it's unknown whether to send padded or unpadded payload for Fast Open.
fastopen
header