Tors Proof-of-Work-Verteidigung: Denial-of-Service gegen Onion Services verteuern
Ein Onion Service unter Flutangriff kann nicht tun, was eine normale Website tut: Es gibt keine IP-Adressen zum Ratelimiting, denn weder Besucher noch Angreifer legen eine offen. Tors Antwort, ausgeliefert mit Tor 0.4.8 und im August 2023 im Projektblog vorgestellt, lautet: den Introduction-Schritt in Rechenzeit umpreisen. Der Entwurf geht auf Proposal 327 zurück, im April 2020 von George Kadianakis, Mike Perry, David Goulet und tevador verfasst, das den Kern nüchtern benannte: Der Aufbau von Rendezvous-Schaltkreisen ist teuer - für den Dienst und für das Netzwerk, und bloßes Rate-Limiting änderte daran nie etwas.
Ein Puzzle, das nur unter Last erscheint
Das Schema ist im Protokollsinne transparent: Es gibt keinen zusätzlichen Challenge-Roundtrip. Die Puzzle-Parameter liegen im Onion-Service-Descriptor, den Clients ohnehin abrufen - ein Versionstag, ein 32-Byte-Seed, ein vorgeschlagener Effort-Wert und ein Ablaufzeitpunkt. Solange der vorgeschlagene Effort bei null bleibt, schläft die Verteidigung, und Introductions laufen genau wie bisher. Stellt der Dienst Überlastung fest, hebt er den vorgeschlagenen Effort an. Die Clients lösen dann Equi-X, die im Proposal spezifizierte Puzzle-Funktion, über eine Challenge aus Personalisierungsstring, geblendeter Service-ID, Seed, einem zufälligen 16-Byte-Nonce und dem gewählten Effort. Die rund 43 Byte große Lösung reist als Erweiterung in der INTRODUCE1-Zelle mit. Laut dem Tor-Blog kostet ein erster Lösungsversuch auf schnellen Maschinen etwa 5 Millisekunden, auf langsamerer Hardware bis zu etwa 30; unter anhaltendem Angriff kann die nötige Arbeit Richtung einer Minute Rechenzeit klettern.Die Warteschlange bezahlt nach Mühe
Eine Lösung zu prüfen ist bewusst billig; der teure Teil - der Aufbau des Rendezvous-Schaltkreises - wird aufgeschoben. Verifizierte Anfragen landen in einer Prioritätswarteschlange, sortiert nach behauptetem Effort, ältere Einträge gewinnen bei Gleichstand, und ein Scheduler leert sie in geregeltem Tempo. Die Schwierigkeit folgt einem Add-Increase-/Multiply-Decrease-Zyklus über 300-Sekunden-Fenster: Bleibt die Warteschlange gesättigt, hebt der Dienst den Effort auf entweder den vorherigen Wert plus eins oder den Durchschnittseffort behandelter Introductions - je nachdem, was größer ist; lässt der Druck nach, schrumpft der Effort um etwa ein Drittel. Clients versuchen es mit steigendem Effort - unter 1.000 Verdopplung, danach Faktor 1,5 - innerhalb der Grenzen, die der Spec mit 8 und 10.000 setzt. Die Seeds rotieren ungefähr alle zwei Stunden, der vorherige Seed bleibt kurz gültig, um Races zu vermeiden.Warum normale Nutzer es meist nicht merken
Weil das Puzzle nur existiert, während der Dienst unter Stress steht, zahlt normaler Traffic bei geringer Last nichts. Wer während eines Angriffs ein paar Seiten anklickt, verbringt Millisekunden - ein Erlebnis, das der Blog mit dem Warten auf eine langsame Verbindung vergleicht - während ein Angreifer mit Millionen von Introductions für jede einzelne bezahlt. Die Zusammenfassung des Tor Projects:"Blocks attackers while giving real users a chance to reach their destination" - Tor-Project-Blog, August 2023
Wie sich Dienste einklinken
Betreiber steuern die Verteidigung über die torrc. Die Schalter, dokumentiert in dem Onion-Service-DoS-Leitfaden des Projekts:- HiddenServicePoWDefensesEnabled - veröffentlicht das Puzzle im Descriptor und aktiviert die nach Effort sortierte Warteschlange
- HiddenServicePoWQueueRate und HiddenServicePoWQueueBurst - wie schnell verifizierte Anfragen die Warteschlange verlassen
- CompiledProofOfWorkHash - eine globale Option, die die Hash-Funktion für Puzzles wählt