Tor over VPN

Kann mir jemand bei meinem Anliegen behilflich sein ?

Ich würde gerne Tor over VPN nutzen.
Tor würde ich gerne als Proxy nutzen, damit mein gesamter Traffic durch Tor geroutet wird.
( nicht nur Browser )

Das ganze sollte dann so aussehen:
VPN → Tor → Internet

Muss ich dafür den Socks + Port von Tor im VPN eintragen ?
Oder kann ich den Socks + Port einfach im Betriebssystem eintragen ?
Oder muss ich es bei beiden eintragen ?

wäre die route nicht eigentlich:

vpn client → tor client → isp → vpn server → tor node → internet

dann ergeben sich die einträge für socks und port doch automatisch ;–)

Am besten geht sowas mit Tails oder Whonix. Falls du aber nicht extra ein OS nutzen möchtest, kannst du es mal mit sowas wie https://github.com/BlackArch/torctl versuchen auch wenn das nun schon länger nicht aktualisiert wurde.

Für Windows gäbe es noch das hier:
https://reqrypt.org/tallow.html

ABER soweit ich es gesehen habe, ist die Tor Version veraltet. Da müsstest du dir von der Tor Seite dieses Tor Expert Bundle laden und schauen, ob du manuell auf die neueste Tor Version kommst.

Generell muss man aber noch anmerken, dass du durch Tor keinen UDP Traffic tunneln kannst. Es geht ausschließlich TCP Traffic. Musst halt je nach Anwendung schauen ob das so für dich passt.

Kann man nicht einfach den Tor-Browser laufen lassen und die Proxy von Tor in den Interneteinstellungen eintragen ?

Tallow funktioniert doch ähnlich, nur das es veraltet ist.

verstehe nicht ganz was du meinst.
Im Netz steht halt, dass man Tor als Proxy nutzen sollte um den kompletten Traffic über Tor zu routen.

Probiere es doch mal aus :slight_smile: Aber ja das könnte funktionieren. Bin mir zwar nicht ganz sicher, was du mit „Interneteinstellungen“ meinst aber das klappt sicher. Da muss dann ja nur dein Tor Browser laufen.

Systemsteuerung → Internetoptionen → Verbindungen → LAN Einstellung →
Proxy Server für Lan nutzen → Erweitert → Socks

Und bei Socks halt den Server von Tor eintragen ( 127.0.0.1 Port: 9050 )

Das hat bei mir auch geklappt, aber der Tor Browser muss laufen, wenn ich den Browser schließe komme ich nicht ins Internet.

Meine Frage ist aber nun:
Wenn ich einen VPN nutze, muss ich den Tor Server beim VPN eintragen oder ebenfalls in den Interneteinstellungen ?

Wenn du einen VPN-Provider hast, der vielleicht eigene TOR-Nodes betreibt, brauchst du überhaupt nichts irgendwo eintragen!
Hat dein Anbieter dies nicht, aber dein VPN soll in der Reihenfolge zuerst dran kommen, muss der Socks-Proxy (localhost) im Client hinterlegt werden, damit der restliche Traffic (z.B. FTP, SSH usw) ebenfalls über den ext. VPN-Server hin zum TOR-Node läuft.

Ansonsten hast du das Problem, wie schon beschrieben →

Das hat bei mir auch geklappt, aber der Tor Browser muss laufen, wenn ich den Browser schließe komme ich nicht ins Internet.

Denke aber auch an deine lokale Firewall (im Host oder im Router)…das diese den localhost und die zugehörigen Ports in beide Richtungen durchlässt. In 90% solcher Vorhaben vergessen die User die FW und suchen Ewigkeiten nach dem Fehler, wieso der Traffic nicht rein oder -rausgeht!!
Das könnte nämlich auch das Prob sein, dass du nicht mehr ins Netz kommst nach Beendigung des TOR-Browsers?! Weil alle anderen Dienste / Protokolle die FW nicht passieren können, wenn du zum Proxy willst…! Nur mal so als Denkanstoß :wink:

1 Like

1 Like

Verstehe
Man könnte den Socks auch im VPN Router eintragen richtig ?

Wenn ich den Socks im VPN Router eintrage und auf dem Host ebenfalls ein VPN nutze, würde die Kette theoretisch so aussehen:

