Make a fortune quietly
Go to file
2019-03-23 16:56:08 +08:00
src Fix option parsing 2019-03-23 16:56:08 +08:00
tests Add tests 2019-03-23 16:56:08 +08:00
tools Add source import tool 2019-03-23 16:56:08 +08:00
.appveyor.yml Add documentation 2019-03-23 16:56:08 +08:00
.gitignore Add .gitignore 2019-03-23 16:56:08 +08:00
.travis.yml Add documentation 2019-03-23 16:56:08 +08:00
CHROMIUM_VERSION Add source import tool 2019-03-23 16:56:08 +08:00
LICENSE Add LICENSE 2019-03-23 16:56:08 +08:00
README.md Update README.md 2019-03-23 16:56:08 +08:00
USAGE.txt Add documentation 2019-03-23 16:56:08 +08:00

NaiveProxy Build Status Build status

A secure, censorship-resistent proxy.

NaiveProxy resists censorship by obfuscating as common HTTP/2 traffic with minimal distinguishable features. Privacy and integrity are simultaneously achieved through implementations of TLS best practices.

The following attacks are mitigated:

  • Website fingerprinting / traffic classification: mitigated by traffic multiplexing in HTTP/2.
  • TLS parameter fingerprinting: defeated by using identical behaviors from Chromium's network stack.
  • Active probing: defeated by application fronting, i.e. hiding proxy servers behind a commonly used frontend with application-layer routing.
  • Length-based traffic analysis: mitigated by length padding.

Architecture

[Browser → Naive (client)] ⟶ Censor ⟶ [Frontend → Naive (server)] ⟶ Internet

NaiveProxy uses Chromium's network stack. What the censor can see is exactly regular HTTP/2 traffic between Chrome and Frontend (e.g. HAProxy), two of the most commonly used browsers and servers. Being as common as possible reduces the viability of traffic classification censorship.

Frontend also reroutes unauthenticated users and active probes to a backend HTTP server, making it impossible to detect the existence of a proxy:

Probe ⟶ [Frontend → Nginx] ⟶ index.html

Download

See latest release.

Note: On Linux libnss3 must be installed before using the prebuilt binary.

Build

If you don't like to use downloaded binaries, you can build it.

Prerequisites:

  • Ubuntu (apt-get install): git, python2, ninja-build (>= 1.7), pkg-config, libnss3-dev, ccache (optional)
  • MacOS (brew install): git, ninja, ccache (optional)
  • Windows (choco install): git, python2, ninja, visualstudio2017community. See Chromium's page for detail on Visual Studio setup requirements.

Build it:

git clone https://github.com/klzgrad/naiveproxy.git
cd naiveproxy/src
./get-clang.sh
./build.sh

The build scripts download tools from Google servers with curl. If there is trouble try to set a proxy environment variable for curl, e.g. export ALL_PROXY=socks5h://127.0.0.1:1080.

Verify:

./out/Release/naive --log &
curl -v --proxy socks5h://127.0.0.1:1080 google.com

Setup

The naive binary functions as both the client and the server. Naive client can be run as ./naive --proxy=https://user:pass@domain.example, which accepts SOCKS5 traffic at port 1080 and proxies it via domain.example as HTTP/2 traffic. Naive server can be run as ./naive --listen=http://127.0.0.1:8080 behind the frontend as a regular HTTP proxy. You can also store the parameters in config.json and ./naive will detect it automatically.

For details on setting up the server part [Frontend → Naive (server)], see Server Setup.

For more information on parameter usage, see USAGE.txt. See also Parameter Tuning to improve client-side performance.

Portable setup

Browser ⟶ [HAProxy → Tinyproxy] ⟶ Internet

This mode is clientless: point your browser directly to the server as an HTTPS proxy. You don't need to download, build, or run anything client-side.

But this setup is prone to traffic analysis due to lack of obfuscation. Also, the browser will introduce an extra 1RTT delay during connection setup.

Tinyproxy is used in place of Naive server in this mode, so you only need to apt-get install tinyproxy without downloading anything manually.

FAQ

Why not use Go, Node, etc.?

Their TLS stacks have distinct features that can be easily detected and generally TLS parameters are very distinguishable.

Previously, Tor tried to mimic Firefox's TLS signature and still got identified and blocked by firewalls, because that signature was of an outdated version of Firefox and the firewall determined the rate of collateral damage would be acceptable. It would be unacceptable to block the most commonly used browsers.