Skip to content

Relay

After Iran's 80-day blackout, traffic surged through our community's Tor WebTunnel bridge

For people in Iran, the outside internet barely existed for nearly three months. When connectivity started to come back a few days ago, the Tor WebTunnel bridge our community runs began taking on a wave of traffic. That was Iranians who had found a way around the censorship and reconnected to Tor, getting back onto the wider internet.

Wherever you are, you can help

If you have a VPS (a small cloud server) or a physical machine, plus a domain name, you can run a Tor WebTunnel bridge and give people cut off by censorship a way back onto the open internet. Can't run a server? Open a browser tab and run Snowflake instead, it contributes anonymous traffic just the same.

Server specs, legal considerations, and the full setup steps are written up in How to set up a Tor WebTunnel bridge.

A Server That Forgets: why this relay design deserves attention

The Tor Project post, A Server That Forgets: Exploring Stateless Relays, is grounded in real operator experience from Osservatorio Nessuno in Italy. It is not just a technical tour. It asks a basic trust question: if a relay can be seized, searched, or physically cloned, what exactly can an adversary still learn?

Why this is worth translating

First, the article starts from actual seizure and raid precedents. That makes the threat model concrete. Relay operators are not debating abstract malware only; many are planning for legal process and physical hardware exposure.

Second, it gives a rare end-to-end map of the stack: TPM, measured boot, remote attestation, RAM-only runtime, VM images, and tooling paths such as Patela and stboot. Most discussions in our region cover one layer at a time. This one connects them.

Third, it keeps the hard parts visible. Re-sealing after updates, conflicts between stateless images and unattended upgrades, memory ceilings without swap, and the risk of losing a Stable flag due to restarts are all left as open engineering work, not hidden in marketing language.

A Server That Forgets

What "stateless relay" changes in practice

A stateless system reboots into a known image and does not keep writable disk state. In security terms, this shifts defaults:

  • physical seizure yields less forensic material;
  • configuration drift is constrained by declarative rebuilds;
  • persistence across reboots becomes harder for attackers;
  • reproducibility and auditability become more realistic goals.

For Tor relays, there is one unavoidable tension: identity must survive reboots. Relays build reputation over time through long-term keys. If keys disappear on every boot, the node loses its standing and utility.

That is where TPM-backed key handling matters. Keys can be bound to measured boot state and used without handing raw private key material to the operating system. Remote attestation can then let an external verifier check what software stack actually booted. But the limitations are real too, including key-type mismatches and operational complexity.

Three deployment paths, three trade-offs

The post compares three practical models:

  • minimal RAM-disk setups (simple, manual key operations);
  • VM-based RAM images (easier rollback and image lifecycle);
  • bare metal with TPM + verified boot (stronger trust chain, heavier operations).

No single model wins everywhere. The right choice depends on threat model, budget, hosting constraints, and team maturity.