VPN Router / Tor → VPN → Internet

ISP schickt mein Traffic verschlüsselt zum Router ( Perfect Privacy ), dieser schickt den Traffic verschlüsselt zu Tor, dieser schickt den Traffic verschlüsselt zum VPN auf dem Host ( Mullvad ) und über Mullvad gelange ich dann ins Internet.

Somit sieht mein ISP nicht das ich Tor nutze und den Traffic sieht er ebenfalls nicht.
Perfect Privacy sieht mein Traffic auch nicht, da er ihn verschlüsselt zu Tor schickt.
Tor sieht mein Traffic ebenfalls nicht, weil er es verschlüsselt zu Mullvad schickt.
( schutz gegen Bad-Nodes )
Und Mullvad sieht zwar den Traffic, jedoch ist die Ip von einem Tor Node und die korrelation wird dadurch erschwert.

Lieg ich da richtig, oder hab ich einen Denkfehler :smiley:

Wir hatten das Thema schon an anderer Stelle. Mit der Konfiguration bist du extrem auffällig unterwegs. Mal abgesehen davon, dass der Traffic auch aufeinmal unverschlüsselt laufen kann, weil VPN 1 nicht merkt was VPN 2 macht. Da könntest du auch nackig durch die Fußgängerzone laufen. Was auch immer du verbergen willst … Keep it simple!!

Setz dich mit Tails in die öffentliche Bibliothek und nutz deren Inet Zugang.

Das ganze wird auf meinem Mac Pro laufen, das ist nicht möglich mich irgendwo öffentlich zu setzen außerdem läuft der Mac 24/7.

Ich könnte doch Theoretisch den Datenverkehr splitten, wie wollen die mich dann identifizieren ?

Was @nomaam meint, belasse es am Besten bei der einfachsten, funktionierenden Konfiguration für das ganze Vorhaben!
Zwei versch. VPN-Provider plus TOR-Nodes und äußerst komplizierte Einstellungen, können genauso nach hinten losgehen, bei der Nutzung!!
TOR-Nodes stottern z.B. auch öfters mal und „„Zack die Bohne““ bricht das Konstrukt zusammen - und das schlimmste dabei: Meistens bemerkt man es erst, viel zu spät, dass der Socks wesch ist ist! :wink: Wie willst du eigentlich diese Verbindungen monitoren? Kill-Switch hilft ja dann nicht mehr…also muß man schon ein Auge darauf haben, bevor man wieder auf ISO - Jagd geht!!
:underage: :warning:

Man kann natürlich auch 3-5 Server anmieten, die alle außerhalb der 5 Eyes, 9 Eyes und 14 Eyes liegen und dann per VPN/TOR vom Nachbarn aus das Projekt betreiben.

Also funktioniert das auf keinen Fall selbst wenn ich den Traffic splitte ?

ISP schickt 500GB verschlüsselten Traffic raus:
200GB an VPN Router 1 → Laptop mit VPN → Internet
300GB an VPN Router 2 → Mac Pro mit VPN → Internet

Wie würde hier nun ein Correlation Attack stattfinden wenn 500GB rein geht und 1x 200GB und 1x 300GB raus geht ?

Perfect Privacy schreibt:
Mit einer kaskadierten Verbindung wird ein solcher Angriff enorm erschwert. Zwar kann man beim ISP immer noch sehen, zu welchem VPN-Server verbunden wird, aber eben nicht, wo der Traffic wieder raus kommt. Dazu wäre es nötig, den Traffic an allen VPN-Servern zu überwachen. Das macht es praktisch nahezu unmöglich, Nutzer über Traffic-Korrelation zu identifizieren.

Dies wird als End-to-End-Korellationsangriff bezeichnet:

Die Idee ist einfach: Anstatt zu versuchen, den Inhalt von Paketen zu entschlüsseln, versucht ein Angreifer, der beide Enden des Kommunikationskanals beobachten kann, Muster im Datenverkehr, um ausgehende und eingehende Daten zu vergleichen, um Benutzer zu entnannen. Dies kann durch die Korrelation der übertragenen Datenmenge oder der Vergleich der Zeit, zu denen Pakete übertragen werden, erfolgen. Zum Beispiel zeigt ein Benutzer, der ein Video streamt, ein anderes Muster in Bezug auf Timing und Traffic-Volumen als jemand, der auf einer Website stöbert.

