Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Alwin Neumann Geändert vor über 7 Jahren
1
Systems Architecture http://sar.informatik.hu-berlin.de Tor: The Second-Generation Onion Router Afschin Hormozdiary, Eric Redlin 17.7.2007
2
2 May 2006 - 2 Systems Architecture http://sar.informatik.hu-berlin.de 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
3 May 2006 - 3 Systems Architecture http://sar.informatik.hu-berlin.de 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
4 May 2006 - 4 Systems Architecture http://sar.informatik.hu-berlin.de Worum geht es? Ziele: Risiko der Verkehrsanalyse verringern Web-Browsing anonymisieren und damit die Anonymität der Nutzer gewährleisten
5
5 May 2006 - 5 Systems Architecture http://sar.informatik.hu-berlin.de 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
6 May 2006 - 6 Systems Architecture http://sar.informatik.hu-berlin.de 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
7 May 2006 - 7 Systems Architecture http://sar.informatik.hu-berlin.de 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
8 May 2006 - 8 Systems Architecture http://sar.informatik.hu-berlin.de 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
9 May 2006 - 9 Systems Architecture http://sar.informatik.hu-berlin.de 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
10 May 2006 - 10 Systems Architecture http://sar.informatik.hu-berlin.de 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
11 May 2006 - 11 Systems Architecture http://sar.informatik.hu-berlin.de Zellen (Controll Cell) Controll Cell -Unverschlüsselt -Padding (Keep-Alive-Signal) -Create (neuen Verbindungstunnel aufbauen) -Destroy (Verbindungstunnel abbrechen)
12
12 May 2006 - 12 Systems Architecture http://sar.informatik.hu-berlin.de 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
13 May 2006 - 13 Systems Architecture http://sar.informatik.hu-berlin.de 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
14 May 2006 - 14 Systems Architecture http://sar.informatik.hu-berlin.de Verbindungstunnel (cont.)
15
15 May 2006 - 15 Systems Architecture http://sar.informatik.hu-berlin.de 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
16 May 2006 - 16 Systems Architecture http://sar.informatik.hu-berlin.de Ö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
17 May 2006 - 17 Systems Architecture http://sar.informatik.hu-berlin.de 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
18 May 2006 - 18 Systems Architecture http://sar.informatik.hu-berlin.de 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
19 May 2006 - 19 Systems Architecture http://sar.informatik.hu-berlin.de 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
20 May 2006 - 20 Systems Architecture http://sar.informatik.hu-berlin.de 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 1000 -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
21 May 2006 - 21 Systems Architecture http://sar.informatik.hu-berlin.de 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
22 May 2006 - 22 Systems Architecture http://sar.informatik.hu-berlin.de 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
23 May 2006 - 23 Systems Architecture http://sar.informatik.hu-berlin.de 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
24 May 2006 - 24 Systems Architecture http://sar.informatik.hu-berlin.de 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
25 May 2006 - 25 Systems Architecture http://sar.informatik.hu-berlin.de 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
26 May 2006 - 26 Systems Architecture http://sar.informatik.hu-berlin.de 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
27 May 2006 - 27 Systems Architecture http://sar.informatik.hu-berlin.de 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
28 May 2006 - 28 Systems Architecture http://sar.informatik.hu-berlin.de 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
29 May 2006 - 29 Systems Architecture http://sar.informatik.hu-berlin.de Erste Erfahrungen und offene Fragen Stand Mitte Mai 2004 - 32 Knoten, einige Hundert Nutzer - Langsam wachsende Nutzerzahl ermöglicht schrittweises erweitern und verbessern von TOR - Kein Missbrauch bekannt seit Oktober 2003 - 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
30 May 2006 - 30 Systems Architecture http://sar.informatik.hu-berlin.de 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
31 May 2006 - 31 Systems Architecture http://sar.informatik.hu-berlin.de References Tor: The Second-Generation Onion Router (2004), Roger Dingledine, Nick Mathewson, Paul Syverson Homepage des Projects: http://tor.eff.org/index.html.dehttp://tor.eff.org/index.html.de http://de.wikipedia.org/wiki/Denial_of_Service http://de.wikipedia.org/wiki/Denial_of_Service http://de.wikipedia.org/wiki/Onion_Routing http://de.wikipedia.org/wiki/Onion_Routing http://de.wikipedia.org/wiki/Tor_%28Netzwerk%29 http://de.wikipedia.org/wiki/Tor_%28Netzwerk%29 Spezifikation-Directory-Server: http://tor.blingblingsquad.net/svn/trunk/doc/spec/dir-spec.txthttp://tor.blingblingsquad.net/svn/trunk/doc/spec/dir-spec.txt Umfangreiche FAQ zum Thema: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQhttp://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ Informationen zu Clock-Skew Analysen: http://hp.kairaven.de/bigb/asurf.html#a92http://hp.kairaven.de/bigb/asurf.html#a92 Diffi-Hellman-Handshake: http://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustauschhttp://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.