The Second-Generation Onion Router

Einleitung

"TOR - The 2nd generation Onion Router" ist das Nachfolgeprojekt von den Entwicklern des Onion Routings und setzt somit auch das Zwiebelprinzip um. Dieses bezeichnet ein Verschlüsselungsschema bei dem die Daten über eine ständig wechselnde Route von Knoten (Nodes) geleitet werden. Bei jedem Knoten finden dann Ver- oder Entschlüsselungsoperationen statt, je nachdem ob die Daten ein- oder ausgehen. Diese stufenweise Verschlüsselung führt zum Begriff des Zwiebelprinzips.

Im Vergleich zum Vorgänger, dem Onion Routing, gibt es eine Reihe von Verbesserungen. So konnten Knoten früher den Verkehr aufnehmen und später wieder einspielen - jetzt wird der Verbindungstunnel inkrementell aufgebaut und bei jedem Sprung zum nächsten Knoten ein eigener Session Key ausgehandelt. Sobald diese Schlüssel gelöscht sind, kann der Verkehr nicht mehr entschlüsselt werden. Früher musste für jede Anwendung ein eigener Proxy geschrieben werden - jetzt werden mit dem SOCKS Proxy Interface alle TCP-basierten Programme ohne weitere Modifikation unterstützt. Auch können jetzt mehrere Streams über einen Verbindungstunnel laufen, wodurch man wesentliche Verbesserungen der Performance erreicht.

Das generelle Problem dem sich TOR begegnen will, ist die Überwachung des Internetverkehrs durch die Datenanalyse. Durch diese kann man erkennen, wer mit wem über ein öffentliches Netzwerk kommuniziert hat, was nicht nur in China, sondern überall auf der Welt zu Problemen führen könnte. Der Datenverkehr besteht aus zwei Teilen, der Nutzlast, in der die eigentlichen Daten enthalten sind, und den Kopfteil, in dem sich verschiedene Informationen zum Routing befinden. Auch wenn man die Nutzlast verschlüsselt, enthält der Kopf verwertbare Informationen darüber, wer mit wem kommuniziert hat.

Konzept von TOR

Bezug zu anderen Projekten

Moderne Arbeiten die sich mit anonymen Netzwerken beschäftigen, verwenden zumeist Chaum's MixNet-Design, in welchem man die Korrespondenz von Sender und Empfänger versteckt, in dem man die Nachrichten durch mehrere Schichten von Verschlüsselungen umhüllt und durch einen zufälligen Pfad durch das Netz schickt. Im wesentlichen haben sich dabei zwei Richtungen entwickelt. Zum einen high-latency Designs, die eine maximale Anonymität durch hohe und variable Latenzzeiten bieten und größeren Angriffen standhalten, und zum anderen low-latency Designs, zu denen auch TOR gehört, die versuchen den Datenverkeher zu anonymisieren, aber trotzdem noch für interaktive Anwendungen wie IRC oder SSH verwendbar sein sollen. Darum sind sie aber auch leichter anzugreifen, da durch die Fülle an Datenpaketen, die in möglichst schneller Zeit versendet werden sollen, das Abhorchen der Kommunikation wesentlich einfacher ist.

Design-Ziele (Goals)

Anwendbarkeit

Ein sehr wichtiges Ziel des Designs ist es, dass TOR im alltäglichen Gebrauch verwendbar ist. Dafür darf es nicht zu viel Bandbreite des Nutzers beanspruchen, damit dieser noch über eine ausreichende Verbindung ins Netz verfügt. Des weiteren sollte die Installation recht einfach sein. Durch nötige Kernel-Patches oder verschiedene Proxies würde dies unnötig erschwert werden. Außerdem sollten Nutzer nicht dafür haftbar gemacht werden können, wenn über ihre Verbindungen Aktivitäten von Angreifern ausgehen.

Benutzbarkeit

Da schwer benutzbare Systeme nur wenig Nutzer haben, anonyme Netze aber viele Nutzer brauchen um auch anonym zu sein, ist es sehr wichtig, dass TOR einfach zu benutzen ist. Darum sollte man keine anderen Programme wegen TOR modifizieren müssen, keine zu großen Latenzzeiten erzeugen, für alle Plattformen verfügbar sein und so wenig wie möglich an Konfigurationseinstellungen bieten.

Flexibilität

Damit auch andere Projekte auf der Basis von TOR arbeiten können, oder Teilprobleme von TOR unabhängig bearbeiten werden können, sollte das Design einfach zu erweitern und gut spezifiziert sein.

Einfaches Design

Wenn das Design und die Sicherheitsparameter gut zu verstehen sind, wird die Komplexität und Implementation von Erweiterungen nicht zu aufwändig.

Keine Ziele (Non-Goals)

Für manche Probleme gibt es keine oder nur unzureichende Lösungen. Daher verzichtet man lieber auf die Verwendung dieser, auch wenn sie eigentlich gewisse Vorteile besitzen. So ist das Design zum Beispiel nicht Peer-to-Peer (durch die Directory Server), wobei es dazu unterschiedliche Angaben gibt. Auch bieten low-latency Systeme wissentlich keine Sicherheit gegen end-to-end-Attacken, da diese einfach zu schwer abzuwehren sind.

Threat-Modell

Für ein anonymes Netzwerk haben Bedrohungen meistens die Form einer passiven globalen Analyse des Netzwerkverkehrs. Gegen Angriffe solcher Stärke hat TOR jedoch kaum Chancen und nimmt daher an, dass Angriffe eher in der Art erfolgen, dass Teile des Netzwerkverkehrs überwacht, dieser erzeugt, verändert, gelöscht oder verzögert werden kann, oder dass Onion Router übernommen und nach belieben gesteuert werden können. Nun kann der Angreifer entweder passiv agieren und den Verkehr an beiden Enden der Verbindung abhören und sie durch Timing und Volumen der Pakete miteinander verbinden. Wenn er aktiv agiert, kann der Angreifer versuchen die Schlüssel zu cracken oder Timing Signaturen einfügen um Unterschiede zwischen den Paketen noch deutlicher sichtbar zu machen. TOR hält diesen Angriffen nur in gewissem Maße stand.

TOR-Design

Onion Router, Onion Proxies und Schlüssel

Tor kann ausschließlich TCP-Streams verarbeiten. Das Netzwerk besteht aus Knoten, den Onion Routern (OR). Darüberhinaus gibt es noch Onion Proxies, welche eine reine Client-Lösung sind, d.h. einen OP installiert sich jeder, der TOR nur benutzen will, jedoch kein dauerhafter Knoten des Netzwerks werden will und auch nicht den Datenverkehr anderer Nutzer weiterleiten will. Onion Router hingegen nehmen auch Datenverkehr von anderen Knoten an und leiten ihn durch das Netzwerk weiter.

Jeder Onion Router besitzt einen Identity Key und einen Onion Key. Mit dem Identity Key werden TLS-Zertifikate und OR-Descriptoren (siehe [Directory Server]) signiert. Der Onion Key wird zur Entschlüsselung von Anfragen anderer Benutzer verwendet und wir auch zum Aushandeln von Sessionkeys für neue Verbindungen benötigt. Es existiert auf link-eben noch ein link-key ( vom TLS-Protokoll ), der hier aber nicht weiter betrachtet wird.

Zellen

Datenpackete werden im TOR-Netzwerk Zellen genannt und haben eine feste Länge/Größe von 512 Bytes. Auf einer TLS-Verbindung können mehrere Verbindungstunnel hergestellt werden und jede Zelle ist über die Circuit-ID (Verbindungstunnel-ID) einem dieser Tunnel zugeordnet.

Aufbau einer Zelle

Controll Cells sind in grundsätzlich unverschlüsselt und werden hauptsächlich für den Verbindungsauf- und Abbau verwendet. Darüber hinaus gibt es ein Padding-Command, was bisher aber nur als Keep-Alive-Signal für Verbindungstunnel benutzt wird.

Relay Cells besitzen einen zusätzlichen Relay Header, der eine StreamID, Digest (Prüfsumme), Len (Payload-Länge) und CMD umfasst. Der gesamte Payload jeder Relay-Cell ( Relay-Header und Data) wird verschlüsselt (AES-128 Counter-Mode). Die TCP-Packete eines TCP-Streams werden innerhalb des TOR-Netzes auch durch Streams unterschieden. Über einen Verbindungstunnel können mehrere dieser Streams "laufen". Es gibt eine Reihe von Relay-Commands: Relay Begin/Connected, Relay Data, Relay End, Relay Teardown, Relay Extend/Extended, Relay Truncated. Im wesentlichen dienen die Kommandos zum Öffnen und Schließen von Streams, zur Weiterleitung von Packeten und zum Abbruch von Streams. Desweiteren wird über Relay Extend der Verbindungstunnel stückweise aufgebaut bzw. über Relay Teardown abgebrochen.

Verbindungstunnels und Streams

Im ursprünglichen Design des Onion Routings wurde für jeden TCP-Stream ein eigener Verbindungstunnel etabliert. Dadurch entstanden allerdings größere Latenzzeiten, da zum Zeitpunkt der Anfrage erst ein Verbindungstunnel über mehrere Knoten hergestellt werden musste, bevor überhaupt über den Kanal kommuniziert werden konnte. Ein weiteres Problem bestand darin, das der Exit-Node (End-Knoten des Verbindungstunnels) den gesammten TCP-Stream mithören konnte.

Das aktuelle Design lässt viele verschiedene Streams über einen Verbindungstunnel zu, wodurch die Latenzzeit verringert werden kann. Der Verbindungstunnel wird vorsorglich im Hintergrund schon bereitgehalten und sobald eine Anfrage stattfindet kann sofort kommuniziert werden. Zur Erschwerung der Nachvollziehbarkeit von Verbindungen wird der Verbindungstunnel öfters (die Angaben variieren von 1 Minute bis zu 10 Minuten) gewechselt.

Aufbau eines Verbindungstunnels und Anfrage einer Website

Aufbau eines Verbindungstunnels

1. OP baut Verbindungstunnel schrittweise auf durch aushandeln eines symmetrischen Schlüssels (Session-Key) mit jedem OR des Verbindungstunnels. (diffie-hellman-handshake)
2. create cell (von Alice) enthält die erste hälfte des Diffie-Hellman-Handshakes g^x1 verschlüsselt mit dem onion key (public key) von OR1
3. created cell (von OR1) enthält g^y1 und den Hash von K=g^x1y1
4. Schlüssel ist nun ausgehandelt. Jetzt können Alice und OR1 verschlüsselt relay cells austauschen.
5. Eigentlich wird der ausgehandelte Schlüssel K benutzt um 2 symmetrische Schlüssel (einen für jede Richtung) abzuleiten
6. Zum erweitern des Verbindungstunnels schickt Alice eine Relay-Extend-Cell, in der die Adresse des nächsten OR’s (OR2) steht, an OR1. Diese Zelle enthält auch wieder ein verschlüsseltes g^2 für den handshake mit OR2 (verschlüsselt mit OR2s „Onion Key“).
7. OR1 entschlüsselt die Relay-Extend-Cell, kopiert den halben Handshake g^x2 in eine create cell und schickt sie an OR2.
8. OR1 benutzt eine andere CirID C2 für die Verbindung zu OR2, welche Alice gar nicht kennen braucht. Nur OR1 macht ein mapping von C2 zur CircID der Verbindung zu Alice C1.
9. OR2 antwortet mit einer created cell die OR1 verschlüsselt und dann in eine extended cell umschreibt und an Alice weiterreicht.
10. Der Verbindungstunnel ist nun erweiter bis zu OR2.

Weiterleiten von Zellen

Verschlüsselungsschichten einer Zelle

