Jeden Tor-Benutzer dazu zu verpflichten, ein Relay zu sein, würde dabei helfen, das Netzwerk zu skalieren, um alle unsere Benutzer zu bedienen; und ein Tor-Relay zu betreiben, kann deine Anonymität verbessern.
Viele Tor-Benutzer können jedoch keine guten Relays sein – zum Beispiel arbeiten einige Tor-Clients hinter restriktiven Firewalls, verbinden sich über ein Modem oder sind aus anderen Gründen nicht in der Lage, den Verkehr weiterzuleiten.
Die Bereitstellung von Diensten für diese Clients ist ein entscheidender Teil der Bereitstellung von effektiver Anonymität für alle, da viele Tor-Benutzer diesen oder ähnlichen Einschränkungen unterliegen und die Einbeziehung dieser Clients die Größe der Anonymitätsmenge erhöht.
Trotzdem wollen wir Tor-Benutzer dazu ermutigen, Relays zu betreiben. Was wir also wirklich tun wollen, ist, den Prozess des Aufbaus und der Pflege eines Relays zu vereinfachen.
Wir haben in den letzten Jahren eine Menge Fortschritte bei der einfachen Konfiguration gemacht: Tor ist gut darin, automatisch zu erkennen, ob es erreichbar ist und wie viel Bandbreite es anbieten kann.
Bevor wir dies jedoch tun können, müssen wir vier Schritte in Angriff nehmen:
Erstens müssen wir noch besser darin werden, die richtige Menge an Bandbreite automatisch zu ermitteln.
Es könnte sein, dass Umstellung auf UDP-Transport hier die einfachste Antwort ist – was leider überhaupt keine sonderlich einfache Antwort ist.
Zweitens müssen wir an der Skalierbarkeit arbeiten, sowohl des Netzwerks (wie können wir aufhören zu verlangen, dass alle Tor-Relays sich mit allen Tor-Relays verbinden können) als auch des Verzeichnisses (wie können wir aufhören zu verlangen, dass alle Tor-Benutzer über alle Tor-Relays Bescheid wissen).
Änderungen wie diese können große Auswirkungen auf die potenzielle und tatsächliche Anonymität haben.
Siehe Abschnitt 5 des Papiers Herausforderungen für weitere Einzelheiten.
Auch hier würde UDP-Transport helfen.
Drittens müssen wir die Risiken besser verstehen, die entstehen, wenn ein Angreifer Datenverkehr über dein Relay schickt, während du gleichzeitig deinen eigenen anonymisierten Datenverkehr einleitest.
In drei verschiedenen Forschungs-Arbeiten werden Methoden beschrieben, um die Relays in einem Kanal zu identifizieren, indem der Datenverkehr durch die in Frage kommenden Relays geleitet wird und nach Einbrüchen im Datenverkehr gesucht wird, während der Kanal aktiv ist.
Diese Verstopfungsangriffe sind im Tor-Kontext nicht so beängstigend, solange die Relays nicht auch Clients sind.
Wenn wir aber versuchen, mehr Clients dazu zu ermutigen, auch die Relayfunktionalität zu aktivieren (ob als Brücken-Relays oder als normale Relays), dann müssen wir diese Bedrohung besser verstehen und lernen, wie man sie entschärfen kann.
Viertens brauchen wir vielleicht eine Art Anreizsystem, um Leute zu ermutigen, Verkehr für andere weiterzuleiten und/oder Ausgangsknoten zu werden.
Hier sind unsere aktuellen Überlegungen zu Tor-Anreizen.
Bitte hilf bei all diesen Überlegungen!
Es wäre schön, wenn Relay-Betreiber in ihren Exit-Richtlinien Dinge wie www.slashdot.org ablehnen sagen könnten, anstatt von ihnen zu verlangen, den gesamten IP-Adressraum zu lernen, der von der Site abgedeckt werden könnte (und dann auch andere Sites an diesen IP-Adressen zu blockieren).
Es gibt da aber zwei Probleme.
Erstens konnten die Nutzer diese Sperren immer noch umgehen.
Sie könnten zum Beispiel die IP-Adresse statt des Hostnamens anfordern, wenn sie das Tor-Netzwerk verlassen.
Das bedeutet, dass die Betreiber immer noch alle IP-Adressen für die fraglichen Zielorte lernen müssen.
Das zweite Problem ist, dass es außenstehenden Angreifern erlauben würde, beliebige Seiten zu zensieren.
Wenn zum Beispiel ein Tor-Betreiber www1.slashdot.org blockiert und dann ein Angreifer das DNS des Tor-Relays manipuliert oder den Hostnamen so ändert, dass er auf die IP-Adresse einer großen Nachrichtenseite aufgelöst wird, dann blockiert der Tor-Relay plötzlich die Nachrichtenseite.
Nein, du kannst dich nicht darauf verlassen, dass das Netz den Pfad auswählt.
Böswillige Relays könnten dich über ihre konspirativen Freunde weiterleiten.
Dies würde einem Gegner die Möglichkeit geben, deinen gesamten Datenverkehr von Anfang bis Ende zu überwachen.
Dies wäre aus mehreren Gründen praktisch:
Es würde Tor besser in die Lage versetzen, neue Protokolle wie VoIP zu verarbeiten.
Damit könnte die Notwendigkeit der Socketierung von Anwendungen vollständig gelöst werden.
Ausgangs-Relays müssten auch nicht viele Dateideskriptoren für alle Ausgangs-Verbindungen zuweisen.
Wir sind auf dem Weg in diese Richtung. Einige der schwierigen Probleme sind:
IP-Pakete verraten die Merkmale des Betriebssystems.
Wir müssten immer noch eine Normalisierung der Pakete auf IP-Ebene vornehmen, um Angriffe wie TCP-Fingerprinting zu verhindern.
In Anbetracht der Vielfalt und Komplexität der TCP-Stacks und der Angriffe durch Geräte-Fingerprinting sieht es so aus, als ob es am besten wäre, einen eigenen User-Space-TCP-Stack zu entwickeln.
Streams auf Anwendungsebene müssen noch bereinigt werden.
Wir werden weiterhin benutzerseitige Anwendungen wie Torbutton benötigen.
Es wird also nicht nur darum gehen, Pakete zu erfassen und sie auf dem IP-Layer zu anonymisieren.
Bei bestimmten Protokollen existieren immer noch Informationslecks.
So müssen wir beispielsweise DNS-Anfragen so umschreiben, dass sie an einen nicht verlinkbaren DNS-Server und nicht an den DNS-Server des Internetanbieters des Benutzers weitergeleitet werden; wir müssen also die Protokolle verstehen, die wir transportieren.
DTLS (Datagram-TLS) hat im Grunde keine Benutzer, und IPsec ist wirklich groß.
Sobald wir uns für einen Transportmechanismus entschieden haben, müssen wir ein neues Ende-zu-Ende-Tor-Protokoll entwerfen, um Markierungsangriffe und andere potenzielle Anonymitäts- und Integritätsprobleme zu vermeiden, da wir nun Abbrüche, erneutes Senden usw. erlauben.
Ausgangsrichtlinien für beliebige IP-Pakete bedeuten den Aufbau eines sicheren Intrusion-Detection-Systems (IDS).
Unsere Knotenbetreiber sagen uns, dass die Ausgangsrichtlinien einer der Hauptgründe sind, warum sie bereit sind, Tor zu betreiben.
Ein IDS hinzuzufügen, um Ausgangsrichtlinien zu handhaben, würde die Sicherheitskomplexität von Tor erhöhen und würde wahrscheinlich sowieso nicht funktionieren, wie der gesamte Bereich der IDS- und Gegen-IDS-Papiere beweist.
Viele potentielle Missbrauchsprobleme werden durch die Tatsache gelöst, dass Tor nur gültige TCP-Streams transportiert (im Gegensatz zu beliebiger IP, einschließlich fehlerhafter Pakete und IP-Floods).
Mit der Möglichkeit, IP-Pakete zu transportieren, gewinnen die Ausgangsrichtlinien noch mehr an Bedeutung.
Wir müssen auch die Ausgangsrichtlinien im Tor-Verzeichnis kompakt beschreiben, sodass die Clients vorhersagen können, durch welche Knoten ihre Pakete hinausgelassen werden.
Außerdem müssen die Clients alle Pakete, die sie in einer Sitzung senden wollen, vorhersagen, bevor sie ihren Ausgangsknoten auswählen!
Die Tor-internen Namensräume müssten umgestaltet werden.
Wir unterstützen die „.onion“-Adressen des Onion-Dienstes, indem wir die Adressen abfangen, wenn sie an den Tor-Client übergeben werden.
Dies auf IP-Ebene zu tun, erfordert eine komplexere Schnittstelle zwischen Tor und dem lokalen DNS-Resolver.