Korrelationsangriffe sind ein schwer zu lösendes Problem in anonymen Netzwerken mit geringer Latenz wie Tor und dem Tor-Projekt, die in einem Blog-Post ausdrücklich erklärten, dass sie sich nicht vor diesen Angriffen durch Design schützen:
Das Tor-Design versucht nicht, sich vor einem Angreifer zu schützen (bis zu v4.x), der sowohl den Verkehr im Tor-Netz als auch den Verkehr aus dem Tor-Netzwerk sehen oder messen kann.
Die Art und Weise, wie wir es im Allgemeinen erklären, ist, dass Tor versucht, sich vor Verkehrsanalysen zu schützen, wo ein Angreifer versucht zu erfahren, wen er untersuchen soll, aber Tor nicht vor Verkehrsbestätigung schützen kann (auch als End-to-End-Korrelation bekannt), wo ein Angreifer versucht, eine Hypothese zu bestätigen, indem er die richtigen Orte im Netzwerk überwacht und dann die Mathematik macht.
Es gibt ziemlich viele Untersuchungen, die darauf hindeuten, dass Korrelationsangriffe immer noch eine große Bedrohung für Tor-Nutzer sind. Zum Beispiel analysierte ein Entwickler-Team im Jahr 2013 realistische Korrelationsangriffsszenarien, die zu dem Schluss kamen:

Die Ergebnisse zeigen, dass Tor mit noch größeren Risiken durch Verkehrskorrelation konfrontiert ist, als frühere Studien nahelegten. Ein Gegner bietet nicht mehr Bandbreite, als es einige Freiwillige heute tun können Entanonymisieren Sie jeden Benutzer innerhalb von drei Monaten nach der regulären Tor-Nutzung mit einer Wahrscheinlichkeit von über 50% und innerhalb von sechs Monaten mit über 80% Wahrscheinlichkeit.
Die These „Verteidigung von End-to-End-Bestätigungsangriffen gegen das Tor-Netzwerk“ enthält einige neuere Korrelationsexperimente im Live-TOR-Netzwerk mit der Erkenntnis, dass „End-zu-End-Bestätigungsangriffe erfolgreich gegen das aktuelle Tor-Netzwerk angewendet werden können“. Der Autor schlägt auch eine konkrete Verteidigungstechnik vor, die auf Dummy-Verkehr basiert, die angeblich „einfach, einfach zu implementieren und einzusetzen sowie nutzbar“ ist, aber nach bestem Wissen noch nicht den Weg in das Tor-Protokoll gefunden hat.
Seitdem wurde in den letzten 10 Jahren seitens der TOR-DEVs einiges getan. Jährliche Audits mit Test-Szenarien werden erprobt, sämtliche Verbesserungen werden anschl. direkt in den Code eingefügt. Trotzdem hat sich parallel in dieser Zeit die Immunität gegen diese Angriffe nicht wirklich merkbar verbessert! Höchstens im einstelligen Prozentbereich. Ergänzungen zur v4 Version des Netzwerks könnten eventuell etwas daran ändern und größere Erfolge forcieren! Wann genau das geplant ist, weiß nur der TOR Entwickler-Blog…

https://support.t0rproject.org/de/

Mathematischer Ansatz einer Erklärung zu Korrelationsangriffen:

Bei Korrelationsangriffen handelt es sich um eine Klasse von kryptografischen Angriffen auf bekannte Klartexte zum Brechen von Stromchiffren, deren Schlüsselströme durch Kombination der Ausgaben mehrerer linear rückgekoppelter Schieberegister (LFSRs) unter Verwendung einer booleschen Funktion erzeugt werden. Korrelationsangriffe nutzen eine statistische Schwäche aus, die sich aus der für den Schlüsselstrom gewählten Booleschen Funktion ergibt. Obwohl einige Boolesche Funktionen für Korrelationsangriffe anfällig sind, sind Stromchiffren, die mit solchen Funktionen erzeugt werden, nicht von Natur aus unsicher.
Erläuterung

