Sicher surfen mit dem Tor-Browser

Datenschutz
1

Seit ca. 10 Jahren surfe ich fast ausschließlich mit dem Tor-Browser. Ich benutze diesen auch, um mich an ausgewählten Accounts anzumelden, bzw. einzuloggen.

In der Vergangenheit habe ich deswegen (vor allem wegen der Gefahr von Bad Exits) die entsprechende Konfigurations-Datei im Tor-Browser so modifiziert, dass ausschließlich festgelegte, mir vertrauenswürdig erscheinende Exit Nodes benutzt wurden.

Mittlerweile jedoch ist eine „StrictNodes 1“-Anweisung in der torrc nicht mehr möglich. Oder anders, besser gesagt: Diese wird vom Tor-Browser nicht mehr konsequent umgesetzt.

Das bedeutet, dass der Tor-Browser (entgegen den Empfehlungen von Mike seinerzeit ) im Ergebnis Exit Nodes neuerdings nach Belieben auswählt, um Verbindungenn auf jeden Fall zustande zu bringen - obwohl in der torrc Anderes (vermeintlich sicher) festgelegt wurde.

Das halte ich für ein Sicherheitsrisiko, zumal, wenn man sich als user/in darauf verlässt.

Andererseits ist das Tor-Browser-Bundle mittlerweile auch so default-konfiguriert, dass jegliche Nicht-HTTPS-Verbindungen für user/innen unübersehbar gemeldet werden.

Dennoch wäre eine eigene und halbwegs beständige, sowie diesbezüglich zuverlässig funktionierende Editierung der torrc wünschenswert, insofern, dass der Tor-Browser auch zuverlässig das macht, wozu er via torrc angewiesen wurde.

Dass dies nicht mehr so zu sein scheint, schwächt mein Vertrauen in diese eigentlich wunderbare Technologie des digitalen Zwiebel-Daseins.

-Gibt es diesbezüglich Erfahrungen, Hinweise oder Tipps Eurerseits?..

Danke!
:slight_smile:
leeti

2

Beim TOR-Browser bzw. TOR-Netzwerk ist man allgemein überhaupt nicht mehr anonym.
Die ganzen Exit Nodes laufen größtenteils über das FBI, BKA usw.
Ich würde dieses Protokoll nicht mehr nutzen und stattdessen auf das I2P-Protokoll setzen.

1.) Persönlich nutze ich es aber auch nicht, da ich für meine Bandbreite monatlich zahle und diese nutzen möchte.

2.) mir die gehärteten Browser und ein paar Tweaks ausreichen.

3

Gibt es dafür auch Beweise bzw. Hintergrundinfos? Die Aussage einfach so stehen zu lassen, erscheint mir nicht richtig.

Vielleicht hat sich die Syntax geändert bzw. die Befehlsform.

In meiner torrc (unter TorBrowser/Data/Tor/) habe ich bei mir aktuell Folgendes vermerkt:
[…]

ExitNodes {de}
StrictNodes 1

Das passt soweit ich das sehe.

Hier gibt es weitere Infos: https://support.torproject.org/#tbb-editing-torrc

4 „Gefällt mir“
4

Vielen Dank.

Ich habe die Erfahrung gemacht, dass die Anweisung

StrictNodes 1

teilweise wirkungslos ist, bzw. ignoriert wird, wenn der Tor-Browser auf einen ganz bestimmten ExitNode festgelegt wurde.

Ist dieser Knoten nicht erreichbar, wird (wie eine Art fallback) die Verbindung über einen beliebigen Knoten hergestellt. Das leider zunächst unbemerkt für NutzerInnen (es sei denn, man lässt sich z.B. über Klick auf das Schlosssymbol die gewählte Route anzeigen; dazu gibt es aber, wie gesagt, keinerlei Meldung/Aufforderung durch den Tor-Browser).

Dieses Verhalten des Tor-Browsers könnte man auch als Vorrang von Konnektivität vor Sicherheit bezeichnen. Ich denke, dass es gerade beim Tor-Browser IMMER umdreht sein müsste.

Im Tor Manual wird dieses Verhalten - etwas umwunden - auch beschrieben:

StrictNodes* 0|**1
If StrictNodes is set to 1, Tor will treat solely the ExcludeNodes option as a requirement to follow for all the circuits you generate, even if doing so will break functionality for you (StrictNodes applies to neither ExcludeExitNodes nor to ExitNodes, nor to MiddleNodes). If StrictNodes is set to 0, Tor will still try to avoid nodes in the ExcludeNodes list, but it will err on the side of avoiding unexpected errors. Specifically, StrictNodes 0 tells Tor that it is okay to use an excluded node when it is necessary to perform relay reachability self-tests, connect to a hidden service, provide a hidden service to a client, fulfill a .exit request, upload directory information, or download directory information. (Default: 0)

