Security Documentation

1. Security Architecture Overview

CipherVPN's security architecture is built on the principle of defence in depth with data minimisation: each layer of the stack is hardened, but more importantly, the architecture limits how much sensitive data exists at each layer to begin with.

Architectural Zones

• Edge / Tunnel Zone — WireGuard VPN nodes; no persistent user data; connection-forwarding only; memory-only session state
• Application Zone — API servers, web frontend; minimal session data; protected by WAF, DDoS mitigation, rate limiting
• Data Zone — Encrypted databases; field-level encryption for PII; HSM-backed key management; no internet egress
• Management Zone — Air-gapped for most operations; bastion host access with hardware MFA; full audit logging; no persistent admin sessions

Zones communicate only through explicitly defined, authenticated, and encrypted channels. Lateral movement between zones is prevented by network segmentation and deny-by-default firewall policies.

2. Encryption Standards

Certificate Management

All CipherVPN TLS certificates are issued by Let's Encrypt (with DigiCert backup), have a maximum validity of 90 days, and are renewed automatically via ACME. Certificate Transparency monitoring alerts our team to any unexpected certificate issuance for CipherVPN domains within 24 hours.

3. VPN Security Model

WireGuard Architecture

CipherVPN is built on WireGuard, widely considered the most cryptographically sound VPN protocol available. Key security properties:

• Minimal attack surface — WireGuard's kernel implementation is ~4,000 lines of code vs. OpenVPN's ~70,000+ lines
• Forward secrecy — Ephemeral Diffie-Hellman keys ensure that compromise of long-term keys cannot decrypt past sessions
• Authenticated encryption — ChaCha20-Poly1305 provides both confidentiality and integrity; tampering is detectable and rejected
• Replay attack prevention — sliding window counters prevent replay of captured packets
• No fallback to weaker protocols — there is no protocol negotiation that could be downgraded

DNS Leak Prevention

DNS queries within the VPN tunnel are resolved by CipherVPN's own resolvers via the encrypted tunnel and are never sent to your ISP or any third party. The client applications enforce this at the OS level by:

• Binding the DNS resolver to the tunnel interface only
• Blocking all DNS traffic not destined for CipherVPN resolvers on all other interfaces
• Monitoring for DNS leaks and alerting the user if a leak is detected

Kill Switch

The CipherVPN kill switch blocks all non-VPN internet traffic if the tunnel drops unexpectedly, preventing exposure of your real IP address during reconnection. The kill switch is implemented using native OS firewall rules (iptables/nftables on Linux, WFP on Windows, PF on macOS) rather than application-layer blocking, making it robust against application crashes.

Multi-Hop Architecture

Multi-hop routing sends your traffic through two independently operated VPN nodes in different countries. Even if one node is compromised or its operator is compelled to log activity, the compromising party sees only traffic to/from the second hop — not your origin or destination. The two hops share no identity information about sessions.

4. CipherMail Security

End-to-End Encryption

For CipherVPN-to-CipherVPN messages (and PGP-encrypted mail to external recipients), encryption happens client-side before messages leave your device. The sequence is:

1. Your message is encrypted with the recipient's public key using XChaCha20-Poly1305
2. Your private key never leaves your device; it is encrypted with a key derived from your passphrase via Argon2id
3. CipherVPN servers receive and store only ciphertext; our staff cannot read your messages even with full database access
4. Messages are delivered over TLS 1.3 to prevent interception in transit

Zero-Knowledge Architecture

CipherVPN's mail architecture is designed so that the email subject, body, and attachments are all encrypted before transmission. Only the routing envelope (sender address, recipient address, timestamp) is visible to our systems for delivery — and even this metadata is encrypted at rest using AES-256-GCM with separately-managed keys.

External Mail Security

For email to/from external providers (e.g., Gmail, Hotmail), transport is secured with STARTTLS (MTA-STS enforced), DKIM signing, and SPF/DMARC records. Where the external provider does not support TLS, you are warned before sending.

5. Infrastructure Security

Bare-Metal VPN Nodes

All CipherVPN exit nodes run on dedicated bare-metal servers, not shared cloud instances. This eliminates hypervisor-level attack vectors and side-channel attacks that affect shared cloud tenants (e.g., RIDL, Fallout, MDS attacks). Node operators are contractually bound to prohibit traffic logging and to notify CipherVPN of any law enforcement contact within 24 hours.

Physical Security