Korrelationsangriffe werden möglich, wenn eine signifikante Korrelation zwischen dem Ausgangszustand eines einzelnen LFSR im Schlüsselstromgenerator und dem Ausgang der booleschen Funktion besteht, die die Ausgangszustände aller LFSRs kombiniert. Diese Angriffe werden in Kombination mit einer Teilkenntnis des Schlüsselstroms eingesetzt, die aus einer Teilkenntnis des Klartextes abgeleitet wird. Die beiden werden dann mit einem XOR-Logikgatter verglichen. Diese Schwachstelle ermöglicht es einem Angreifer, den Schlüssel für den einzelnen LFSR und den Rest des Systems separat zu erzwingen. Wenn beispielsweise bei einem Keystream-Generator vier 8-Bit-LFSRs kombiniert werden, um den Keystream zu erzeugen, und wenn eines der Register mit der Ausgabe der Booleschen Funktion korreliert, kann zuerst dieses Register und dann die übrigen drei LFSRs geknackt werden. Die Gesamtkomplexität des Angriffs beträgt somit 28 + 224.

Verglichen mit den Kosten eines Brute-Force-Angriffs auf das gesamte System mit einer Komplexität von 232 entspricht dies einem Faktor der Aufwandsersparnis von knapp 256. Wenn ein zweites Register mit der Funktion korreliert wird, kann der Prozess wiederholt werden und die Angriffskomplexität auf 28 + 28 + 216 reduzieren, was einem Faktor von knapp 65028 entspricht. Quelle: Wikiwand // Wiki

So denn Mohammad…dein verbissener Wille ehrt dich ja! Aber zwischendurch solltest du mal entspannen!!! Mal irgendwas in der Stadt wegflexen oder sowas in der Art ! :wink: :joy: :wink:

1 Like

wegflexen … :rofl: ich werde mal ne Tüte wegflexen!!

Für mich klingt das einfach nach einem Problem was hauptsächlich Tor user betrifft.

Ich verstehe einfach nicht wie es möglich sein soll den Eingang und Ausgang beim VPN zu kontrollieren.
Okey bei einem Single Hop sehr einfach zu machen, da ISP den VPN Server kennt und der VPN Server kennt auch den ISP.
Bei Multi Hop für mich definitiv nicht einfach zu machen, da ISP den 2. VPN Server nicht kennt und der 2. VPN Server kennt auch den ISP nicht.

Das wäre nur möglich wenn der VPN Provider loggs raus gibt.

So für heute mach ich echt ne pause, zeit zum wegflexen :smiley: :smiley:

1 Like

Okey 1 Frage hätte ich noch bitte :smiley: das lässt mir echt keine Ruhe.

Woher will ein Angreifer denn wissen wie hoch die Datenmengen sind vom ( Eingang & vom Ausgang ) ohne Zugriff auf diese Server zu haben ?

OK…aber nur, wenns flexen gehst oder gegangen bist?! :joy:

Wie bereits erwähnt, ist es für einen Beobachter, der sowohl dich als auch die Zielwebseite oder deinen Tor-Exit-Knoten sehen kann, möglich, die Zeitpunkte deines Datenverkehrs zu korrelieren, wenn er in das Tor-Netzwerk eintritt und auch wenn er es verlässt. Tor bietet keinen Schutz gegen ein solches Bedrohungsmodell.
Wenn eine Zensurbehörde oder eine Strafverfolgungsbehörde in der Lage ist, Teile des Netzes gezielt zu beobachten, können sie den Verdacht bestätigen, dass du regelmäßig mit deinem Freund sprichst, indem sie den Verkehr an beiden Enden beobachten und nur den Zeitpunkt dieses Verkehrs korrelieren. Dies ist nur nützlich, um zu überprüfen, ob die Parteien, die bereits im Verdacht stehen, miteinander zu kommunizieren, dies auch tun. In den meisten Ländern hat der für die Erlangung eines Haftbefehls erforderliche Verdacht bereits mehr Gewicht als die zeitliche Korrelation.
Da Tor außerdem Schaltkreise für mehrere TCP-Verbindungen wiederverwendet, ist es möglich, nicht-anonymen und anonymen Verkehr an einem bestimmten Exit-Knoten miteinander in Verbindung zu bringen, also sei vorsichtig, welche Anwendungen du parallel nebeneinander über Tor laufen lässt. Vielleicht solltest du sogar separate Tor-Clients für diese Anwendungen betreiben.

Und das war nur die übliche, einfache Variante!! :wink: