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 one WebSocket connection 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 there. The server uses rustls for inbound WebSocket connections.
// 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() }
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.
3.1. X3DH key agreement
Initial handshakes use Extended Triple Diffie-Hellman. The client retrieves the server's signed prekey, computes four DH shared secrets, and derives the root key via HKDF-SHA256.
3.2. Double Ratchet
After the handshake, the Double Ratchet Algorithm governs the connection. The symmetric ratchet evolves chain keys per message for forward secrecy, while the DH ratchet rotates asymmetric keys for post-compromise security.
3.3. Out-of-order handling
TCP streams can deliver messages out of order. The Double Ratchet state stores skipped message keys so that late or reordered frames can be decrypted without advancing the chain, keeping the connection intact without a separate reorder buffer.
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.
IP CIDR lookup
IP network tables resolve CIDR routes in logarithmic time for split-tunnel bypass and force-tunnel networks.
Domain rules
Hierarchy-aware matching for tunnel, bypass, and force-tunnel domain lists.
Ad & tracker lists
Fast exact and parent-domain lookups against compiled-in and user-supplied ad/tracker lists.
Deferred DNS
Zero DNS leaks, with near-zero initial connection latency.
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.
No management API
No HTTP endpoints, no RPC interfaces, no admin sockets. Nothing to exploit at runtime.
Static config (TOML)
All parameters defined at startup. Immutable at runtime, with no dynamic reconfiguration surface.