Threat Model¶
Understanding what R-VPN protects against and its security goals.
Security Goals¶
R-VPN is designed to provide the following security properties:
1. Confidentiality¶
All application data is encrypted using AEAD (Authenticated Encryption with Associated Data) ciphers. Traffic content is inaccessible to any third party, including network observers, ISPs, and intermediate infrastructure.
2. Forward Secrecy¶
Past sessions remain secure even if long-term keys are compromised in the future. This is achieved through ephemeral key exchanges that generate session-specific keys which are never stored.
3. Post-Compromise Security¶
Future sessions can recover from key compromise through the Double Ratchet Algorithm. Even if current session keys are exposed, the protocol "self-heals" over time, limiting the window of vulnerability.
4. Undetectability¶
Traffic is designed to be indistinguishable from legitimate HTTPS/WebSocket traffic. This prevents traffic classification systems from identifying and blocking R-VPN connections.
5. Plausible Deniability¶
The server presents legitimate website content to unauthenticated clients. To external observers, the server appears as a normal web service, providing deniability for VPN operation.
Adversary Capabilities¶
Passive Observer¶
Capabilities: - Traffic analysis and flow monitoring - Timing pattern observation - Volume monitoring and statistics collection - Connection duration tracking
Mitigation: - Traffic padding to mask payload sizes - Constant-rate transmission mode - TLS 1.3 encryption with standard cipher suites - WebSocket framing mimics normal web traffic
Active Attacker¶
Capabilities: - Packet injection and modification - Replay attacks - Man-in-the-middle attacks - Connection disruption
Mitigation: - Double Ratchet sequence numbers prevent replay - AEAD authentication tags detect tampering - X3DH key agreement provides authentication - Perfect forward secrecy limits exposure
DPI Systems (Deep Packet Inspection)¶
Capabilities: - Protocol fingerprinting - Traffic classification - Statistical analysis of packet patterns - TLS fingerprinting
Mitigation: - WebSocket over TLS 1.3 (standard web technology) - Browser-grade traffic mimicry - Random padding to prevent size-based fingerprinting - Standard TLS handshake without custom extensions
Censorship Systems¶
Capabilities: - Active probing of suspected VPN servers - Domain and IP address blocking - Traffic throttling based on classification - Certificate pinning enforcement
Mitigation: - Domain fronting capability (planned) - CDN integration for IP diversity (planned) - Website masking (decoy) for unauthenticated requests - No distinguishable protocol signatures
Compromised Keys¶
Capabilities: - Store-now-decrypt-later attacks - Session decryption with stolen keys - Impersonation if identity keys are stolen
Mitigation: - Post-compromise security via Double Ratchet - Forward secrecy from symmetric ratchet - Regular key rotation (signed prekeys rotated ~weekly) - One-time prekeys for ephemeral sessions
Quantum Adversary¶
Capabilities: - Store-now-decrypt-later with quantum computing - Breaking traditional asymmetric cryptography
Mitigation: - Hybrid PQC mode available (ML-KEM + X25519) - Post-quantum key encapsulation mechanism - Future-proof cryptographic design
What R-VPN Protects¶
Content Protection¶
- All application-layer data is encrypted end-to-end
- Payload content is inaccessible to network observers
- DNS queries are tunneled through the encrypted connection
- No cleartext data exposure on the wire
Metadata Protection¶
- Connection timing patterns are masked through padding
- Traffic volume is obfuscated via constant-rate mode
- Protocol headers are encrypted
- No distinguishable packet size patterns
Destination Protection¶
- Final destination is hidden from network observers
- Traffic appears to go to the VPN server only
- No DNS leaks revealing true destinations
- All traffic multiplexed through single WebSocket connection
Identity Protection¶
- Client identity is authenticated but not exposed
- No persistent identifiers in protocol messages
- Ed25519 identity keys provide cryptographic authentication
- No correlation possible between sessions without key compromise
What R-VPN Does NOT Protect¶
Network Activity Patterns¶
While content is encrypted, some metadata may still leak: - Connection establishment times - Overall connection duration - Approximate traffic volume (without constant-rate mode) - Presence of network activity (that a connection exists)
Compromised Endpoints¶
If either client or server device is compromised: - All traffic from that device is visible to the attacker - Current session keys can be extracted - Future sessions may be compromised until remediation
Traffic Volume Analysis¶
Without constant-rate mode enabled: - Sustained high-throughput connections may be detectable - Traffic spikes can reveal usage patterns - Upload/download ratios may be analyzed
Global Adversary¶
Very well-resourced adversaries with global visibility may: - Correlate traffic entering and leaving the VPN - Perform timing analysis across the network - Deploy targeted active attacks
Application-Layer Leaks¶
R-VPN cannot protect against: - Browser fingerprinting - Application-level metadata leaks - User behavior patterns - Credentials entered on malicious sites
Attack Surface¶
Server¶
Components: - TLS termination point (TLS 1.3) - Decoy website serving legitimate content - VPN protocol processing layer - WebSocket connection handler
Risks: - Server compromise reveals current session keys - Memory dumps may expose ephemeral keys - Side-channel attacks on cryptographic operations
Mitigations: - Double Ratchet limits exposure window - Minimal logging (no traffic logs) - Memory-safe Rust implementation - Regular security updates
Client¶
Components: - Device security and OS protections - Key storage (memory and disk) - Local SOCKS5 proxy - Browser/extension integration
Risks: - Client compromise reveals current and future sessions - Key extraction from memory - Malware intercepting traffic before encryption
Mitigations: - Hardware-backed key storage (planned) - Regular key rotation - Minimal privilege operation - Secure memory handling in Rust
Network¶
Components: - Path between client and server - Intermediate routers and proxies - DNS infrastructure
Risks: - Traffic interception - Man-in-the-middle attacks - DNS poisoning
Mitigations: - TLS 1.3 with certificate validation - Forward secrecy for all sessions - DNS over HTTPS (DoH) integration - Certificate pinning option
Management Interface¶
Design Principle: Zero Exposed Management
Implementation: - No administrative API exposed to public internet - Local CLI for server administration - VPN-tunneled management access only - Configuration via local files
Risks Mitigated: - API exploitation - Credential theft via network - Unauthorized administrative access
Security Properties Summary¶
| Property | Guarantee | Mechanism |
|---|---|---|
| Forward Secrecy | Compromising current keys doesn't reveal past sessions | Ephemeral key exchange, symmetric ratchet |
| Post-Compromise Security | Future sessions secure even if current keys compromised | Double Ratchet DH ratchet |
| Authentication | Server identity verified | Ed25519 signed prekeys |
| Confidentiality | All data encrypted | ChaCha20-Poly1305 AEAD |
| Integrity | Tampering detected | Poly1305 authentication tags |
| Undetectability | Traffic appears as HTTPS | WebSocket over TLS 1.3 |
| Deniability | No persistent verifiable state | Ephemeral session keys |
Limitations and Considerations¶
Traffic Analysis¶
Even with encryption, sophisticated traffic analysis may distinguish VPN traffic by: - Timing patterns of packet transmission - Volume patterns and burst characteristics - Connection behavior and duration - WebSocket frame patterns
Recommendation: Enable constant-rate mode for maximum stealth in high-threat environments.
Key Compromise Scenarios¶
If identity keys are compromised: - Past sessions: Protected by forward secrecy (cannot be decrypted) - Current session: Vulnerable until next DH ratchet step - Future sessions: Protected if new identity keys are generated
Recommendation: Rotate keys regularly and regenerate identity keys if compromise is suspected.
Endpoint Compromise¶
If a device is compromised by malware or physical access: - All traffic from that device is visible to the attacker - Future VPN connections from that device are compromiseable - Keys may be extracted from memory
Recommendation: Use hardware security modules where available, keep systems updated, and use endpoint security tools.
Quantum Computing Threat¶
While current sessions are protected, long-term storage of encrypted traffic may pose risks: - Current X25519 key exchange is vulnerable to quantum attacks - Hybrid PQC mode provides protection but is not default
Recommendation: Enable hybrid PQC mode for sensitive long-term communications.
Comparison with Alternatives¶
| Property | R-VPN | Traditional VPN | Tor |
|---|---|---|---|
| Forward Secrecy | Yes | Sometimes | Yes |
| Post-Compromise Security | Yes | No | No |
| Undetectability | High | Low | Medium |
| Speed | High | High | Low |
| Latency | Low | Low | High |
| Complexity | Medium | Low | High |
| Single Hop | Yes | Yes | No (3+ hops) |
| Exit Node Trust | Not required | Required | Required |
| Website Masking | Yes | No | No |
R-VPN vs Traditional VPN¶
Advantages: - Better resistance to traffic classification - Post-compromise security through ratcheting - Plausible deniability via website masking - No VPN protocol signatures
Trade-offs: - More complex setup - Newer codebase (less battle-tested)
R-VPN vs Tor¶
Advantages: - Significantly higher performance - Lower latency - Single-hop design (no exit node trust issues) - Better suited for high-bandwidth applications
Trade-offs: - Single point of trust (the server) - Less anonymity against global adversaries - No built-in circuit rotation
Best Practices¶
For Users¶
- Use the latest version - Security improvements are released regularly
- Rotate keys regularly - Regular key rotation limits exposure window
- Verify server keys - Always verify server public keys on first use
- Enable authentication - Use authentication on SOCKS5 proxy
- Enable constant-rate mode - For maximum stealth in restrictive environments
- Monitor for anomalies - Watch for unexpected connection behavior
For Operators¶
- Keep server software updated - Apply security patches promptly
- Use strong TLS configuration - Modern TLS 1.3 only, strong cipher suites
- Implement proper decoy content - Convincing website masking
- Monitor server logs - Watch for probing and attack attempts
- Regular key rotation - Automated signed prekey rotation
- Secure key storage - Protect identity keys with appropriate measures
Reporting Security Issues¶
If you discover a security vulnerability in R-VPN:
Do¶
- Do not disclose publicly until a fix is available
- Contact the development team privately
- Provide a detailed report including:
- Description of the vulnerability
- Steps to reproduce
- Potential impact assessment
- Suggested mitigation (if any)
- Allow reasonable time for remediation
- Coordinate disclosure timeline with the team
Do Not¶
- Do not exploit the vulnerability beyond minimal verification
- Do not access others' data or systems
- Do not publicly disclose before a fix is released
- Do not demand compensation as a condition of disclosure
Contact¶
Security issues should be reported to the project maintainers through secure channels. Please check the project repository for current contact information.
Changelog¶
| Version | Changes |
|---|---|
| v0.1.0 | Initial release with X3DH + Double Ratchet |
| v0.2.0 | Added hybrid PQC mode (ML-KEM + X25519) |
| Future | Enhanced traffic shaping, hardware key support |