Systems Architecture Tor: The Second-Generation Onion Router Afschin Hormozdiary, Eric Redlin

2 May Systems Architecture Gliederung  Worum geht es?  Bezug zu anderen Projekten  TOR-Design - Design-Ziele - Threat-Modell - Zellen - Verbindungstunnel und Streams - Quality of service - Rendezvous Points und Hidden Services  Other design decisions  Angriffe und Verteidigung  Erste Erfahrungen und offene Fragen  Zukunft und Ausblick

3 May Systems Architecture Worum geht es? Geschichte:  basierend auf der originalen Idee des Onion Routing entwickelt (Zwiebelprinzip)  TOR ist die Weiterentwicklung (von Freehaven unterstützt)  Verbesserungen: - Implementation von perfect forward secrecy - Nutzung von SOCKS proxy interface - mehrere Streams durch einen Verbindungstunnel - Leaky-pipe circuit topology - Congestion Control - Directory Server, variable Exit policies, Rendezvous Points... Problem:  Analyse des Datenverkehrs (Internetüberwachung) - Welche Kommunikationspartner? - Welcher Inhalt?

4 May Systems Architecture Worum geht es? Ziele:  Risiko der Verkehrsanalyse verringern  Web-Browsing anonymisieren und damit die Anonymität der Nutzer gewährleisten

5 May Systems Architecture Bezug zu anderen Projekten  Bezieht sich auf Chaum's Mix-Net Design - High-latency: - Babel, Mixmaster - Maximale Anonymität durch große, variable Latenzen bei der Datenübermittlung - Low-latency - Nutzbar für interaktive Verbindungen (SSH, IRC) - Dafür weniger Anonymität (end-to-end-Attacken) - Wird aber in Kauf genommen, da anwenderfreundlicher  TOR gehört zu low-latency Design

6 May Systems Architecture TOR-Design: Goals and Non-goals  Grundsätzliches Ziel: Anonymität der Kommunikationspartner  Weitere Ziele, die durch das Design realisiert werden: - Anwendbarkeit - Nicht zu viel Bandbreite des Nutzers beanspruchen - Bei illegalen Nutzungen durch Angreifer sollte der Nutzer nicht haftbar gemacht werden können - Einfache Installation (keine Kernel-Patches oder versch. Proxies) - Benutzbarkeit - Schwer zu benutzen → wenig Nutzer → geringe Anonymität -Darum: low-latency, auf allen Plattformen installierbar -Flexibilität -Flexibles und gut spezifizertes Protokoll -Einfaches Design -Einfaches Verständnis fördert die Erweiterbarkeit

7 May Systems Architecture TOR-Design: Goals and Non-goals  Non-goals: -unzureichend oder nicht existente Lösungen für Probleme werden nicht berücksichtigt -Kein Peer-to-Peer -Keine Sicherheit gegen end-to-end-Attacken -Zu hoher Aufwand bei low-latency -Keine Protokollnormalisierung -Anonymität des Antwortenden bei komplexen Protokollen -Keine Steganografie -TOR versucht nicht zu verstecken wer im Netz ist, sondern wer mit wem kommuniziert

8 May Systems Architecture TOR-Design: Threat-Modell  TOR schützt nicht gegen globale passive Angriffe (wie andere low-latency Designs auch nicht)  Angriffe folgender Art werden erwartet: - Teile des Netzwerkverkehrs beobachten - Netzwerkverkehr erzeugen, modifizieren, löschen, verzögern - Kontrolle über Onion Router übernehmen - Teile eines Onion Router gefährden - Kommunikation von Sender und Empfänger vergleichen - Timing und Volumen der Datenpakete vergleichen (passiv) - Timing Signaturen einführen um Unterschiede deutlicher zu machen (aktiv)  TOR versucht die Analyse des Verkehrs zu verhindern

