End-to-End Encryption Security

NFLTR provides three distinct E2EE tracks. Tunnel commands run in verified end-to-end encryption by default. Inspectable mode is available only as an explicit opt-in via --e2ee=false.


Three E2EE Tracks

🔐 TLS Passthrough (default)

Tunnel commands run in verified mode by default. The agent generates or loads a TLS certificate and terminates TLS itself. The server routes by SNI hostname without decrypting and sees only the TLS ClientHello.

Protocols: HTTPS, gRPCS, any TLS-wrapped protocol
Cert options: Auto-generated ECDSA P-256, user-provided cert/key, or ACME/Let's Encrypt

🛡️ WireGuard VPN (nfltr wg)

Full L3 VPN tunnel using WireGuard. Curve25519 key exchange over gRPC metadata. The server relays opaque encrypted UDP packets — no access to the plaintext IP traffic.

Protocols: TCP, UDP, ICMP — any IP protocol
Features: Userspace (no root), SOCKS5 proxy, CGNAT address allocation

✦ P2P Direct (nfltr p2p)

Data flows directly between peers after HMAC-authenticated handshake. AES-256-CTR encryption with per-session keys. The server handles signaling only — data never touches the relay.

Features: File transfer, text chat, audio/video calls
NAT traversal: STUN-assisted, falls back to encrypted relay

TLS Passthrough for Tunnel Commands

Tunnel commands run with agent-terminated TLS by default. Use --e2ee=false only when you need inspectable mode for debugging.

CLIENT (Browser) TLS ClientHello SNI: agent.e2ee.nfltr.xyz Encrypted HTTPS NFLTR SERVER Read SNI → route to agent Cannot decrypt (no key) AGENT (--e2ee) TLS termination ECDSA P-256 / ACME cert → localhost:port Opaque TLS bytes — server cannot read payload

Supported Commands

CommandDefault behavior
nfltr httpAgent terminates HTTPS; share URL serves over agent's TLS cert
nfltr tcpTCP tunnel with agent-terminated TLS wrapping
nfltr terminalBrowser terminal via agent's HTTPS server (xterm.js)
nfltr shellEmbedded SSH over agent-terminated TLS
nfltr commandCommand-as-a-service over agent's HTTPS
nfltr serveFile server over agent-terminated HTTPS
nfltr tailLog tail viewer over agent's HTTPS
nfltr watchLive command output over agent's HTTPS
nfltr shareEphemeral content share over agent's HTTPS
nfltr aiAI session (Claude, etc.) over agent's HTTPS
nfltr a2aAgent-to-agent with payload encryption (default on)

Certificate Options

# Auto-generated self-signed ECDSA P-256 cert (default verified mode)
  nfltr http 3000

# User-provided certificate and key
nfltr http 3000 --e2ee-cert server.crt --e2ee-key server.key

# ACME / Let's Encrypt trusted certificate
nfltr http 3000 --acme-domain myapp.e2ee.nfltr.xyz

# Explicit inspectable mode for debugging
nfltr http 3000 --e2ee=false

WireGuard VPN

Full Layer 3 VPN tunnel using the WireGuard protocol. The server relays opaque WireGuard packets — it has no access to the Curve25519 session keys or plaintext IP traffic. Runs in userspace (no root required) using gvisor netstack.

🔑 Curve25519 Key Exchange

WireGuard public keys exchanged over gRPC metadata headers. The server allocates a CGNAT IP (100.64.0.0/10) but never possesses the private keys.

🌐 SOCKS5 Proxy

Connect via nfltr wg socks5 — routes TCP traffic through the WireGuard tunnel. Access remote services as if you were on the same LAN.

🖥️ Userspace — No Root

gvisor netstack handles packet processing entirely in userspace. No sudo, no /dev/tun, no kernel modules. Works on macOS, Linux, and Windows.

# Start WireGuard server on the agent
nfltr wg serve --name my-network

# Connect from another machine via SOCKS5
nfltr wg socks5 my-network --listen :1080

# Access remote services through the tunnel
curl --proxy socks5://localhost:1080 http://192.168.1.100:8080

P2P Direct Transfer

Data flows directly between peers after an HMAC-authenticated handshake. AES-256-CTR encryption with per-session key derivation. The server handles signaling only — payload never touches the relay.

AGENT A (Sender) Generate ephemeral key HMAC authentication Derive session AES key AES-256 Encrypted data stream STUN NAT traversal NFLTR SERVER Signaling only Relay handshake msgs Cannot decrypt data No data passes through after handshake AGENT B (Receiver) Generate ephemeral key HMAC verification Derive session AES key AES-256 Decrypted data received STUN NAT traversal Direct P2P (encrypted)

Cryptography Summary

🔐 AES-256-GCM / CTR

P2P transfers use AES-256-CTR stream encryption. A2A messaging uses AES-256-GCM authenticated encryption. Both provide confidentiality and integrity.

🔑 Per-Session Keys

Fresh keys derived for every session — X25519 ECDH for A2A, HMAC-based KDF for P2P, Curve25519 for WireGuard. Compromising one session doesn't affect others.

🤝 HMAC Mutual Auth

P2P connections authenticate both parties via HMAC challenge-response before any data flows. Prevents man-in-the-middle attacks during handshake.

🌐 STUN NAT Traversal

P2P connections bypass the server entirely after handshake. STUN-assisted NAT traversal works across LAN, CGNAT, and hairpin NAT. Falls back to encrypted relay if direct connection fails.

🚫 Zero Server Knowledge

Across all three tracks, the server never possesses session keys or plaintext data. TLS passthrough reads only SNI; WireGuard relays opaque packets; P2P data bypasses the server entirely.

📜 Audit Trail

SHA-256 hash chain commitments let peers compare session history and detect modified, dropped, injected, or reordered frames when they exchange commitments.

What's Encrypted

TrackWhat's E2EEWhat the server sees
TLS PassthroughAll HTTP/TCP traffic (agent terminates TLS)SNI hostname only — opaque TLS bytes
WireGuard VPNAll IP traffic (TCP, UDP, ICMP)Opaque WireGuard packets — no IP headers
P2P DirectFile contents, chat messages, call mediaOnly handshake signaling — no data passes through
A2A MessagingPayload bytes (AES-256-GCM by default)Routing headers (agent IDs) — payload is ciphertext

Trust Model

NFLTR uses a trust-the-server-for-routing-only model:

  1. Agents authenticate to the server (API key / fleet token / mTLS)
  2. The server performs routing: SNI-based for TLS passthrough, IP allocation for WireGuard, signaling relay for P2P
  3. All subsequent data is encrypted end-to-end — the server relays opaque bytes it cannot decrypt
  4. Optional audit-trail commitments let peers compare what each side saw during a session
💡 E2EE is the default tunnel mode

Tunnel commands run in end-to-end encrypted verified mode by default, where the NFLTR relay cannot read your traffic. Use --e2ee=false only when you intentionally need inspectable mode for debugging. If a CDN or reverse proxy terminates TLS in front of the relay, that edge is outside this guarantee.

Need a practical verification workflow?

E2EE Verification walks through the exact dashboard, proof page, JSON, and proof bundle checks to confirm that a live tunnel is running in verified mode at the NFLTR relay and that the exposed identity matches the agent you trust.

Private by design

Three E2EE tracks - TLS passthrough, WireGuard VPN, and P2P direct. Verified mode is the default for tunnel commands.

Download Agent P2P Transfer →