Skip to main content
Mole inspecting security

Security Overview

Muti Metroo is designed with security as a core principle. This guide covers the security model and best practices.

Security Model​

End-to-End Encryption​

All stream data is encrypted end-to-end between ingress and exit agents:

  • X25519 Key Exchange: Ephemeral keys per stream for forward secrecy
  • ChaCha20-Poly1305: Authenticated encryption prevents tampering
  • Transit Opacity: Transit agents cannot decrypt payload data
  • Key Derivation: HKDF-SHA256 with stream context

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​

LayerMechanismPurpose
E2EX25519 + ChaCha20-Poly1305Stream data encryption
TLSCertificatesPeer authentication
mTLSClient certsMutual authentication
SOCKS5Username/passwordClient authentication
RPCbcrypt passwordCommand authorization
File Transferbcrypt passwordTransfer authorization

Authorization​

  • Route-based ACL: Exit only allows configured CIDRs
  • RPC whitelist: Only whitelisted commands allowed
  • File path restrictions: Only allowed paths accessible

Threat Model​

What Muti Metroo Protects Against​

ThreatProtection
EavesdroppingTLS + E2E encryption
Compromised transitE2E encryption (transit cannot decrypt)
Replay attacksNonce-based encryption
Data tamperingAuthenticated encryption (Poly1305)
Man-in-the-middleCertificate validation
Unauthorized peersmTLS authentication
Unauthorized clientsSOCKS5 authentication
Unauthorized commandsRPC whitelist + password
Resource exhaustionConnection limits

What Muti Metroo Does NOT Protect Against​

ThreatMitigation
Compromised CASecure CA key management
Compromised hostHost security hardening
Traffic analysisUse VPN/Tor if needed
Insider threatAudit logging, monitoring

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
  • Mutual TLS enabled
  • SOCKS5 authentication enabled
  • RPC 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​

Disable Unnecessary Features​

# Disable RPC if not needed
rpc:
  enabled: false

# Disable file transfer if not needed
file_transfer:
  enabled: false

Restrict SOCKS5 Access​

# Localhost only + authentication
socks5:
  enabled: true
  address: "127.0.0.1:1080"
  auth:
    enabled: true
    users:
      - username: "user"
        password_hash: "$2a$12$..."    # Use cost 12+

Restrict Exit Routes​

# Only allow specific destinations
exit:
  enabled: true
  routes:
    - "10.0.1.0/24"    # Specific subnet, not 0.0.0.0/0

Enable mTLS​

# Require client certificates
listeners:
  - transport: quic
    tls:
      cert: "./certs/agent.crt"
      key: "./certs/agent.key"
      client_ca: "./certs/ca.crt"    # Require valid client cert

Security Topics​

TopicDescription
E2E EncryptionStream payload encryption
TLS/mTLSCertificate-based security
AuthenticationClient and RPC authentication
Access ControlRoute and command restrictions
Best PracticesProduction hardening guide

Reporting Security Issues​

If you discover a security vulnerability:

  1. Do NOT open a public issue
  2. Contact the maintainers privately
  3. Provide detailed reproduction steps
  4. Allow reasonable time for fix before disclosure

Next Steps​