tor – the onion router

Christoph Biedlcbiedl@cis.fu­berlin.de

18. 30. Mai 2006

tor

Anonymisierung von Netzwerkverbindungen “low­latency” Nur TCP, nur einfache Client­Server­Verbindungen

Es geht: HTTP, NNTP, POP3 usw. Es geht nicht: FTP, VoIP

tor

Entwicklung/Finanzierung Ältere Projekte ab 2000 2002 bis 2004 United States Naval Research Laboratory mit 

Unterstützung des Office of Naval Research (ONR) und der Defense Advanced Research Projects Agency (DARPA)

2004/2005 Electronic Frontier Foundation (EFF) Seitdem: Spenden :­)

Nutzung von tor

“tor” ist ein Netzwerke von Knoten (“node”, “onion router” [OR]), die den Datenverkehr verschlüsselt weiterleiten.

Ein Client muß installiert werden (open source, für alle gängigen Betriebssysteme verfügbar).

Der Client agiert als socks­Proxy. Anwendungsprogramm muß socks­fähig sein oder 

socksifiziert werden (tsocks).

Nutzung von tor

Liste der nodes besorgen

Nutzung von tor

“Circuit” aufbauen

Optimierung: Circuit wird für einige Zeit gehalten.

Interna – Konstruktion des “curcuit”

Client (OP) wählt eine Route zum exit node aus, d.h. OP–OR1–OR2–OR3.

Aufbau einer verschlüsselten Verbindung OP­OR1 (DH). Aufbau einer verschlüsslten Verbindung OP­OR2 durch 

OR1, OP­OR1 wird doppelt verschlüsselt. Und so weiter. Jeder OR kennt nur nur seine Nachbarn.

Konzepte zur Absicherung

Crypto bis der Arzt kommt. node list vom directory server ist signiert. node­node: Authentifizierung mit private/public key. node­node: Symmetrische Verschlüsselung der 

transportierten Daten. Checksum über die Payload.

Betrieb eines “nodes”

Ausgerichtet auf Betrieb durch viele Freiwillige mit wenig Ressourcen: rate limiting. Abschaltung propagiert sich schnell. Dynamische IP ist kein ernsthaftes Problem. Betrieb hinter NAT ist möglich mit DNAT auf dem Router. Reines Userland, root­Rechte nicht nötig. exit policy für Zugriffsbeschränkungen. “transit” (oder “middleman”) node

Nutzung (Client)

Sehr simpel. Client macht alles von selber, aber man kann eingreifen. Client ist kein node.

“hidden server”

Ein “hidden server” steht irgendwo im tor­Netzwerk. Adressierung über TLD .onion, z.B.

http://6sxoyfb3h2nvok2d.onion Protokollvariante “rendevouz” für den Zugriff.

Probleme (für den Nutzer)

d.h. ungewollter Verlust der Privatsphäre

Speziell WebbrowserVerknüpfung von Seitenabrufen durch User­Agent Cookies Mobiler Code (JavaScript)

Abhilfe: Features abschalten, lokaler filternder Proxy (privoxy)

Probleme (für den Nutzer)

Allgemein DNS­Leaking (Lösung: Eigener Resolver über tor, oder 

Socks 4a). IP­Übermittlung im Protokoll (z.B. IRC­DCC). Sniffer auf dem exit node.

Probleme (für den node­Admin)

Traffic. Verantwortung(?) ­ aber zumindest Ärger. “Has anyone ever been sued for running Tor?” ­ “No.” Speziell DMCA: “safe harbour”

http://tor.eff.org/eff/tor­dmca­response.html

Probleme (für den Rest der Welt)

Mißbrauch von Anonymität. Ausnutzung der Erreichbarkeit von Diensten. Bestimmte Ports sollten auf dem exit node eigentlich immer 

gesperrt sein, sind es aber nicht.

Probleme (für den Provider)

Zugriff auf IP­authentifizierte Dienste des Providers, z.B. Newsserver.

tor nodes sind im Campus­Netz wohl nicht akzeptabel: “transit nodes” machen nur traffic. “exit nodes” erlauben Dritten Zugriff mit Rechten von FU­IP­

Nummern: Newsserver, Bibliotheksrecherche etc.

(Anekdote “clueless”, exit node in Erlangen)

Links

tor allgemeinhttp://tor.eff.org/http://de.wikipedia.org/wiki/Tor_(Netzwerk)

Designhttp://tor.eff.org/cvs/tor/doc/design­paper/tor­design.html 

Liste der exit nodeshttp://serifos.eecs.harvard.edu/cgi­bin/exit.pl