A secure transport protocol with Double Ratchet encryption, X3DH key agreement, and zero-surface management.
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.
The client uses BoringSSL to mimic a Chrome TLS 1.3 ClientHello fingerprint, helping it evade deep-packet inspection. 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() }
Each row maps a threat to the mechanism that mitigates it.
| Threat level | Adversary capability | rVPN mitigation |
|---|---|---|
| Passive observer | Traffic analysis, flow timing | 0–64 byte frame padding, constant-rate injection |
| Network analysis | Protocol fingerprinting | WebSocket over TLS 1.3, BoringSSL Chrome mimicry |
| Network restriction | Connection verification requests | Decoy website masking: HTTP 200 OK to unauthenticated probes |
| Compromised keys | Future key compromise | Post-compromise security via Double Ratchet |
| Quantum adversary | Store-now-decrypt-later attacks | Planned hybrid PQC mode: ML-KEM + X25519 (current release uses X25519/Ed25519) |
rVPN does not use static handshakes like OpenVPN or WireGuard. Its cryptographic state evolves throughout the session.
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.
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.
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.
The client includes a routing engine that decides which traffic enters the tunnel, which stays local, and which is blocked.
IP network tables resolve CIDR routes in logarithmic time for split-tunnel bypass and force-tunnel networks.
Hierarchy-aware matching for tunnel, bypass, and force-tunnel domain lists.
Fast exact and parent-domain lookups against compiled-in and user-supplied ad/tracker lists.
Zero DNS leaks, with near-zero initial connection latency.
The client loads compiled-in routing and block lists, plus optional user-supplied lists, into memory at startup. This keeps per-connection lookups fast.
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.
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 HTTP endpoints, no RPC interfaces, no admin sockets. Nothing to exploit at runtime.
All parameters defined at startup. Immutable at runtime, with no dynamic reconfiguration surface.