Tor and Anonymity Networks

What It Is

This page covers how FortrOS handles transport camouflage -- making network traffic look like something other than a VPN to outside observers. The core question isn't "how does Tor work?" but "what does an observer see, and how does FortrOS control that?"

FortrOS uses WireGuard for its overlay network. WireGuard is UDP-only with a recognizable handshake pattern. On a home network or friendly data center, this is fine. On a hostile network -- nation-state censorship, repressive regime, corporate DPI, or adversarial ISP -- recognizable VPN traffic is a problem.

Why It Matters

The extreme use case: a FortrOS laptop that looks like a normal Linux desktop. Peripherals are passed to a client VM. The user sees Ubuntu or Fedora. FortrOS is the invisible hypervisor underneath, routing connectivity through the org's secure overlay. An authority demanding to inspect the device sees a normal laptop. The network admin sees normal web traffic.

This isn't theoretical. In 2011, CIA assets in Iran and China were identified partly because handler communication used recognizable patterns (sequential URLs on a shared web platform). The operational failure was that the communication infrastructure was identifiable. FortrOS's transport layer must not be identifiable.

Security must be plug-and-play. The user shouldn't need to understand Tor or configure transports. The org's policy sets the required transport profile, and the maintainer handles the rest.

Transport Profiles: What the Observer Sees

FortrOS nodes are configured with a transport profile that determines how overlay traffic appears to the network:

The profile is set per-node or per-org. A homelab uses direct. A corporate laptop uses tcp-wrapped. An asset in a repressive regime uses tor-obfuscated. The user never touches transport configuration -- the org's policy determines it, and the maintainer automatically selects the lightest working profile.

Profile Selection

The maintainer probes what the network allows and selects the lightest transport that succeeds:

1. Try direct WireGuard UDP to a lighthouse
2. If blocked: try TCP wrapping (HTTPS WebSocket)
3. If blocked: try obfuscation (obfs4-style)
4. If blocked: try CDN fronting or Tor rendezvous
5. If all fail: wait and retry (the network may be fully offline)

Fallback is automatic. If the network changes (moved from Wi-Fi to cellular, VPN policy changed), the maintainer re-probes and adjusts.

The Technologies

Tor (The Onion Router)

Tor is a volunteer-operated network of ~6,000-8,000 relays that routes traffic through three encrypted hops so no single relay knows both who you are and where you're going.

Onion routing (3-hop circuit):

Client -> [Guard node] -> [Middle relay] -> [Exit node] -> Destination

• Guard: Knows your IP but not your destination
• Middle: Knows neither
• Exit: Knows the destination but not your IP

Onion services (rendezvous): Both sides build circuits into Tor and meet at a rendezvous point. Six hops total. Neither side learns the other's IP. No exit node -- traffic never leaves Tor. Addresses are .onion domains (56 characters, encoding an Ed25519 public key). FortrOS uses this for the tor-rendezvous profile: two nodes find each other inside Tor without revealing their real IPs to anyone.

What Tor protects: Source-destination linkage. An observer knows you're using Tor but can't tell where your traffic goes.

What Tor doesn't protect: Application-layer leaks, compromised endpoints, traffic confirmation attacks (adversary watching both entry and exit can correlate timing).

Tor Pluggable Transports

Protocols that disguise Tor traffic so it doesn't look like Tor:

• obfs4: Traffic looks like random noise. No recognizable pattern.
• meek: Traffic routes through a CDN using domain fronting. Looks like HTTPS to ajax.aspnetcdn.com or www.google.com.
• Snowflake: Uses WebRTC through volunteer browser proxies. Looks like a video call.

These are the building blocks for the obfuscated, cdn-fronted, and tor-obfuscated profiles.

I2P (Invisible Internet Project)

A separate anonymity network (unrelated to Tor) optimized for internal services rather than public internet access. Uses "garlic routing" (bundles multiple messages to defeat traffic analysis) and unidirectional tunnels. I2P has native UDP support (SSU2) which is more compatible with WireGuard than Tor's TCP-only approach, but the network is much smaller (~50,000-80,000 users vs Tor's ~2-3 million) and less audited. FortrOS does not currently use I2P but it remains an option for environments where Tor is specifically targeted.

Performance Reality

The performance gradient matches the threat gradient. On friendly networks, you get full speed. On hostile networks, you trade performance for undetectability. The org's mission determines the acceptable tradeoff.

Device Inspection Resistance

For the most sensitive use case (device appears normal under physical inspection):

• The VM layer: The user interacts with a standard Linux desktop VM. FortrOS is the hypervisor underneath, invisible to the desktop OS. Peripherals (keyboard, mouse, display) are passed through to the VM.
• The disk: /persist is LUKS-encrypted. Without the org's key material (TPM + org auth), it's indistinguishable from random data. The ESP contains a preboot UKI that could be identified as FortrOS -- for maximum deniability, the ESP can be configured to also contain a normal Linux bootloader as a decoy.
• The network: Transport profile determines what's visible. With tor-obfuscated, network traffic looks like normal HTTPS or video calls. No VPN signatures, no recognizable endpoints, no sequential patterns.
• No operational footprint: The org's lighthouses use common cloud providers (not dedicated servers with identifiable IPs). Lighthouse addresses rotate. No shared infrastructure patterns that could link multiple assets.

The goal: an authority with physical access to the device and network logs finds a normal laptop making normal web traffic. FortrOS's presence is not apparent without the cryptographic keys to unlock /persist.

Leak Prevention and Fingerprinting

Encrypting the tunnel isn't enough. Side channels can reveal FortrOS's presence even when the payload is invisible:

The Principle

Every packet that leaves the physical NIC must be consistent with the cover story. If the transport profile says "this is a normal laptop browsing the web," then DNS, NTP, TLS fingerprints, traffic patterns, and WiFi behavior must all match that story. A single inconsistency (a non-browser TLS fingerprint, a DNS query for an unusual domain, regular traffic bursts) is enough for a sophisticated observer to flag the device.

FortrOS handles this at the maintainer level: the transport profile isn't just "wrap WireGuard in HTTPS" -- it's a comprehensive set of behaviors that align all observable network activity with the expected cover. The org's security policy determines how thorough the camouflage needs to be. A homelab doesn't need any of this. An asset in a repressive regime needs all of it.

Links

• Tor Project
• Tor Pluggable Transports
• I2P
• obfs4 (Lyrebird)
• Snowflake
• Shadowsocks