Security Overview
Your traffic stays private even when it passes through transit nodes you don't control. Only the ingress and exit see your data - everything in between sees encrypted bytes they cannot decrypt.
What this means for you:
- Compromise a transit node? They see nothing useful
- Network tapped between agents? Traffic is encrypted
- Unauthorized client tries to connect? Rejected by authentication
Security Model
End-to-End Encryption
Transit nodes relay your traffic without being able to read it:
- Your data is encrypted before leaving the ingress
- Only the exit node can decrypt it
- Even if a transit is compromised, your data stays private
See End-to-End Encryption for details.
Transport Security
All peer connections use TLS 1.3:
- Encryption: All traffic encrypted in transit
- Authentication: Server certificates validated
- Mutual TLS: Optional client certificate authentication
- Perfect Forward Secrecy: Session keys derived per connection
Authentication Layers
| Layer | Mechanism | Purpose |
|---|---|---|
| E2E | X25519 + ChaCha20-Poly1305 | Stream data encryption |
| TLS | Certificates | Peer authentication |
| mTLS | Client certs | Mutual authentication |
| SOCKS5 | Username/password | Client authentication |
| Shell | bcrypt password | Command authorization |
| File Transfer | bcrypt password | Transfer authorization |
| Sleep/Wake | Ed25519 signatures | Command authentication |
Authorization
- Route-based ACL: Exit only allows configured CIDRs
- Shell whitelist: Only whitelisted commands allowed
- File path restrictions: Only allowed paths accessible
What You're Protected Against
| If This Happens... | You're Protected Because... |
|---|---|
| Someone captures traffic between agents | It's encrypted - they see random bytes |
| Transit node is compromised | E2E encryption - transit can't decrypt your data |
| Someone replays captured traffic | Nonce-based encryption detects replays |
| Someone modifies traffic in transit | Authenticated encryption detects tampering |
| Unauthorized peer tries to connect | mTLS rejects unknown certificates |
| Unauthorized client tries to use proxy | SOCKS5 authentication blocks them |
| Someone tries to run unauthorized commands | Shell whitelist blocks unapproved commands |
| Someone tries to hibernate your mesh | Signing keys verify sleep/wake commands |
What You Need to Protect Yourself
| Risk | Your Responsibility |
|---|---|
| CA private key stolen | Store it securely (HSM, vault, encrypted disk) |
| Ingress or exit host compromised | Harden your endpoints - they see your data |
| Traffic pattern analysis | Disable protocol identifiers, use standard ports. See Traffic Patterns |
| Insider with valid credentials | Monitor logs, rotate credentials |
Security Checklist
Minimum Security
- TLS certificates generated and deployed
- Certificate CA key secured
- SOCKS5 bound to localhost or authenticated
- Exit routes restricted to needed CIDRs
Recommended Security
- Mutual TLS enabled
- SOCKS5 authentication enabled
- Shell disabled or password-protected
- File transfer disabled or restricted
- Monitoring and alerting configured
- Regular certificate rotation
Production Security
- All of the above
- CA key in HSM or secure vault
- Network segmentation
- Intrusion detection
- Audit logging
- Incident response plan
Quick Hardening
Apply these four changes for immediate security improvement:
-
Disable unused features - Shell and file transfer are disabled by default. Keep them disabled unless needed. See Shell and File Transfer configuration.
-
Restrict SOCKS5 access - Bind to localhost and enable authentication. See SOCKS5 Configuration.
-
Restrict exit routes - Only advertise specific CIDRs, not
0.0.0.0/0. See Exit Configuration. -
Enable mTLS - Require valid client certificates for peer connections. See TLS Configuration.
For detailed hardening guidance, see Best Practices.
Security Topics
| Topic | Description |
|---|---|
| E2E Encryption | Stream payload encryption |
| TLS/mTLS | Certificate-based security |
| Authentication | Client and shell authentication |
| Access Control | Route and command restrictions |
| Best Practices | Production hardening guide |
| Traffic Patterns | Network detection and analysis |
Reporting Security Issues
If you discover a security vulnerability:
- Do NOT open a public issue
- Contact the maintainers privately
- Provide detailed reproduction steps
- Allow reasonable time for fix before disclosure