Anonymisierende Proxies: Chaum, JAP/JonDo und Tor

Auch wenn Alice Cache und Cookies regelmäßig löscht, ist ihr Internet-Provider immer noch in der Lage, ihre gesamte Kommunikation zu überwachen, und ihre Kommunikationsdaten weiterzugeben. Um dies zu verhindern, muss Alice kryptographische Verfahren anwenden, mit deren Hilfe sie verbirgt, mit wem sie kommuniziert.

Ein einfaches, aber auch ungenügendes Verfahren besteht in der Konfiguration einer einzelnen anonymisierenden Zwischenstation, ↑Proxy oder Mix genannt (technisch evtl. auch ein VPN-Server), dem Alice ihre Kommunikationsdaten verschlüsselt zusendet, damit dieser sie an den eigentlichen Adressaten weiterleitet und dessen Antworten verschlüsselt an sie zurücksendet. Der Internet-Provider sieht dann nur noch Alice' verschlüsselte Kommunikation mit dem Proxy. Dieses Verfahren ist ungenügend, weil nun anstelle des Internet-Providers der Proxy vollständiges Wissen über Alice' Kommunikation erlangt. Was er mit diesem Wissen macht, ist nicht klar. (Löschen oder Verkaufen sind zwei Extreme…)

Die Kernidee besserer Verfahren besteht darin, Nachrichten aufgeteilt in mehrfach verschlüsselte Pakete gleicher Größe über eine Kette mehrerer Proxies, idealerweise zeitlich verzögert und umgeordnet, zum eigentlichen Kommunikationspartner weiterzuleiten. Die Beobachtung von Alice' Kommunikation wird dann nur zeigen, dass ihre Kommunikation verschlüsselt mit einem von ihr gewählten Proxy stattfindet, vorzugsweise im nichteuropäischen Ausland: der eigentliche Adressat bleibt verborgen. Die wegweisende Grundlagenarbeit dieser Verfahren ist bereits 1981 von David Chaum unter dem Titel ↑„Untraceable electronic mail, return addresses, and digital pseudonyms“ veröffentlicht worden.

Heute existieren für E-Mail, Web, Tauschbörsen und allgemeine TCP/IP-Verbindungen frei verfügbare und einfach zu benutzende Software-Lösungen, die Anonymität basierend auf frei zugänglichen Netzen von Proxy-Servern bieten. Im Folgenden wird kurz auf ↑JAP/↑JonDo und ↑Tor zum anonymisierten Web-Surfen eingegangen, bevor danach mit ↑Mixminion ein Projekt für anonyme E-Mail-Kommunikation vorgestellt wird. Bei allen diesen Verfahren bleibt zumindest dem Internet-Provider verborgen, mit wem Alice kommuniziert, und der Gesprächspartner (z. B. der Suchmaschinenbetreiber im Internet) erfährt nicht, dass es Alice ist, mit der er kommuniziert (aus seiner Sicht findet die Kommunikation mit dem letzten Proxy statt). Darüber hinaus gibt es keine einzelne Stelle mehr, der Alice ihre gesamte Kommunikation anvertrauen müsste.

Jedes dieser Anonymisierungsprojekte befindet sich in der Entwicklung. Keines dieser Projekte behauptet von sich, Anonymität zu garantieren. Auch ich behaupte das nicht! Ich halte es aber für besser, ein Verfahren in Entwicklung einzusetzen, das bekannte (z. B. ↑Angriffe auf JAP und ↑Angriffe auf Tor) und unbekannte Schwachstellen hat, als gar nichts zu tun. Es gibt nichts zu verlieren! (Na ja, sagen wir fast nichts: Das Surfen über mehrere Zwischenstationen wird durch Erhöhung von Latenzzeiten und Verminderung von Bandbreite langsamer…)

Magie? Fehlanzeige… Ich möchte hier keine Einführung in Internet-Sicherheit geben, aber ich möchte zumindest erwähnen, dass es gängige Internet-Protokolle gibt, die niemand verwenden sollte. Erst recht niemand mit Sorge um informationelle Selbstbestimmung. Dies sind insbesondere POP und IMAP zum Lesen von E-Mail, NNTP zum Lesen von News-Beiträgen und, falls eine Authentifizierung erforderlich ist, auch HTTP beim Web-Surfen sowie FTP zum Dateitransfer. Bei all diesen Protokollen werden sämtliche Daten im Klartext übertragen, insbesondere Benutzerkennung und Passwort. Das bedeutet, dass alle Rechner, z. B. beteiligte Router, auf dem Weg vom eigenen Rechner bis zum Zielserver sämtliche Nachrichten mitlesen (auch nach Belieben unbemerkbar manipulieren) und dabei Passwörter ausfiltern können. Nach einmaligem Login darf man seine Kennung als kompromittiert ansehen. Vor dieser Gefahr schützt auch keines der im Folgenden beschriebenen Anonymisierungsverfahren. Das Gegenteil kann der Fall sein: Bei Verwendung der folgenden Verfahren werden die eigenen Daten über zusätzliche Wege und Zwischenstationen, die von unbekannten Parteien mit unbekannten Motiven kontrolliert werden, weitergeleitet. Es sollte klar sein, dass die eigenen Daten dabei auch in die dunkelsten Ecken im Internet geraten könnten.

Um sich sicher durch diese dunklen Ecken bewegen zu können, vertrauen Alice und Bob auf starke Kryptographie und verwenden nicht obige Klartextprotokolle sondern deren durch ↑SSL/TLS abgesicherten Varianten (POPS, IMAPS, NNTPS, HTTPS, SFTP). (Und sie machen Server-Betreiber, die nur unsichere Klartextvarianten anbieten, aber deren Dienste sie trotzdem für wertvoll halten, darauf aufmerksam, dass Klartextprotokolle keine gute Idee sind. Obwohl Klartextprotokolle Alice und Bob erlauben abzustreiten, etwas mit den unter ihren Kennungen durchgeführten Aktionen zu tun zu haben…)

Weiterhin beachten Alice und Bob SSL/TLS-Warnungen über ↑Zertifikate unbekannter Aussteller (siehe oben) und brechen dann die Verbindung ab — es sein denn, sie wissen, was sie tun. (Beispielsweise, wenn sie eine Web-Seite ansehen wollen, ohne persönlichen Daten oder gar Passwörter einzugeben.) Andernfalls werden sie vermutlich Opfer eines ↑Man-In-The-Middle-Angriffs.

Wenn Alice und Bob eines der folgenden Anonymisierungsverfahren verwenden, sind sie bei Warnungen der obigen Form besonders vorsichtig, weil dann insbesondere die letzte zur Anonymisierung gedachte Zwischenstation von einem Angreifer betrieben werde könnte, der Kennungen/Passwörter/PIN/TAN trotz SSL/TLS-Verschlüsselung abfängt. Wer Tor verwendet, konnte im August 2006 ↑diesem Link folgen, um zu sehen, wie so ein Angriff aus Sicht des Opfers aussieht. (Der beteiligte Tor-Router ist leider (?) nicht mehr aktiv, so dass der Link nicht mehr funktioniert.)

Zum Hintergrund: In obigem Link-Ziel ↑https://meine.deutsche-bank.de.1.exit/mod/WebObjects/dbpbc.woa endet der Domänenname auf 1.exit, was Tor anweist, den unter dem Namen 1 bekannten Tor-Router als letzte Zwischenstation zu verwenden, um auf ↑https://meine.deutsche-bank.de/mod/WebObjects/dbpbc.woa zuzugreifen.

Wer der Angreifer war und welche Ziele er/sie verfolgte, ist nicht klar. Der Tor-Router mit dem Namen 1 hatte jedenfalls die IP-Adresse 218.58.6.159 und stand in China (autonomes System AS4837). Möglich wäre zum einen, dass der Man-In-The-Middle den Tor-Router betrieb und versuchte, Tor-Nutzern fingierte Zertifikate unterzuschieben, um Kennungen/Passwörter/PIN/TAN abzufangen. Zum anderen könnte es auch sein, dass der Tor-Router bereits Opfer eines Man-In-The-Middle-Angriffes war und die ihm untergeschobenen fingierten Zertifikate nur an Tor-Benutzer weiterleitete. (↑Gerüchten zufolge könnte Letzteres eine breiter angelegte Strategie sein, um die Verschlüsselung von SSL/TLS de fakto auszuschalten und so chinesische Surfer effektiv überwachen zu können.)

Wem nicht so richtig klar ist, worüber ich hier schreibe, sollte evtl. zunächst nachlesen, was ↑asymmetrische Kryptographie ist, die die Grundlage von SSL/TLS darstellt, sich dann vergewissern, was eine ↑digitale Signatur ist und schließlich versuchen zu verstehen, wie ↑Public-Key-Infrastrukturen (PKI) genutzt werden, um die Gültigkeit beteiligter Schlüssel durch ↑digitale Zertifikate zu verifizieren. (Ich schreibe „verstehen zu versuchen“, weil PKI im Browser eigentlich nicht funktioniert, da es für alle Beteiligten zu kompliziert ist: Selbst namhafte Aussteller wie ↑VeriSign und ↑Equifax, deren Zertifikaten alle Browser „vertrauen“, machen Fehler…)