1. Der Verbindungstunnel steht, Alice kann nun Relay Cells schicken.
2. Beim empfangen einer Relay Cell prüft jeder OR zu welcher Verbindung (CircID) die Zelle gehört.
3. Der OR entschlüsselt die Zelle mit dem Session-Key der entsprechenden Verbindung.
4. Nun wird die Prüfsumme untersucht. Sofern sie nicht mit der Prüfsumme des Payloads der Zelle übereinstimmt und der OR nicht der Exit-Node ist wird die Zelle einfach weitergegeben.
5. Wenn die Prüfsumme korrekt ist, so ist die letzte Verschlüsselungsschicht entfernt worden und der OR verarbeitet die Zelle so wie es im Relay Command steht.
6. Wenn die Prüfsumme nach dem letzten Entschlüsselungsschritt inkorrekt ist, so wird der gesamte Verbindungstunnel zur Sicherheit vor Manipulation der Zellen abgebrochen.

Öffnen von Streams

Wenn eine Anwendung von Alice eine TCP-Verbindung zu ein er bestimmten Adresse herstellen will wird die Anfrage zuerst an ihren Onion Proxy weitergegeben. Der OP wählt den aktuellsten Verbindungstunnel für die Kommunikation aus oder erstellt einen neuen Verbindungstunnel, falls keiner zur Verfügung steht. Nun bestimmt der OP einen OR des Verbindungstunnels als Exit-Knoten. In der Regel wird der Letzte Knoten des Verbindungstunnels dafür gewählt, es kann jedoch potenziell auch jeder andere Knoten gewählt werden, z.B. wegen Exit-Policies. Der Exit-Knoten verbindet sich nun mit dem Zielrechner und antwortet Alice mit einem Relay-Connected Command.

Von nun an kann der OP Daten vom TCP-Stream der Anwendung annehmen, sie in Relay-Data-Cells packen und (verschlüsselt) durch den Verbindungstunnel schicken.

Schließen von Streams

Das Schließen von Streams geschieht ähnlich wie bei TCP in 2 Schritten, bei Verbindungsabbruch in einem Schritt.# Alice schicht eine Relay-End-Cell an den Exit-Knoten und sofern der Stream normal beendet werden kann wird der Exit-Knoten eine Relay-Ended-Cell an Alice zurückschicken. Falls es Probleme bei der Verbindung gab schickt der benachbarte OR eine Relay-Tear-Down-Cell.

Quality of Service

Integrität von Streams

Tor ist verwundbar durch End-to-End timing Attacks. Diese Tatsache muss durch das Design als Low-Latency-Network hingenommen werden. Relay Cells enthalten eine Prüfsumem (Digest) welche genauso wenig resistent gegen End-to-End Attacken ist.

SHA-1 wird im TOR-Netzwerk als Hashfunktion benutzt und durch die Verschlüsselung des gesamten Payloads jeder Relay-Cell ist die Prüfsumme mitverschlüsselt. Aus diesem Grund kann die Integrität einer Zelle nur an den Enden des Verbindungstunnels sichergestellt werden. Um den Rechenaufwand für die Prüfsummen zu optimieren bestehen die ersten beiden Bytes von DIGEST aus Nullen. Durch die Verschlüsselung des Payloads genügt es nun, das jeder Onion Router zuerst prüft ob die ersten beiden Bytes von DIGEST Null sind, bevor die Daten erneut gehasht werden.

Bandbreitenbegrenzung (Rate Limiting) und Fairness

Die Regelung und Begrenzung der Bandbreite ist bei OR-Betreiber prinzipiell wünschenswert. Die Datenmenge die das TOR-Netzwerk verlässt ist ungefährt gleich der Input-Datenmenge in das TOR-Netzwerk. Dadurch genügt es den eingehenden Datenverkehr an jedem Onion Router zu beschränken.

Allerdings gibt es interaktive Streams, bei denen oft nur eine sehr kleine Anfrage geschickt wird und direkt die Antwort erwartet wird. In diesem Fall muss auch eine fast leere Zelle sofort losgeschickt werden um die Latenzzeit klein zu halten. Um interaktive Stream (z.B. ssh, Telnet) von den sogenannten Bulk-Streams, welche nicht ganz so zeitnah verarbeitet werden müssen, zu unterscheiden gibt es heuristische Ansätze. Hierbei versucht man durch Beobachtung der Häufigkeit, mit der Zellen von einem Stream bereitgestellt werden bestimmte Streams zu priorisieren. Abgesehen von den sowieso schon möglichen End-to-End Attacken entsteht durch diese Priorisierung keine weitere Einschränkung der Anonymität.

Datenfluss-Kontrolle (Congestion Controll)

Drosselung findet sowohl auf Verbindungstunnel-Ebene, als auch au Stream-Ebene statt. Jeder OR überwacht zwei Fenster nach denen sich entscheidet welche Aktivität der OR überhaupt ausübt.

packaging window: wieviele Relay-Data-Cells darf der OR packen (tcp-traffic von ausserhalb des TOR-Netzwerkes)

delivery window: wieviele Relay-Data-Cells darf der OR ausd TOR-Netzwerk nach Aussen weiterleiten

Diese Fenster werden zu Beginn mit einem Startwert (z.B 1000) initialisiert und bei jedem Packet der zuugehörige Wert dekrementiert. Sobald ein Wert bei Null angelangt ist stellt der OR die über das Fenster definierte Tätigkeit ein, bis sich der Wert wieder ändert.

Durch Relay-Sendme Zellen können die Fenster wieder aufgestockt werden. Ein OR schickt z.B ein Relay-Send-Me wenn er bereit ist weitere Daten von einem anderen OR anzunehmen.

Durch diesen Mechanismus werden Engpässe und Datenstau vermieden. Das Tor-Design sieht eine relativ Konservative Bemessung zugunsten der Betreiber von OR vor. D.h. Es wird der Schutz der OR-Betreiber vor die Performance des Netzwerkes gestellt.

Auf Stream-Ebene funktioniert die Datenfluss-Kontrolle prinzipiell genauso, jedoch auf End-to-End basis. Zusätzlich muss geprüft werden ob die Daten des TCP-Streams an den Endpunkten auch geflusht werden. Deshalb wird ein Relay-Sendme nur dann geschickt wenn nicht zuviele Bytes gerade auf einen Flush warten.

Rendezvous Points und Hidden Services

Versteckter Dienst durch TOR

Ziel der versteckten Dienste ist die Möglichkeit anonym Dienste bereitstellen- und nutzen zu können. Bobs Dienst wird durch einen Hash identifiziert und zusammen mit einer Liste von Introduction Points (IP) in einem Directory Server gespeichert. Bob signiert diese Dienstbeschreibung damit niemand einen Dienst als Bob's Dienst anbieten kann. Bob unterhält Verbindungen zu all den Introduction Point's die er angegeben hat.

Wenn Alice nun den Dienst von Bob nutzen möchte schaut sie im Directory Server nach, welche Introduction Point sie nutzen kann. Sie verbindet sich zu einem dieser Introduction Points und hinterlässt ein rendezvous-cookie sowie die Information welchen OR sie als Rendezvous Point (Treffpunkt) ausgesucht hat. Anschließend verbindet sich Alice mit dem Rendezvous Point und wartet dort auf Bob.

Falls Bob die Anfrage von Alice beantworten möchte verbindet er sich mit dem Rendezvous Point und kann Alice anhand dem Rendezvous-Cookie erkennen. Der Rendezvous-Point leitet nun Dtaen zwischen Alice und Bob weiter.

Exit Policies

Jeder Onion Router beschreibt in seiner Exit Policy zu welcher externen Adresse und welchen Ports sich der Router verbindet. Dabei unterschiedet man zwischen den folgenden Arten. Zum einen die Open Exit Nodes, die überall hin verbinden. Zum anderen die Middleman Nodes, die nur zu anderen TOR-Knoten verbinden. Desweiteren gibt es private Exit Nodes, die nur zu lokalen Rechnern oder dem lokalen Netzwerk verbinden. Die vierte Variante sind Restricted Exit Nodes, die am Häufigsten vorkommen. Sie ermöglichen die Verbindung nach außen, verhindern aber den Zugang zu gewissen, missbrauchsanfälligen Adressen und Diensten wie zum Beispiel SMTP. Diese Variante eignet sich sehr gut für den Administrator, weil er wählen kann welche Ports freigeschaltet werden und welche nicht. Fraglich ist jetzt, in welchem Verhältnis die verschiedenen Möglichkeiten angewandt werden sollten. Viele Middleman Nodes erstellen ein großes, robustes Netzwerk, aber wenn man nur wenig Exit Nodes hat, erleichtert man Angreifern auch die Überwachung des Datenverkehrs. Eine Mischung aus Open und Restricted Nodes erlaubt die größte Flexibilität für den Administrator.

