Tailscale encryption

Tailscale's architecture provides end-to-end encryption for all network communications, whether devices connect directly or through a relayed connection⎯regardless of whether they're on the same local network or across the globe. The architecture uses multiple layers of encryption across the control plane and data plane to secure device connections throughout your Tailscale network (known as a tailnet).

The following sections explain Tailscale's use of encryption across the control and data planes, during NAT traversal operations, and throughout the Tailscale ecosystem.

Control and data planes

The control and data planes are fundamental network components that work together to manage and execute network operations. Each plane has a distinct division of responsibilities to minimize the impact of security breaches and facilitate independent scalability. The control plane manages how data flows, which includes policy management, routing, resource management, and signaling (session management). The data plane executes instructions from the control plane. These include packet forwarding, packet processing, and traffic management. In effect, the control plane makes the decisions, and the data plane executes those decisions.

Control plane

In Tailscale, the control plane performs many tasks, including device coordination, authentication, access control interpretation, and packet filter computation.

Control plane communication, which includes key exchange and coordinating device connections, employs a custom Noise IK-based protocol with X25519 as described in RFC7748. While it can operate directly over plain TCP in environments that allow it, it also supports being wrapped in TLS when necessary for compatibility or additional security requirements.

Data plane

Tailscale's data plane uses WireGuard as its primary mechanism to encrypt communication between Tailscale devices. You can learn more about WireGuard's cryptographic design in the WireGuard white paper.

Tailnet devices start out using a DERP server to establish a connection, then transition to a direct connection if possible. If a direct connection isn't possible, devices fall back to a relayed connection using DERP servers. DERP servers never see your unencrypted data; they only handle WireGuard packets that are already encrypted.

The connection between devices and DERP servers are authenticated using a NaCl box construction on top of TLS to verify that clients own their claimed WireGuard keys. This ensures only devices with the correct private key can establish a connection with the DERP server.

Device discovery and NAT traversal

Tailscale's NAT traversal engine implements a custom UDP protocol for path discovery, using NaCl box for authenticated encryption. This protocol operates separately from the main WireGuard data plane, and can only influence the efficiency of connections, not the security of the data they carry.

Encryption across Tailscale

Tailscale also uses encryption for authentication, certificates, and features like the logging system and tailnet lock.

Device TLS certificates

Tailscale assists you with provisioning TLS certificates from Let's Encrypt using hostnames within your tailnet's MagicDNS domain. You can use these certificates to ensure that only authorized devices can join your tailnet.

Tailnet lock

The tailnet lock feature, uses ED25519 signatures for authentication. While this feature doesn't involve encryption directly, it ensures that only devices authorized by designated approvers (which are not under Tailscale's control) can communicate with devices in your tailnet.

Log system

All Tailscale log data is sent over TLS without additional authentication or encryption.

TLS and cryptography

Tailscale's TLS (Transport Layer Security) implementation builds upon the Go crypto/tls package, requiring a minimum of TLS 1.2 while supporting TLS 1.3. The system uses the default cipher suite selection from the Go implementation, which includes ECDHE for forward secrecy and AEAD schemes. The AEAD implementation can dynamically choose between AES-128-GCM or ChaCha20-Poly1305 based on the availability of hardware acceleration for AES operations.

Compliance

Tailscale's cryptographic implementations are not FIPS compliant, and several of the primitive choices (including Curve25519, XSalsa20, ChaCha20-Poly1305, and the Noise and WireGuard protocols) cannot be made compliant under current FIPS standards. While these implementations have been reviewed by cryptographers and are considered secure⎯in many cases, providing superior security to FIPS-approved alternatives⎯this might be a consideration for organizations requiring FIPS compliance.