Infrastructure is hosted in Tier III+ data centres with:

• 24/7 CCTV and on-site security
• Biometric access controls to server floors
• Locked cage within the data centre (our equipment is not co-mingled with other tenants)
• Full disk encryption on all drives (AES-256-XTS); encrypted drives are destroyed on decommission per NIST SP 800-88

Network Perimeter

• All ingress traffic is scrubbed by DDoS mitigation (multi-Tbps capacity, automatic BGP null-routing for volumetric attacks)
• Web Application Firewall (WAF) with OWASP CRS 4.0 rules, custom rules for CipherVPN-specific endpoints
• Rate limiting enforced at API and authentication layers
• Automated IP reputation blocking (Tor exit nodes, known malicious IPs) for admin endpoints

6. Access Controls

Zero-Trust for Internal Systems

CipherVPN operates on a zero-trust network model: there is no "trusted internal network". All access to internal systems requires:

• Authentication — hardware security key (FIDO2/WebAuthn) mandatory for all staff accessing production systems
• Authorisation — Role-Based Access Control (RBAC) with least-privilege principle; engineers have access only to their specific system scope
• Device posture — managed devices with disk encryption, MDM enrolment, and up-to-date OS required before production access is granted
• Session recording — all privileged sessions (SSH, database access, cloud console) are recorded and retained 90 days for incident investigation

Privileged Access Management

• No persistent privileged accounts — all elevated access is time-limited (max 8 hours) and requires approval workflow
• Database access is through a PAM broker; no developer has direct database credentials
• Production deployments are automated via CI/CD pipelines; manual production access is an exception requiring dual approval
• Third-party access (sub-processors, contractors) uses separate access paths, logged separately, and revoked within 24 hours of engagement end

Credential Security

• All secrets (API keys, database credentials, TLS private keys) are stored in HashiCorp Vault with audit logging and automatic rotation
• No secrets are stored in source code, configuration files, or environment variables in production
• Secret scanning is run on every git commit; any accidental exposure triggers immediate rotation and post-incident review

7. Audit Programme

Penetration test executive summaries are published in the year following each test on our Security Audit Reports page. Full reports are made available to enterprise customers under NDA.

8. Bug Bounty Programme

CipherVPN operates a private bug bounty programme. To submit a vulnerability report, email security@ciphervpn.eu with PGP encryption (key available at /pgp/security-key.asc).

Scope

The following targets are in-scope:

• ciphervpn.eu and all subdomains (excluding staging/non-production)
• CipherVPN client applications (Windows, macOS, Android, iOS)
• CipherMail web and native clients
• CipherVPN API (api.ciphervpn.eu)

Rules of Engagement

• Do not access, modify, or delete user data beyond your own test accounts
• Do not conduct DoS/DDoS attacks
• Do not perform social engineering against CipherVPN staff
• Do not disclose vulnerabilities publicly before we have had 90 days to remediate
• First reporter of a valid vulnerability will receive the bounty

9. Incident Response

Response Framework

CipherVPN's incident response follows a documented playbook aligned with NIST SP 800-61 Rev. 2:

1. Detection & Analysis — SIEM alerts, IDS/IPS notifications, vulnerability reports, or user reports trigger initial assessment
2. Containment — Affected systems are isolated; scope is determined; impacted accounts are identified
3. Eradication — Root cause is eliminated; patching or infrastructure rebuild as required
4. Recovery — Systems are restored to a verified clean state; monitoring is intensified
5. Post-Incident Review — Root cause analysis is conducted within 7 days; findings are applied to prevent recurrence

Breach Notification

In the event of a personal data breach:

• Supervisory authority notification (ICO for UK users) within 72 hours of CipherVPN becoming aware, as required by GDPR Article 33
• Individual user notification without undue delay where the breach is likely to result in high risk to individuals (GDPR Article 34)
• Public disclosure on this page when a breach has been resolved and user notification has been made — we will not hide incidents

10. Compliance & Certifications

Sub-Processor Security

All CipherVPN sub-processors (companies processing data on our behalf) are contractually required to:

• Maintain a security programme aligned with ISO 27001 or SOC 2 Type II
• Notify CipherVPN of any security incident within 24 hours
• Submit to CipherVPN's right-to-audit clause
• Process data only for purposes specifically described in the data processing agreement

A full list of sub-processors is maintained in our Privacy Policy, Section 7. Any changes to sub-processors are notified to users 30 days in advance where required by contract.