Directory Servers

Directory Server sind ein zentraler Bestandteil des TOR-Netzwerkes. Es gibt nur wenige gut ausgewählte Onion Router, die als Directory Server (DS) genutzt werden. Sie verfolgen alle Änderungen in der Netz-Topologie und im Status von Knoten und bieten für alle Knoten und Proxies einen einfachen Look-up-Dienst an. Jeder Onion Router schickt periodisch signierte Statusinformationen an einen oder mehrere DS. Diese Informationen umfassen Exit-Policies, Schlüssel als auch Information über die Nachbarschaft des Onion Routers.

Jeder neue Onion Router muss von Hand von einem DS-Admin für diesen Vorgang zugelassen werden. Die Automatisierung dieser Zulassung unter Berücksichtigung der Sicherheit des Netzwerkes ist ein aktives Forschungsgebiet.

DS bilden aus allen vorhandenen Informationen einen signierten Descriptor. Dieser Descriptor stellt das Verzeichniss dar. Die Directory Server gleichen ihre Descriptoren untereinander ab und legen durch einen Mehrheitsentscheid fest wie der IST-Zustand des Netzwerkes aussieht.

Angriffe und Angriffsabwehr

Denial of Service

Da TOR ein öffentlicher Service ist, wird er natürlich auch gern für Angriffe genutzt. Vor allem Denial of Service-Attacken, also Attacken die zur Dienstverweigerung führen, finden hier Anwendung. So könnte ein Angreifer einen TLS Handshake antäuschen, was die CPU durch die verschiedenen Verschlüsselungsoperationen viel Zeit kostet. Dahingegen werden Angriffe, bei denen eine Vielzahl von UDP-Paketen gesendet werden, gut abgewehrt, da TOR nur korrekt geformte TCP-Streams transportiert und nicht beliebige IP-Pakete. Werden Hosts oder Links eines Streams erfolgreich angegriffen, geht der Dienst verloren. Man spricht dabei dann aber von sporadisch auftretenden Netzwerkfehlern.

Passive Angriffe

• Observing user traffic patterns: Durch das Beobachten der Verkehrsmuster eines Nutzers, wird zwar nicht die Herkunft oder die Daten erfahren, aber man kann Profile erstellen.
• Option distinguishability: Den Nutzern die Möglichkeit zu geben ihr Level an Sicherheit oder andere Einstellungen zu treffen, könnte bei gewissen Konfigurationen dazu führen, dass ein kleinerer Nutzerkreis entsteht und damit trotz höherer Sicherheitseinstellungen die Anonymität leidet.
• End-to-end timing correlation: Falls ein Angreifer den Datenverkehr beim Sender und Empfänger abhorcht, wird er durch die zeitliche Nähe der Pakete mit hoher Wahrscheinlichkeit herausfinden, dass die beiden Nutzer miteinander kommuniziert haben.

Aktive Angriffe

• Compromise keys: Sollte der Angreifer den Session Key herausfinden, kann er Kontrollzellen und verschlüsselte Relayzellen aller Verbindungstunnel dieser Verbindung sehen. Mit dem Session Key für den Verbindungstunnel, kann er dann eine Schicht entschlüsseln. Um diesen Verbindungstunnelschlüssel zu bekommen gibt es nun zwei Möglichkeiten:

1. Wenn der Verbindungstunnel bereits besteht muss der Angreifer den bereits ausgehandelten Session Key des Tunnels herausfinden. Da man aber vom Onion Key nicht auf diesen schließen kann, ist das sehr schwierig.
2. Wenn eine Anfrage für einen neuen Verbindungstunnel ankommt, benötigt der Angreifer den Onion Key um die create-Zelle zu entschlüsseln.

Man erkennt also, dass dies sehr aufwändig ist und darum auch als halbwegs sicher gilt.

• Replay attacks: Attacken, bei denen eine Wiederholung einer Seite des Handshakes ausgeführt wird, führt dazu, dass ein neuer Session Key vermittelt wird und somit die vorangehende Sitzung nicht entschlüsselt werden kann.

Directory Angriffe

• Subvert a majority of directory servers: Wenn ein Angreifer mehr als die Hälfte der directory server kontrolliert, kann er so viele von ihm kontrollierte Onion Router in das finale Verzeichnis einbinden wie er will. Darum sollten Betreiber von directory Servern besonders unabhängig und resistent gegen Attacken sein.

Angriffe auf Rendezvous Points

• Make many introduction requests: Da der Nutzer einstellen kann welchem Umfang die Anfragen an seinem Eingang haben dürfen, wird es dem Angreifer bei korrekten Einstellungen seitens des Nutzers kaum zu einem erfolgreichen überlaufen des Eingangspunktes kommen.

Fakten, Zahlen und Offene Fragen

Wie auf der Homepage von TOR zu lesen ist, sollte man immer daran denken, dass "... der Code in Entwicklung ist — daher ist es keine gute Idee, auf Tor zu vertrauen, wenn du wirklich starke Anonymität benötigst". Dies ist natürlich mit dem Design an sich zu begründen, da low-latency Systeme die weiter oben beschriebenen Probleme haben. Trotzdem weist TOR eine stets steigende Zahl von Knoten und Nutzern auf. TOR wird dabei für verschiedene Programme wie FTP, SSH, IRC oder E-Mailzustellungen genutzt. Allerdings steigt mit höherer Nutzerzahl auch die Gefahr, dass man einen langsamen Verbidungstunnel erwischt, weil einer der beteiligten Knoten über eine begrenzte bzw. ausgelastete Bandbreite verfügt.

So ergeben sich für das Design und die Nutzer einige Fragen.

1. Wie oft sollte der Verbindungstunnel seine Route aktualisieren?
   Wechselt man die Route zu oft, verliert man an Performance. Wechselt man zu selten, steigt das Sicherheitsrisiko.
2. Wie lang sollte der Pfad sein?
   Mindestens 3 Knoten sind nötig, damit man auch wirklich anonym unterwegs ist. Aber erhöhen noch mehr Knoten auch die Anonymität?
3. Sollte man versuchen end-to-end Attacken abzuwehren?
   Dies ist ein sehr schmaler Grat zwischen mehr Sicherheit und weniger Performance, der pauschal nicht zu beantworten ist.
4. Ist es sinnvoll wenn jeder Nutzer seinen eigenen Onion Router laufen lässt?
   Falls jeder Nutzer seinen eigenen Onion Router laufen lässt, könnte man nicht mehr unterscheiden, ob die Daten die an diesem Punkt durchgesetzt werden von ihm oder jemand anderem sind. Andererseits könnten Nutzer mit geringer Bandbreite langsame Verbindungstunnel erzeugen.

Zukunft und Ausblick

Einige Punkte könnten in Zukunft noch diskutiert werden. Diese betreffen vorwiegend das Design.

1. Scalability
   Da das Design recht einfach und flexibel gehalten werden soll, kommt es zu Problemen bei wachsender Nutzerzahl. Vielleicht muss man das Design dadurch grundlegend ändern.
2. Bandwidth classes
   Nutzer sollten möglicherweise ihre Bandbreite angeben, um den Flaschenhalseffekt bei manchen Verbindungen zu vermeiden.
3. Incentives
   Nutzer könnten durch höhere Anonymität oder andere Sachen dazu angeregt werden einen eigenen Knoten laufen zu lassen. Möglichweise skaliert dadurch das ganze System und wird dadurch noch reizvoller für neue Nutzer.

Quellen

Tor: The Second-Generation Onion Router (2004), Roger Dingledine, Nick Mathewson, Paul Syverson ([[1]])