Technical whitepaper

A transport that hides in plain sight.

rVPN runs over WebSocket/TLS on port 443, the same port and protocol as ordinary HTTPS. To network observers, the tunnel looks like normal web browsing.

It replaces static key exchanges with the Double Ratchet Algorithm, giving forward secrecy and post-compromise security. All traffic multiplexes through a small set of WebSocket connections on port 443.

Desktop, CLI, and Android clients use BoringSSL to mimic a Chrome TLS 1.3 ClientHello fingerprint, helping evade deep-packet inspection. iOS clients use pure-Rust rustls; Apple's Network Extension sandbox constrains BoringSSL's memory model, so iOS trades fingerprint mimicry for stability. The server also uses rustls for inbound WebSocket connections, and obtains and renews its own Let’s Encrypt certificate via ACME TLS-ALPN-01 on the same :443 listener, with no external tooling or renewal timers.

// TLS 1.3 Chrome fingerprint
fn build_chrome_connector() {
    let mut builder = SslConnector::builder();
    builder.set_min_proto_version(TLS1_3);
    builder.set_cipher_list(
        "TLS_AES_128_GCM_SHA256:
         TLS_AES_256_GCM_SHA384:
         TLS_CHACHA20_POLY1305"
    );
    builder.set_alpn_protos(b"\x08http/1.1");
    builder.build()
}

A small, stable connection shape.

Since v1.3.5 the CLI and desktop clients multiplex all proxy flows over a pool of long-lived WebSocket/TLS connections instead of opening a new connection per flow. Mobile direct-TUN mode has always multiplexed over a single connection; pooling brings the same property to SOCKS5/HTTP mode without giving up parallelism.

What rVPN defends against.

Each row maps a threat to the mechanism that mitigates it.

A dynamic, self-healing cryptographic state.

rVPN does not use static handshakes like OpenVPN or WireGuard. Its cryptographic state evolves throughout the session.

An advanced routing engine, built in.

The client includes a routing engine that decides which traffic enters the tunnel, which stays local, and which is blocked.

Multi-server routing

A profile can carry additional exit servers, each with its own route domains (suffix-matched: google.com covers *.google.com) and route IPs/CIDRs. Matched traffic egresses through that exit and never silently falls back to the default server. On mobile, the resolver runs inside the tunnel extension itself: each exit resolves names through its own DNS-over-HTTPS channel, and every answer is recorded in a shared route map with the answer’s TTL, so follow-up connections to those IPs take the same exit automatically. Exits connect lazily on first use and reconnect independently, each with its own TOFU identity pin.

Fast rule loading at startup.

The client loads compiled-in routing and block lists, plus optional user-supplied lists, into memory at startup. This keeps per-connection lookups fast.

How it works

Domains are matched in HashSet collections, with parent-domain checks. IP ranges are stored in a longest-prefix-match table. Everything loads into memory at startup; zero-copy serialization and delta updates are planned for very large enterprise rule sets.

No management interface to exploit.

Exposing HTTP/REST management APIs, RPC interfaces, or admin sockets creates attack surface for credential theft, privilege escalation, and zero-day exploits.

rVPN has no management interface. All parameters, routing rules, and key mappings are set in static TOML files read at startup. No admin APIs, dashboards, or control sockets exist, so an adversary cannot alter runtime state.