End-to-End Encryption Security

NFLTR provides two end-to-end encrypted tracks, TLS passthrough and P2P direct, plus a WireGuard VPN that is end to end between client and exit. Tunnel commands run in verified end-to-end encryption by default. Inspectable mode is available only as an explicit opt-in via --e2ee=false.

Tutorials: End-to-end encryption with pairing keys · Reach a private LAN over WireGuard

Encrypted Tracks

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.

Supported Commands

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

# Let's Encrypt certificate for the share's E2EE host name
nfltr http 3000 --share

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

WireGuard VPN

Full Layer 3 VPN tunnel using the WireGuard protocol. Runs in userspace (no root required) using gvisor netstack.

What the relay sees: sealed WireGuard packets, and which client connects to which exit, when, and how much. WireGuard is end to end: the client and the exit are peers of each other, and the relay forwards their packets without holding a WireGuard key, so it cannot read addresses, ports or payloads inside the tunnel. The relay does pass each side the other's public key, so a compromised relay could swap in its own key and sit in the middle; the same pairing key on both ends (--e2ee-key-file) stops that, because a relay without the secret cannot complete a WireGuard handshake. Accounts are isolated: a client reaches only the exit it named in its own account.

# Start WireGuard server on the agent; it forwards only to --allow
nfltr wg serve --name my-network --allow 192.168.1.0/24

# 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.

Cryptography Summary

What's Encrypted

A2A messaging: what it protects, and what it does not

Agent-to-agent frames (nfltr a2a, and the hub, nodes and workers of nfltr orch) are encrypted with X25519 key agreement, a SHA-256 key derivation and AES-256-GCM, on by default (--e2ee, NFLTR_A2A_E2EE).

• A relay that only watches sees ciphertext.
• An active relay: the ephemeral keys are not signed, so a relay that swapped them could read the traffic. A pairing key (--e2ee-key-file, NFLTR_A2A_E2EE_KEY_FILE), a random secret held only by your machines, closes this: each end proves it holds the key over both public keys before anything is sent, and a relay that swaps keys is refused. It proves the peer is one of your machines, not which one. Your account API key cannot do this job: the relay sees it on every request.
• No downgrade: an end with E2EE on refuses unencrypted requests, with an error naming the flag, and never falls back itself. Exceptions, by design: messages to the relay's own agent, and relay-originated work that a worker accepts (a task POSTed to the relay's task API, a label-selector fleet invocation), which the relay sees anyway. With a pairing key, workers refuse relay-originated work too.
• Not covered: metadata: agent and machine ids, labels, timing and message sizes. A hub refuses every task request from the relay's own agent and sends the relay no summary of its runs, so the dashboard shows none; runs stay on the hub's machine (nfltr orch hub runs; see What the relay sees).

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. Subsequent data is encrypted end-to-end — the server relays opaque bytes it cannot decrypt (for A2A and WireGuard, against an active relay only with a pairing key; see above)