Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/klzgrad/naiveproxy/llms.txt

Use this file to discover all available pages before exploring further.

NaïveProxy is built on top of Chromium’s network stack, but it is not a full browser. To make it work as a lightweight, portable proxy while preserving Chrome-identical TLS and traffic signatures, the project applies a carefully scoped set of patches to the upstream Chromium source. This page documents every change made from Chromium upstream and explains why each one exists.
The current Chromium base version is 150.0.7871.63. NaïveProxy tracks the stable Chrome release train closely so that its TLS fingerprints remain identical to those produced by real Chrome browsers in the wild. You can monitor upcoming Chrome release milestones at chromiumdash.appspot.com/schedule to anticipate when the next NaïveProxy update will be needed.

Why Chromium patches are necessary

NaïveProxy re-uses Chromium’s network stack — not a reimplementation of it — to achieve cryptographically indistinguishable TLS handshakes. However, shipping a full browser build would be enormous and impractical for a proxy tool. The patches below reduce the build to approximately 0.3% of the original Chromium codebase while adding the proxy-specific behaviours that make NaïveProxy work.

Full list of changes

1. Minimized source and build size

The Chromium source tree is stripped down to only the components required for networking. The resulting binary is roughly 0.3% of the original Chromium codebase, making it practical to distribute and deploy on constrained hardware such as home routers.

2. Disabled exceptions and RTTI

C++ exceptions and Run-Time Type Information (RTTI) are disabled across the build to reduce binary size and improve performance. The only platforms that retain exceptions and RTTI are macOS and Android, where platform APIs or third-party dependencies require them.

3. OpenWrt build support

Cross-compilation support has been added so that NaïveProxy can be built for OpenWrt targets — embedded Linux distributions commonly found on home routers and other low-power networking devices. This allows NaïveProxy to run directly on the gateway device, transparently proxying all traffic on a local network.

4. Custom certificate verification (Android and Linux)

On Android and Linux, NaïveProxy replaces Chromium’s default system certificate verifier with the builtin verifier. This eliminates the dependency on NSS (Network Security Services) on Linux while retaining correct trust chain validation. The builtin verifier reads the system trust store by following the same discovery order used by Go’s crypto/x509 package (root_unix.go / root_linux.go):
From environment variable:
  • SSL_CERT_FILE — path to a single CA bundle file
First available file from the following paths:
PathDistribution
/etc/ssl/certs/ca-certificates.crtDebian, Ubuntu, Gentoo
/etc/pki/tls/certs/ca-bundle.crtFedora, RHEL 6
/etc/ssl/ca-bundle.pemOpenSUSE
/etc/pki/tls/cacert.pemOpenELEC
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pemCentOS, RHEL 7
/etc/ssl/cert.pemAlpine Linux
From environment variable:
  • SSL_CERT_DIR — path to a directory of CA certificate files
First available directory from the following paths:
PathDistribution
/etc/ssl/certsSLES10, SLES11
/etc/pki/tls/certsFedora, RHEL
/system/etc/security/cacertsAndroid

5. PKCS#7 AIA response handling

Chromium’s upstream network stack does not handle Authority Information Access (AIA) responses delivered in PKCS#7 format. NaïveProxy adds support for parsing these responses so that certificate chains can be completed correctly when intermediate certificates are fetched via AIA during TLS handshakes.

6. Higher socket limits for proxies

Chrome’s default per-host and global socket pool limits are sized for ordinary browser usage. As a proxy, NaïveProxy must multiplex many concurrent upstream connections on behalf of downstream clients. This patch raises those socket limits to values appropriate for proxy workloads.

7. Force tunneling for all sockets

All outgoing connections are forced through the HTTP/2 or HTTP/3 CONNECT tunnel, regardless of what the higher-level code requests. This ensures that every byte of user traffic is encapsulated inside the authenticated, padded tunnel rather than being sent as plain HTTP requests that could leak information.

8. HTTP/2 and HTTP/3 CONNECT tunnel Fast Open

NaïveProxy adds a fastopen header mechanism that allows payload data to be sent in the same round trip as the CONNECT request, reducing connection latency. This is analogous to TCP Fast Open but operates at the HTTP/2 and HTTP/3 CONNECT tunnel layer.
The first CONNECT request to a server cannot use Fast Open. Because it is the first exchange, the client does not yet know whether the server supports the NaïveProxy padding protocol, so it must wait for the server’s response before sending padded or unpadded payload.

9. RST_STREAM frame padding

In practice, NaïveProxy sessions generate more RST_STREAM frames than a typical Chrome browser session — an anomaly that could be used as a traffic fingerprint. To mask this, an END_STREAM DATA frame is prepended to each RST_STREAM frame. The combined length of the prepended frame is randomly distributed in the range [48, 72] bytes, making it resemble a HEADERS frame to passive observers.
The server often replies to the padded END_STREAM DATA frame with a WINDOW_UPDATE frame, because HTTP/2 flow control accounts for padding bytes. Whether this server response introduces a new detectable pattern is an open research question noted in the project.

Summary table

ChangeScopePurpose
Minimized source and build sizeBuildReduce binary to ~0.3% of Chromium
Disabled exceptions and RTTIBuildSmaller binaries; macOS/Android excepted
OpenWrt build supportBuildCross-compile for embedded Linux/routers
Custom certificate verificationAndroid, LinuxRemove NSS dependency; read system trust store
PKCS#7 AIA response handlingAll platformsCorrect certificate chain completion
Higher socket limitsAll platformsSupport high-concurrency proxy workloads
Force tunneling for all socketsAll platformsGuarantee all traffic goes through CONNECT
HTTP/2 and HTTP/3 Fast OpenAll platformsReduce latency via fastopen header
RST_STREAM frame paddingAll platformsMask anomalous RST_STREAM frequency

Build docs developers (and LLMs) love