Trust model

Security is designed around precise access.

ntwire does not assume a connected client should reach an entire network. Server configuration grants a user only the tunnels and destinations they are meant to use.

Two protected layers

TLS protects control-plane authentication. SSH keys and OIDC are parallel sign-in methods that create the same session type. WireGuard protects tunnel traffic; WebSocket fallback remains token-authenticated when UDP cannot pass.

Server identity matters

For a self-signed deployment, clients pin the server certificate on first connection. That prompt is a trust decision, not a nuisance: verify the fingerprint with the server operator before accepting it. For a stable public hostname, a certificate from a trusted CA avoids the first-use prompt.

Relays forward, not decrypt

An ntwire relay is deliberately not the endpoint of client trust. It forwards opaque bytes between a client and registered server, and does not hold the key material needed to decrypt the client’s TLS or WireGuard session. A certificate configured on the relay itself only protects servers registering with it — the certificate a client actually sees still belongs to the origin server, so a trusted CA certificate for browser- or OS-consumed endpoints (like a proxy auto-config URL) must be configured there, not on the relay.

Operator responsibilities

• Grant the smallest set of tunnels and destinations needed for each identity.
• Keep server configuration, SSH keys, OIDC credentials, and administrator tokens protected.
• Bind local listeners safely and review the implications before exposing them beyond loopback.
• Treat unrestricted SOCKS access and relay-mediated transport as explicit high-risk capabilities.

Read the full Security notes, destination policy guide, and OIDC setup guide before operating a production deployment.