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