9 May Systems Architecture Tor-Design  Tor kann ausschließlich TCP-Streams verarbeiten.  Jeder Benutzer betreibt einen Onion Proxy (OP) oder auch einen Onion Router (OR)  Jeder OR hat 2 Schlüssel: -Identity Key -Signierung von TLS-Zertifikaten und OR-Descriptoren -Onion Key: -Entschlüsselung von Anfragen anderer Benutzer -Herstellung von Verbindungenstunnels -Aushandlung von Sitzungsschlüsseln  Das TLS-Protokoll benutzt einen kurzlebigen link-key für die Kommunikation zwischen OR’s

10 May Systems Architecture Zellen  Grundlegende Transporteinheit mit fester Länge (512 bytes)  Header 3 Bytes -CircID -1 Byte Zelltyp  2 verschiedene Zelltypen -Controll Cell -Relay Cell  Mehrere Verbindungstunnel(CircID) können die gleiche TLS-Verbindung benutzen  CircID ist Verbindungsspezifisch, d.h. jede Teilstrecke eines Verbindungstunnels hat eine andere CircID

11 May Systems Architecture Zellen (Controll Cell)  Controll Cell -Unverschlüsselt -Padding (Keep-Alive-Signal) -Create (neuen Verbindungstunnel aufbauen) -Destroy (Verbindungstunnel abbrechen)

12 May Systems Architecture Zellen (Relay Cell)  Relay Cell -Zusätzlicher Relay-Header am Anfang des Payloads -Verschlüsselter Payload (AES-128 Counter-Mode) -Ein Verbindungstunnel, mehrere Streams (StreamID) -End-to-End Integritätsprüfung (Digest mit SHA-1) -Len: Länge des Payloads -CMD: Relay Begin/Connected, Relay Data, Relay End, Relay Teardown, Relay Extend/Extended, Relay Truncate

13 May Systems Architecture Verbindungstunnels und Streams  Ursprünglich: Für jeden TCP-Stream eigener Tunnel -Große Latenz durch Verbindungsaufbau -Exit-Node sieht Stream von Anfang bis Ende  Jetzt: Viele Streams über einen Verbindungstunnel -Dafür öfterer Wechsel des Tunnels (minütlich) -Verbindungstunnel wird vorsorglich schon im Hintergrund hergestellt, nicht erst bei einer Anfrage (fehler beim Verbinden beeinträchtigt nicht den Nutzer) -Verbindung wird schrittweise Aufgebaut, durch aushandeln von Session-Key's mit jedem einzelnen OR

14 May Systems Architecture Verbindungstunnel (cont.)

15 May Systems Architecture Relay Cells  Verbindungstunnel steht, Alice kann nun Relay Cells schicken  Beim empfangen einer Relay Cell prüft der OR zu welcher Verbindung (CircID) die Zelle gehört  Entschlüsselung der Zelle mit Session-Key der Verbindung  Prüfsumme (digest) prüfen  Prüfsumme korrekt: OR nimmt die Zelle an (Relay Command ausführen)  Prüfsumme inkorrekt: Die Zelle unverschlüsselt weiterleiten zum nächsten OR  Der nächste OR verfährt genauso, entschlüsselt eine weitere schicht etc…  OP’s arbeiten genauso  Wenn Prüfsumme nach letzter Entschlüsselung inkorrekt: Abbruch des Verbindungstunnels

16 May Systems Architecture Öffnen von Streams  Anwendung von Alice will TCP-Verbindung zu bestimmter Adresse und Port: Anfrage geht an OP weiter.  OP wählt aktuellsten Verbindungstunnel.  OP bestimmt Exit-Knoten (in der Regel der letzte OR des Tunnels)  OP eröffnet Stream durch Senden einer Relay-Begin-Cell an den Exit-Knoten (EK). StreamID zufällig gewählt.  EK verbindet zum Zielrechner und antwortet Alice mit Relay-Connected-Cell.  OP kann jetzt Daten vom TCP-Stream der Anwendung annehmen, sie in Relay-Data-Cells packen und durch den Verbindungstunnel schicken.

17 May Systems Architecture Schließen von Streams  Schließen des Streams geschieht in 2 Schritten, bei Abbruch in einem Schritt.  Alice schickt Relay-End-Cell an EK, wenn der Stream normal beendet wird schickt EK eine Relay-Ended-Cell zurück, sonst schickt der benachbarte OR eine Relay Tear Down Cell.

18 May Systems Architecture Integrität von Streams  Tor ist Verwundbar durch End-to-End timing Attacks.  Tor benutzt SHA-1 als Hashfunktion.  Hashes werden nur an den Tunnelenden erfolgreich geprüft.  Hashes sind mitverschlüsselt, daher besteht nicht die Möglichkeit nach Kollisionen zu suchen

19 May Systems Architecture Rate Limiting und Fairness  Begrenzung der Bandbreite bei OR-Betreibern wünschenswert.  Nur Eingehender Verkehr wird in der Praxis beschränkt, da ein- und ausgehender Datenverkehr ungefähr gleichen Umfang haben.  Bei kleinen anfragen mit wenigen Bytes kann manchmal nicht gewartet werden bis die Zelle voll ist, daher wird sie u.u auch halbleer losgeschickt.  Es gibt heuristische Ansätze um interaktive Streams von anderen (bulk) zu unterscheiden durch Beobachtung der Häufigkeit, mit der ein Stream Zellen bereitstellt.  Gute Latenzzeiten für interaktive Streams werden durch bevorzugte Behandlung dieser Zellen erreicht.  Abgesehen von End-to-End attacken entsteht dadurch keine weiter Bedrohung.

20 May Systems Architecture Congestion Controll  Drosselung auf Ebene des Verbindungstunnels: -Jeder OR behält 2 Fenster im Auge: -„packaging window“: wieviele Relay-Data-Cells kann der OR packen (tcp-traffic von aussen) -“delivery window”: wieviele Relay-Data-Cells kann der OR aus dem TOR-Netz heraus weiterleiten -Bsp.: Beide windows Wenn Packete weitergeleitet oder gepackt werden wird dekrementiert. -Mit Relay-Sendme können windows wieder aufgestockt werden. -OR schickt Relay-Sendme-Cell's wenn er weitere Daten empfangen kann -wenn window=0, dann werden keine Cells mehr verarbeitet

21 May Systems Architecture Congestion Controll  Drosselung auf Ebene der Streams: -funktioniert ähnlich, jedoch auf end-to-end basis. -es muss zusätzlich geschaut werden ob die daten in den TCP-Stream geflusht werden. -Ein Relay sendme wird nur dann geschickt, wenn nicht zuviele Bytes gerade auf einen Flush warten.

22 May Systems Architecture Hidden Services & Rendezvous Points  Ermöglicht anonyme Bereitstellung und Nutzung von Diensten  Bob's Dienst wird durch Hash identifiziert und zusammen mit den Introduction Points (IP) in einem Directory Server gespeichert  Bob hält Verbindungen zu seinen IP's  Will Alice verbinden: suchen eines IP im Directory Server anhand des Hashes  Sie schickt dem IP ein rendezvous-cookie und info's welchen OR sie als Rendezvous-Point gewählt hat, danach verbindet sie sich dorthin und wartet auf Bob

23 May Systems Architecture Hidden Services & Rendezvous Points (cont.)  Wenn auch Bob mit Alice sprechen will: Aufbau eines Verbindungstunnels zum Rendezvous-Point  Alice hat dort auf ihn gewartet  Rendezvous-Point leitet nun Daten zwischen Alice und Bob weiter

24 May Systems Architecture Directory Servers  Wenige ausgewählte OR's sind Directory Server (DS) (  Verfolgen alle Änderungen in der Netz-Topologie und im Status von Knoten  Einfacher Look-Up Dienst  OR's schicken periodisch signierte Infos an DS -Info's über OR: Exit-Policies, Key und mehr -Info's über die Lage zu den anderen DS's  OR muss manuell vom Admin eines DS zugelassen werden  DS bilden aus allen vorhandenen Informationen signierten Descriptor (stellt das verzeichniss dar)  Abgleich der DS untereinander und Abstimmung über IST-Zustand  Hidden Services werden im DS nach hashwert indiziert

