Wann ist ein Tor-Server nicht vertrauenswürdig?
Der Anonymisierungsdienst Tor ist so aufgebaut, dass jeder einen Server aufsetzen und Daten für andere weiterleiten kann. Einige kommen auf die schlechte Idee, den Verkehr mitzuschneiden. Da Tor-Nutzer sich manchmal bei unverschlüsselten Seiten anmelden, erhält der Betreiber des Tor-Servers in dem Fall die Login-Informationen. Dan Egerstad war einer dieser Leute.
Die Entwickler hinter dem Tor-Projekt, genauer die Betreiber der Verzeichnisserver, versuchen, schadhaftes Verhalten zu erkennen und den Server dann im Netzwerk zu sperren. Hierfür wird der Server als BadExit markiert. In der Folge darf der Server nur noch internen Verkehr weiterleiten.
Doch wie erkennt man, ob jemand wirklich die Inhalte mitschneidet? Wo ist die Grenze zwischen falscher Konfiguration und Böswilligkeit? Eine Frage, die sich schwer beantworten lässt und gleichzeitig auf der Mailingliste des Projekts hohe Wellen schlug.
Am Anfang stand die Frage „Is “gatereloaded” a Bad Exit?“ und im Verlauf der Diskussion wurden verschiedene Standpunkte diskutiert. Der Tor-Server gatereloaded lässt ausgehenden Verkehr nur für bestimmte Ports zu. Üblicherweise wird über diese (FTP, HTTP, POP3) im Klartext kommuniziert. Weiterhin ist es üblich, über diese Ports auch Login-Informationen zu senden. Das sind also ideale Bedingungen für einen Schnüffler. Gleichzeitig sind in den Informationen zum Server keine oder falsche Kontaktinformationen hinterlegt. Es gibt also keine Möglichkeit, sich mit dem Betreiber über die Sache auszutauschen.
Nach einiger Diskussion wurde der und andere Router in die Liste mit nicht vertrauenswürdigen Routern eingetragen. Einige Menschen auf der Mailingliste protestierten. Denn zum einen wollten sie nicht, dass irgendjemand diktiert, wer welche Ports erlaubt und zum anderen wurde durch die „Schließung“ angeblich mehr Last auf die anderen Server gelegt. Schließlich kam das Killerargument, dass ja jeder Verkehr mitschneiden könne.
Ich halte die Entscheidung der Admins der Verzeichnisserver für richtig und nachvollziehbar. Denn, wie sie später erklärten, läuft der Algorithmus ungefähr wie folgt:
- Suche nach verdächtigen ExitPolicys.
- Hat der Betreiber Kontaktinformationen gesetzt?
- Falls ja, wird der Betreiber kontaktiert und um Auskunft gebeten bzw. über die „falsche“ Policy aufgeklärt. Wenn er die Policy anpasst bzw. eine gute Erklärung für seine Entscheidung liefert, ist alles in Ordnung. Antwortet er nicht, dann wird der Server als BadExit markiert.
- Falls keine Kontaktinformationen angegeben sind, wird der Server als BadExit markiert.
In Abhängigkeit vom Einzelfall kann der Weg natürlich auch anders aussehen. Aber auf jeden Fall wird nicht blind versucht, irgendwelche Server, die Einzelpersonen nicht passen, auszuschalten. Sondern vielmehr versuchen die Personen wenig invasiv vorzugehen und einvernehmliche Lösungen zu finden.
In der Zwischenzeit kontaktierte einer der Administratoren der gesperrten Server das Tor-Projekt und erklärte, dass ihm die Formulierung der ExitPolicys zu schwierig war. Daher hat er einige naheliegende Ports freigegeben. Das Tor-Projekt klärte denjenigen auf, er änderte seine Einstellungen und nun ist er kein BadExit mehr.
Ich frage mich jetzt, warum der Admin Kontakt aufgenommen hat. Nach meiner Meinung/Erfahrung dürfte der durchlaufende Datenverkehr gleich geblieben sein. Denn er kann immer noch Daten innerhalb des Netzwerks weiterleiten. Also müsste dieser Fakt rausfallen. Weiterhin halte ich es für einen normalen Betreiber eines Servers für unerheblich, ob nun Verkehr nach außen geht oder innerhalb des Netzes bleibt. Momentan mag mir nur ein Grund einfallen: Der Scanner, mit dem Daten mitgeschnitten wurden, blieb leer. Was also liegt näher, als nach dem Grund zu fragen? Vielleicht ist meine Phantasie zu eingeschränkt und es gibt noch einen anderen plausiblen Grund. Meine torrc hat auf jeden Fall einen Eintrag mehr für die Option ExcludeExitNodes.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
morphium on :
Aber selbst wenn er ExitNode gewesen wäre, fände ich die Entscheidung mehr als kritisch. Es steht einfach niemandem zu, zu entscheiden, welche Ports gut und welche böse sind. Wer unverschlüsselt Daten übers Internet, insbes. Tor schickt, muss immer damit rechnen, dass sie mitgeschnitten werden.
Die größte Ironie an der ganzen Geschichte für mich konkret ist jedoch, dass ich nicht ge-bad-exit-ed werde, nachdem ich - aus Protest auf die unangemessene Diktatur - nur noch unverschlüsselte Ports auf meinem Tor Exit Node erlaube.
Wer sagt dass ich nicht mitschneide?
Du solltest auch meinen Node in deine ExcludeExitNodes schreiben - sowie jeden anderen Tor Exit Node, der Port 80 erlaubt - denn er könnte ja mitschneiden.
Schade, dass keiner die politische Tragweite solch einer Entscheidung versteht.
morphium
Jens Kubieziel on :
Wie auf der Mailingliste auch geschrieben wurde, geht es nicht darum die Sicherheit (vor was?) zu erhöhen. Vielmehr soll ein Signal gesetzt werden. Das Scannen nach problematischen ExitPolicys ist nur ein Bestandteil. Gleichzeitig versuchen die Entwickler ja ansätze zu finden bzw. auszubauen, wie man Sniffer erkennt. Solch ein Ansatz erhöht dann in der Tat die Wahrscheinlichkeit, unbeobachtet zu kommunizieren. Wobei der Angreifer immer noch tausendundeine andere Möglichkeit hat.
Bei den Ports stellt sich die Frage, warum jemand unbedingt nur Port 21, 80 und 110 durchlässt und alles andere sperrt. Darüber laufen nunmal zu großen Teilen Login-Informationen im Klartext. Also ist das wie gemacht für einen Sniffer.
Aus meiner Sicht geht es hier nicht nur darum, ob ein Port gut oder böse ist, sondern um das Verhalten des Admins. Mit einem funktionierenden Kontakt und einer guten Erklärung wäre vermutlich nichts passiert. Das BadExiten ist für das Tor-Projekt die einzige Möglichkeit, mit dem Admin zu „kommunizieren“.
Ich glaube, du hast mit deiner Diskussion auf der ML einfach zuviel Vertrauen aufgebaut.
Im Allgemeinen ist die Beurteilung nach Ports eine sehr grobe und damit fehleranfällige Maßnahme. Bei den genannten Relays kamen einfach diverse Punkte zusammen, die einen Verdacht nähren.
Insgesamt, da stimme ich dir zu, muss man die Entwicklung im Auge behalten. Sobald sich der Wind dreht und wirklich Ports nach einem Schema gut/böse ohne weitere Anhaltspunkte beurteilt werden, ist Protest angesagt. Derzeit sehe ich aber eher, dass die Entscheidungen überlegt und unter Abwägung diverser Vor-/Nachteile getroffen werden.
binfalse on :
Außerdem versteh ich nicht, warum man keine oder falsche Kontaktinformationen angeben sollte. Vielleicht sollten irgendwelche ExitNode-Policies eingeführt werden, so dass eine funktionierende Kontaktmöglichkeit eine notwendige Bedingung ist!
Statt nach Schnüfflern Ausschau zu halten, finde ich es viel wichtiger alle aufzuklären! Auch der letzte Tor-Nutzer sollte wissen, dass unverschlüsselte Protokolle weiterhin (wahrscheinlich durch Tor noch eher) mitgelesen werden! Wer Tor für seine IMAP-Authentifizierung nutzt handelt natürlich grob fahrlässig und erreicht nur, dass der Mailprovider nicht weiß woher der auth kommt.