Tor Onion Router schützt den Datenverkehr auch gegen Angriffe potenter Geheimdienste wie die NSA. Es ist nach dem aktuellen Stand der Technik nahezu unmöglich, die Verschlüsselung mathematisch zubrechen und Nutzer anhand des Datenfluss zu deanonymisieren.
Angriffe zur Deanonymisierung von Tor Nutzern konzentrieren sich daher üblicherweise auf die Client Anwendung (z. B. den Webbrowser). In mehreren bekannten Fällen wurde durch Ausnutzung von Security Bugs im TorBrowser ein kleiner Trojaner auf dem Rechner von Zielpersonen installiert, der IP- und MAC-Adressen des Rechners ermittelt und an einen Server des Angreifers sendet.
Das FBI verwendete dafür mehrere Jahre den Magneto Trojaner (bzw. CIPAV), der auf Webseiten platziert wurde und nach Infektion des Systems via TorBrowser die Daten an einen Server der "Science Applications International Cooperation" sendet, die u.a. mit dem FBI kooperiert.
Der Server des Hidden Hosting Projektes Freedom Hosting wurde vom FBI in Frankreich lokalisiert und ein direkter Zugriff in Kooperation mit dem Datacenter vor Ort eingrichtet.
Der Magneto Trojaner wurde in mehrere Onion Sites eingebaut und die Besucher damit deanonymisiert. Neben hundert Webangeboten mit kinderpornografischem Material waren auch der E-Mail Service TorMail und die Bitcoin Börse OnionBank betroffen (2013).
Wenn hohe Anforderungen an die Sicherheit gestellt werden, muss die Verschlüsselung des Datenverkehrs mit dem Tor Onion Router (oder mit einem I2P Daemon) in einer Umgebung erfolgen, die von der/den Arbeitsumgebungen mit den Internet Anwendungen getrennt ist.
Die Arbeitsumgebung stellt die Anwendungen wie TorBrowser, E-Mail Client, Messenger usw. dem Nutzer zur Verfügung. Es sind mehere Arbeitsumgebungen möglich.
In den Arbeitsumgebungen wird für Anwendungen, für die Verbindungen ins Internet zulässig sind, sowie für System Updates ein SOCKS5 Proxy konfiguriert (Proxy: Tor Daemon). Es wird aber KEIN globaler Proxy gesetzt, um unerwünschte Verbindungen zu vermeiden.
Der Tor Daemon ist als Tor Relay Node (non-Exit) konfiguriert mit limitierter Bandbreite (für Cover Traffic) und verschlüsselt alle Daten, die aus dem Trusted LAN kommen und ins Internet fließen sollen. Aus den Arbeitsumgebungen gibt es keinen Weg daran vorbei.
Ein kleines Konfigurationsbeispiel mit den Optionen für einen non-Exit Tor Node:
# Tor Client für Arbeitsumgebungen
SocksPort <Trusted-LAN-IP>:9050
# Tor Relay für Cover Traffic
Address <IP> oder <DynDNS>
Nickname <frei wählbar>
ORPort 9001
DirPort 9030
ExitPolicy reject *:*
# Limits für Bandbreite (anpassen)
RelayBandwidthRate 500 KB
RelayBandwidthBurst 800 KB
AccountingMax 1024 GB
AccountingStart month 1 00:00
ContactInfo Max Mustermann <max@mustermann.tld>
Wenn man beim Angreifermodell davon ausgeht, dass die Arbeitsumgebungen kompromittiert werden könnten, darf man den Arbeitsumgebungen keinen Zugriff auf den TorControlPort geben (nur SocksPorts!). Es gibt einige Control-Kommandos, die die Anonymität gefährden.
Zur Vereinfachung der Tor Administration könnte man den ControlPort lokal freischalten:
# für lokale Admin-Tools
ControlPort 127.0.0.1:9051
CookieAuthentication 1
CookieAuthFile /var/lib/tor/control_auth_cookie
CookieAuthFileGroupReadable 1
DataDirectoryGroupReadable 1
StreamIsolation ist ein weiteres Sicherheitsfeature, das man konfigurieren kann. Für Internet Anwendungen mit Login Kennung werden mehrere SocksPorts zur Verfügung gestellt. Der Traffic für diese Ports wird isoliert und über unterschiedliche Routen durch das Tor Netz geleitet, um eine Deanonymisierung durch Korrelationen zu vermeiden.
# SocksPort mit StreamIsolation
SocksPort <Trusted-LAN-IP>:9101 IsolateDestAddr IsolateDestPort
SocksPort <Trusted-LAN-IP>:9102 IsolateDestAddr IsolateDestPort
SocksPort <Trusted-LAN-IP>:9111 IsolateDestAddr
SocksPort <Trusted-LAN-IP>:9112 IsolateDestAddr
Für den TorBowser wird StreamIsolation NICHT empfohlen, aber
Thunderbird könnte z. B. SocksPort 9101 verwenden, ein Messenger SocksPort 9111, wget den SocksPort 9112…
Wenn eine Arbeitsumgebung kompromittiert wird, kann der Angreifer nur eine IP-Adresse aus einem privaten Netzwerkbereich ermittlen und den Nutzer damit nicht deanonymiseren.
(Möglicherweise könnte er mit einem Trojaner zur Online-Durchsuchung persönliche Daten wie Kontonummern oder Kreditkarten finden, die zur Deanonymisierung führen können? Darüber muss man selbst nachdenken!)
Auch die beste Technik kann nicht vor Fehlern beim eigenen Verhalten schützen. So wurde Ross Ulbricht 2011 als Betreiber des Darknet Markplatzes "Silk Road" identifiziert, weil er in einem Forum Werbung für sein Projekt postete und dabei eine Bitcoin Adresse angab. Durch Analyse der Blockchain wurden weitere Bitcoin Adressen ermittelt, die zu einer Bitcoin Börse führten, wo er eine GMail Adresse mit seinem realen Namen angegeben hatte. (Das ist die offizielle Version des FBI.)
(Schon wieder so ein schmutziges Beispiel aus der Presse, falls jemand ein paar besser Beispiele kennt…)
Warum ist Cover Traffic sinnvoll? Ein Besipiel: Es gab einen Studenten, der eine Bombendrohung per E-Mail an seine Universität sendete. Der "Sender-IP" im Header E-Mail verwies auf einen Tor Exit Node. Das Log des zentralen HTTP-Proxy der Universität zeigt nur eine Verbindung ins Tor Netzwerk, die aus der Bibliothek der Universität kam. In der Bibliothek nutzte zum fraglichen Zeitpunkt nur ein Student das Uni-Netz - FAIL. Die Ermittlung dauerte nur wenige Stunden.