https://2019.www.torproject.org/docs/tor-manual.html.en
(Strg+F „StrictNodes“; 3. Übereinstimmung)

Dort steht also, dass die Bedingung „StrictNodes 1“ nur bei ExcludeNodes berücksichtigt (und ausdrücklich NICHT bei ExitNodes).

Im Umkehrschluss bedeutet das, dass man zwar sicher festlegen kann, welche Nodes man NICHT benutzen möchte, aber nicht sicher festlegen kann, welche benutzt werden sollen.
Möchte man also sicherheitshalber ausschließlich eine Handvoll oder gar nur einen einzigen, ganz bestimmten Node als Exit nutzen, müsste man zuvor ALLE (7k?) anderen ausschließen…

5

Das Sicherheitsrisiko bist Du alleine. Du verlässt Dich blind auf die 5 Jahre alte Empfehlung vom Mike ohne zu hinterfragen, ob das heute immer noch alles state of art ist.
StrictNodes gilt seit 2 jahren nicht mehr für ExitNodes. Wenn „StrictNodes“ auf 1 gesetzt ist, wird Tor nur die Option „ExcludeNodes“ als Bedingung für alle deine hops verwenden.
Neue Config ist: „ExitNodes Fingerprint1, Fingerprint2“ usw.

Ergänzung

Mit den folgenden Befehlen kann überprüft werden ob die Einstellungen in der Torc funktionieren

torsocks curl ipinfo.io/
torsocks curl ipinfo.io/country

1 „Gefällt mir“
6

Die neue Syntax sieht dann wie folgt aus (wenn du explizite Exits angeben willst), am Beispiel von Digitalcourage Exit-Nodes:

ExitNodes 97F51AF6791AD33981CE25DC7A2618429F25B3B0, BB034C34ED9E60F7709ED93FB432A9BA12A2F2B6, […]

Nein, sogar schon fast 10 Jahre alt. Hier ist der Eintrag: https://www.kuketz-blog.de/warnung-vor-dem-onion-pi-tor-proxy/ :wink:

3 „Gefällt mir“
7

Ich würde das Thema gerne besser verstehen. Und vielleicht hat ja noch jemand anderes dieselbe Frage: Von welchem vermeintlichen Sicherheitsrisiko reden wir hier eigentlich?

Ich sehe keins.

8

Snowden-Dokumente belegen, dass Geheimdienste einen Teil der Relays bzw. der Exit Nodes betreiben. Dingledine (Mitbegründer vom Tor-Projekt) kennt aber auch angeblich zwei Drittel der Betreiber von Exit Nodes persönlich. Wenn ich jetzt Paranoid wäre würde ich behaupten das es min. 33% Bad Exit Nodes gibt. Bin ich Realist gehe ich davon aus das es max 20% Bad Exit Nodes gibt. Einem Bad Exit Nodes begegne ich nie wenn ich auf Onion-Diensten unterwegs bin,
Bin ich auf https unterwegs, könnte meinen Datenverkehr mitzulesen werden und meine Logins könnten leaken, FALLS die Transportverschlüsselung schwach ist. Andere Aktuelle Angriffe, die die Privatsphäre von Tor Nutzern bei Bad Exit Nodes gefährden, sind mir nicht bekannt.

11

Das Sicherheitsrisiko besteht aus meiner Sicht hierbei darin, dass sich das Prinzip „Konnektivität vor Sicherheit“ in eine Funktion des Tor-Browsers eingeschlichen hat.

Die Option „StrictNodes 1“ als Anweisung in der torrc beinhaltete mal, dass aufgeführte Entry-, Middel- und ExitNodes durch den Tor-Browser AUSSCHLIESSLICH zu benutzen sind, um einen Circuit aufzubauen.

Das gab NutzerInnen z.B. die (relative) Sicherheit, dass ihr Tor-Browser nur einen (oder mehrere) ExitNode(s) ihres Vertrauens benutzt. Das ist insbesondere dann relevant, wenn man sich mit dem Tor-Browser unter Verwendung entsprechend sensibler Daten (Benutzername/Passwort) bei einem Account einloggt (z.B. bei seinem E-Mail-Provider).

Die ExitNodes sind eine sensible Stelle im Circuit, da dort der zuvor mehrfach, zwiebelschalenartig verschlüsselte Netzwerkverkehr wieder entschlüsselt wird. Schiebt der Betreiber des ExitNodes dem Datenverkehr bspw. ein gefälschtes Verschlüsselungszertifikat unter, gelingt es ihm unter Umständen, den Netzwerkverkehr zu entschlüsseln und sensible Nutzerdaten abzugreifen (Man-In-The-Middle-Attacke). Da im Tornetzwerk nicht nur Datenschutzenthusiasten oder altruistische Idealisten unterwegs sind und Nodes betreiben, sondern auch kriminelle Organisationen, Geheimdienste und Ermittlungsbehörden, ist diese Bedrohung real (Bad Exits). Schutz davor bot die eindeutige Festlegung des ExitNodes des Vertrauens durch die Option StrictNodes 1.

Besonders für eine (immer wieder geforderte) Vorratsdatenspeicherung ist diese (ehemalige) Funktion wichtig. Hierbei ist die anonymisierende Wirkung des Tor-Browser quasi nicht „nach vorn“ gerichtet (also Anonymität gegenüber der Webseite), sondern es sichert eine Anonymität „nach hinten“, also z.B. gegenüber dem „Freundeskreis VDS“. Denn bspw. sieht mein ISP in solchem Fall lediglich meine Rücklichter im Tor-Netz verschwinden, weiß aber nicht, dass ich meinen E-Mail-Account angesurft habe.

Dass diese Funktion gewissermaßen geräuschlos verschwunden ist (warum eigentlich?), wiegt NutzerInnen in falscher Sicherheit. Das halte ich für ein ziemliches Risiko.

Das halte ich für richtig.

Ich gebe zu bedenken: Aber nicht alle Seiten, wo man es brauchen könnte, betreiben Onion-Dienste (bspw. bei E-Mail-Providern bleibt da nicht viel übrig).

Vielen Dank.

Das ist mir alles bekannt. Jedoch löst es das von mir beschriebene Problem nicht, dass bestimmte ExitNodes nun nicht mehr AUSSCHLIESSLICH benutzt werden.

Ich frage mich, warum diese Funktion nicht mehr vorhanden ist (und wage kaum, mir selbst darauf zu antworten - weil ich gerne weiter glauben will, dass der Tor-Browser ein hervorragendes, sicheres Instrument ist, um eine relative Anonymität im Netz zu wahren).

1 „Gefällt mir“
12

Es funktioniert noch, einfach „StrictNodes1“ in der Torc weglassen. Siehe Mikes Antwort.

13

Ich habe (auch natürlich unter Beachtung der neuen, geltenden Syntax) leider andere Erfahrungen machen müssen (das der/die gewählte/n Exit/s nicht AUSSCHLIESSLICH benutzt werden: Kann - aus irgendwelchen Gründen - keine entsprechende Verbindung hergestellt werden, ignoriert der Tor-Browser diese torrc-Anweisung und stellt eine Verbindung über einen zufällig gewählten Knoten als Exit her. Genau so steht es auch im oben verlinkten Manual - wenn dort auch leicht verschwurbelt).

1 „Gefällt mir“
14

1 Exit alleine funktioniert auch nicht, es müssen schon mehrere sein.
„ExitNodes Fingerprint1, Fingerprint2,“ genau so nach diesem schema, ohne StrictNodes.

1 „Gefällt mir“
15

StrictNodes 1 sorgte seinerzeit dafür, dass der/die in der torrc festegelegten Exits AUSSCHLIESSLICH benutzt wurden. War das nicht möglich (aus irgendwelchen Gründen), kam kein Circuit/keine Verbindung zustande. Dies unabhängig davon, ob lediglich ein oder mehrere Exits festgelegt wurden (wobei bei nur einem Exit die Wahrscheinlichkeit eines Scheiterns der Verbindung natürlich höher ist, mehrere festgelegte Exits heutzutage jedoch nicht garantieren, dass diese auch AUSSCHLIESSLICH benutzt werden - noch mal: das ist auch die offizielle Version des Tor-Projekts - siehe Handbuch, s.o. - und deckt sich mit meinen Erfahrungen).

Danke & Gute Nacht einstweilen.

16

Zum Bedrohungsszenario gehören meiner Kenntnis nach nicht nur, das BadExits sich in den Netzwerkverkehr einklinken können, wenn kein oder veraltetes TLS o.ä. verwendet wird.

Das Problem ist auch, dass wenn ein Thread Actor genügend Eingangs- und Ausgangs-Nodes betreibt er darüber in der Lage ist den Verkehr auf Paketebene zu korrelieren und so einzelne Nutzer zu deanonymisieren.

Vermutlich ist das dem FBI einmal in einer konzentrierten Aktion gelungen (auch wenn ich den Link dazu nicht finde), hier ein paar Links zu der Problemstellung:

ieee.org

thesecmaster.com

17

Nur als Anmerkung:
Die Beschränkung auf bestimmte exit nodes birgt Gefahren. Wenn das zu wenige sind (wie oben im Beispiel) macht das den Nutzer mit ziemlicher Wahrscheinlichkeit unique und erleichtert außerdem die De-Anonymisierung.

1 „Gefällt mir“
19

Auch noch mal, Du verlässt Dich schon wieder blind auf 1. Quelle.
Auch die offizielle Version des Tor-Projekts ist nicht aktuell und vollständig.

This website is an online archive and it’s outdated!
Some resources you will find here are outdated. We are currently working on a new developer portal.
https://2019.www.torproject.org/docs/documentation.html.en

Ist auch wenig realistisch bis unmöglich. Da Roger zum einem 2/3 der betreiber persönlich kennt. (was nicht berücksichtigt wurde)
und zum anderen gibt es mittlerweile 2 Eingansknoten die alle paar minuten wechseln.
https://forum.torproject.net/t/tor-relays-were-trying-out-guard-n-primary-guards-to-use-2/3790/1

Somit ist dieses threat model heute schon wieder unrealistisch.

21

Das Verhalten des Tor-Browsers unter den oben beschriebenen Bedingungen entspricht exakt dem, was im Manual steht, „outdated“ hin oder her.
Du kannst es ja einfach mal selbst ausprobieren.

Was hast Du denn für Quellen diesbezüglich?

Hi, danke für den Hinweis. Wenn Du noch mal die betreffenden Stellen in meinen Posts liest, wird Du vielleicht bemerken, dass der Zweck eines via torrc dergestalt konfigurierten Tor-Browsers nicht zuvorderst darin besteht, gegenüber einer angesurften Webseite seine (digitale) Anonymität zu wahren (was ja auch wenig Sinn ergibt, wenn man sich damit irgendwo einloggt, denn dann geht es ja gerade darum sich - digital - zu authentisieren/zu authentifizieren).

22

Die Gefahr der „De-Anonymisierung“ bezieht sich nicht auf die angesurfte Webseite, sondern auf alle, die unterwegs möglicherweise mitlauschen. Wenn Dich Anonymität nicht interessiert, ist das natürlich egal, aber warum dann überhaupt Tor?

1 „Gefällt mir“
23

das angeblich irgendjemand persönlich kennt - finde ich schwierig. Außerdem ist das eine Frage der Wahrscheinlichkeit (siehe Link). Das Tor-Netz muss wachsen und dann ist das schwierig alle Netzbetreiber zu kennen.

https://www.schneier.com/blog/archives/2021/12/someone-is-running-lots-of-tor-relays.html

25

Hi ilu,

natürlich geht es um Anonymität. Diese kann ich, soweit ich das verstehe, via Tor grundsätzlich in zwei Richtungen betreiben, bzw. herstellen: gegenüber den angesurften Adressen, „nach vorne“ also und gegenüber - falls ich mich mit Tor z.B. einloggen möchte - bspw. meinem ISP bei drohender VDS („nach hinten“ gewissermaßen also; am besten ist natürlich die Kombination aus Beidem - was aber, möchte man Tor z.B. dafür nutzen, sich irgendwo mit sensiblen persönlichen Daten einzuloggen, so ausgewogen nicht zu bewerkstelligen ist: man benötigt ExitNodes seines Vertrauens dafür, welche dann AUSSCHLIESSLICH benutzt werden, was leider neuerdings durch die Unwirksamkeit der torrc-Bedingung „StrictNodes 1“ für ExitNodes nicht möglich zu sein scheint). Unterwegs baue ich auf die Verschlüsselung. Dass ein MiddelNode diese kompromittieren kann oder konnte, ist mir aber bislang noch nicht bekannt geworden. Wenn Du mehr Valides (bitte keine Gerüchte) weißt darüber und belegen kannst, her damit.

Was Schneier da schreibt/zitiert/beschreibt, ist ziemlich krass und gibt mir sehr zu denken (mögliche Gegenmaßnahme: Routen/Circuits via Entry-/Middle- und ExitNodes explizit festzulegen - was jedoch eben nur dann geht, wenn diese torrc-Editierungen AUSSCHLIESSLICH (etwa durch die Bedingung „StriktNodes 1“ - was ja leider & m.E., bzw. meiner Erfahrung nach so nicht mehr zu funktionieren scheint) befolgt werden vom Tor-Browser.