25 May Systems Architecture Other design decisions  Exit policies and abuse -Jeder Onion Router beschreibt in seiner Exit policy zu welchen externen Adressen und Ports er verbindet -Open exit nodes (verbinden überall hin) -Middleman nodes (verbinden nur zu anderen ORs) -Private exit nodes (verbinden nur zum lokalen Rechner oder Netzwerk) -Restricted exit nodes (verbinden nur zu erlaubten Diensten wie HTTP, SSH) -Richtige Mischung zu finden ist schwer -Mix aus open und restricted exit nodes bringt Flexibilität für den Nutzer -Viele middleman nodes führen zu einem großen, robusten Netzwerk -Wenig exit nodes erleichtern Angreifern das abhören

26 May Systems Architecture Angriffe und Verteidigung  Denial of Service - TLS handshake antäuschen → CPU wegen Verschlüsselungs- operationen ausgelastet - Hosts oder Links angreifen → Nutzer verliert seinen Stream -Typische DoS-Attacken mit UDP-Paketen sind jedoch nicht erfolgreich, da TOR nur korrekt geformte TCP-Streams transportiert

27 May Systems Architecture Angriffe und Verteidigung  Passive Angriffe - Observing user traffic patterns - Enthüllt Verkehrsmuster und erlaubt somit Profiling - Option distinguishability - Lässt Nutzerkreis schrumpfen und bietet damit weniger Anonymität - end-to-end timing correlation - Führt mit hoher Wahrscheinlichkeit zum Erkennen der Kommunikationspartner  Aktive Angriffe - Compromise Keys - Relativ sicher, da der Angreifer einige Keys erlernen müsste - Replay attacks - Sicher, denn bei erneutem handshake wird anderer session key vermittelt

28 May Systems Architecture Angriffe und Verteidigung  Directory Angriffe - Übernahme eines Directory Servers - Ob ein Onion Router gelistet ist oder nicht wird ja durch Mehrheitsentscheid aller Directory Server bestimmt. - Dadurch hat der Übernommene DS einen gewissen Einfluss durch seine Stimme - Übernahme der Mehrheit aller Directory Server - Wenn mehr als die Hälfte der Server kontrolliert werden können, so lassen sich beliebig neue OR in die Liste aufnehmen (durch den Angreifer), durch den Mehrheitsentscheid aller Directory Server  Angriffe auf Rendezvous points - Make many introduction requests - Bob kann den Umfang von gültigen Anfragen einstellen

29 May Systems Architecture Erste Erfahrungen und offene Fragen  Stand Mitte Mai Knoten, einige Hundert Nutzer - Langsam wachsende Nutzerzahl ermöglicht schrittweises erweitern und verbessern von TOR - Kein Missbrauch bekannt seit Oktober Latency vom Netzwerk und der congestion control abhängig - Mehr Nutzer → höhere Wahrscheinlichkeit eines langsamen Tunnels  Offene Fragen -Wie oft sollte sich der Verbindungstunnel aktualisieren? -Wie lang sollte der Verbindungstunnel eigentlich sein? -Sollte man versuchen end-to-end Angriffe abzuwehren? - Sollte man einen einen OR laufen lassen? - Bringen mehr Knoten auch mehr Sicherheit?

30 May Systems Architecture Zukunft und Ausblick  TOR ist bereits relativ innovativ, aber kann natürlich noch weiterentwickelt werden - Scalability - Probleme mit vielen Nutzern durch Einfachheit und Anwendbarkeit - Klassen von Bandbreiten - Knoten sollten einstellen können, über welche Bandbreite sie vefügen - Anreiz - Belohnung der Nutzer die Knoten laufen lassen „Jan 2007: Das Tor Netzwerk ist auf Hunderttausende von Nutzern gewachsen. Die Entwickler können nicht alle neuen Features, Fehlerbehebungen, und die ganze Dokumentation alleine machen. Wir brauchen deine Hilfe!“

31 May Systems Architecture References  Tor: The Second-Generation Onion Router (2004), Roger Dingledine, Nick Mathewson, Paul Syverson  Homepage des Projects:     Spezifikation-Directory-Server:  Umfangreiche FAQ zum Thema:  Informationen zu Clock-Skew Analysen:  Diffi-Hellman-Handshake: