1. Foren
  2. Kommentare
  3. Wissenschaft
  4. Alle Kommentare zum Artikel
  5. › Black-Hat-Konferenz: Vortrag über…

TOR nicht sicher weil: Siehe inside

  1. Thema

Neues Thema Ansicht wechseln


  1. TOR nicht sicher weil: Siehe inside

    Autor: CraWler 22.07.14 - 13:57

    Also wenn der NSA den gesamten TOR Traffic speichert, dann kann natürlich auch analysiert werden wer wann mit TOR verbunden war.

    D.h Ich bin zum Zeitpunkt X verbunden und lade die Datenmenge Y runter. Also muss man nur schauen wann über outproxy z die Datenmenge Y über eine IP Verbindung übertragen wurde. Wenn man da die Daten über stunden abgleicht dürfte man so durchaus stochastische Rückschlüsse ziehen können.

    Als TOR Nutzer kann man das nur umgehen indem man selbst den eigenen TOR node als internen RELAY für andere Nutzer freigibt. So das nicht nur der eigene Traffic drüber läuft sondern auch noch der von anderen Usern und somit eine statistische Zuordnung über Big Data nicht möglich ist.

    Hab selbst nen TOR Relay (Intern) über den 3-4MB/s laufen, da dürfte dann meine Datenmenge Y nicht mehr ermittelbar sein, im Datenrauschen der anderen Nutzer. Das normale TOR Bundle hat aber keinen Relay, so das man sehr genau analysieren kann wie viel Daten nutzer X zu welcher Zeit runterläd. Wenn man ohnehin den ganzen Traffic wegspeichert könnte das durchaus rückschlüsse erlauben.

    TOR sollte da meiner Ansicht nach immer ein wenig Fake Traffic produzieren um da Rückschlüsse zu verhindern.

    ----------------------------
    Piratenpartei Wähler

  2. Re: TOR nicht sicher weil: Siehe inside

    Autor: plutoniumsulfat 22.07.14 - 14:16

    Wenn die den gesamten TOR-Traffic lesen können, dann brauchen sie gar keine stochastischen Rückschlüsse ziehen.

    Wenn die NSA nur die Knoten im Netz überwacht, bringt dir das auch nicht mehr viel oder?

  3. Re: TOR nicht sicher weil: Siehe inside

    Autor: CraWler 22.07.14 - 14:29

    Naja lesen können die den Traffic nicht, is ja verschlüsselt. Aber sehen welche Trafficmengen user x erzeugt und dann schauen ob die selbe Trafficmenge irgendwo gleichzeitig über nen Outproxy in einer IP Verbindung auffindbar ist. Wenn man so lange genug analysiert könnte man da nach einer gewissen Zeit vermutl durchaus Rückschlüsse ziehen.

    Zumal davon auszugehen ist das die Geheimdienste selbst Outproxies betreiben, z.B. gibzs TOR Relays in China (obwohl TOR dort verboten ist). Das wirft dann schon Fragen aus.

    Das Darknet innerhalb von TOR dürfte aber so oder so weiterhin sicher sein. (Solange die dortigen Services nicht gehackt oder direkt vom Geheimdienst angeboten werden). Echte Anonymität gibts auch mit TOR nur wenn man nen gewissen Aufwand betreibt.

    ----------------------------
    Piratenpartei Wähler

  4. Re: TOR nicht sicher weil: Siehe inside

    Autor: plutoniumsulfat 22.07.14 - 14:44

    Genau genommen musst du nur Ein- und Ausgang kontrollieren. Da braucht es nicht viel Zeit.

  5. Re: TOR nicht sicher weil: Siehe inside

    Autor: Fenix.de 22.07.14 - 15:00

    plutoniumsulfat schrieb:
    --------------------------------------------------------------------------------
    > Genau genommen musst du nur Ein- und Ausgang kontrollieren. Da braucht es
    > nicht viel Zeit.

    Da bei jeder Anmeldung im Tor-Netzwerk deine Route zufällig festgelegt wird, wird dieses Szenario immer als sehr umständlich und schwer durchführbar empfunden.

  6. Re: TOR nicht sicher weil: Siehe inside

    Autor: plutoniumsulfat 22.07.14 - 16:21

    Wenn du, wie die NSA, viel kontrollieren kannst, ist das gar nicht mal so schwierig. Du kannst ja theoretisch selber zwei Nodes betrieben. Nur da kannst du dir nicht ausuchen, wen du trackst, da ist es dann Zufall....

  7. Re: TOR nicht sicher weil: Siehe inside

    Autor: gboos 22.07.14 - 16:44

    Eben und darum gehts es ja. Das was ihr beschreibt ist alles keine Echtzeit-Analyse. Bei dem was die beiden Hacker vorstellen wollten ging es aber darum und ganz banal gesagt, mit einem Klick sagen zu können welcher User gerade wo im TOR -Netzwerk unterwegs ist. Wäre tötlich für TOR.

    Kann mir das nur so vorstellen das ein Protokoll-Fehler jeden User einen Stempel aufdrückt und dieser realtime verfolgt werden kann und somit sein Startpunkt verrät. Egal wie, wir werden es nun nicht so schnell erfahren.

    Schade.

  8. Re: TOR nicht sicher weil: Siehe inside

    Autor: Mingfu 22.07.14 - 18:06

    CraWler schrieb:
    --------------------------------------------------------------------------------
    > Hab selbst nen TOR Relay (Intern) über den 3-4MB/s laufen, da dürfte dann
    > meine Datenmenge Y nicht mehr ermittelbar sein, im Datenrauschen der
    > anderen Nutzer.

    Da täuschst du dich leider. Das ist relativ einfach herauszurechnen, insbesondere wenn dein Relay nicht als Entry-Guard gelistet ist.

    Denn viele Tor-Nutzer werden wohl die Standardeinstellung der Circuit-Länge 3 nutzen. Wenn du die auch nutzt, fallen aus deinem "Cover-Traffic" alle Nutzer heraus, die dein Relay an zweiter oder dritter Stelle ihrer Route gesetzt haben (wobei letzteres bedingen würde, dass du eine Exit-Node betreibst, was aber in Deutschland privat relativ mutig wäre). Denn bei denen sieht man, wenn man global überwachen kann, dass im Gegensatz zu deinem eigenen Traffic deren Traffic bereits nach deiner Node (wenn als Exit-Node genutzt) bzw. schon eine Node später (wenn als vorletze Node der Route benutzt) das Tor-Netzwerk verlässt. Dein eigener Traffic dagegen verbleibt, wenn du die Standardlänge 3 nutzt, noch zwei weitere Nodes im Tor-Netzwerk.

    Das könntest du nur vermeiden, wenn deine Node als Entry-Guard gelistet ist, also auch andere Nutzer diese Node als Einstiegsknoten benutzen und damit tatsächlich ununterscheidbar zu dir selbst sind. Dafür braucht es aber eine hohe Bandbreite und durchgängig hohe Erreichbarkeit - privat eher unwahrscheinlich zu realisieren.

    Nebenbei sieht das ganze Szenario auch nur auf den ersten Blick sehr clever aus. Denn man kann, wenn man tatsächlich globale Sicht auf den Traffic im Tor-Netzwerk hätte, ziemlich einfach die Routen aufdecken. Die Muster des Traffics in jeder Route sind schon nach kurzer Zeit recht eindeutig. Wenn z. B. in einere Route einige Zeit keine Pakete übertragen werden (weil der Benutzer z. B. nach dem Laden einer Website diese durchliest), dann fallen bei der Zuordnung alle Routen heraus, auf denen in dieser Zeit Pakete übertragen wurden. Und so kann man aus der Anzahl und den Abständen zwischen einzelnen Datenpaketen relativ schnell einen Großteil des Verkehrs zuordnen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Statistisches Bundesamt, Wiesbaden
  2. ING Deutschland, Nürnberg
  3. dSPACE GmbH, Böblingen
  4. Techniker Krankenkasse, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Core i7-1185G7 (Tiger Lake) im Test: Gut gebrüllt, Intel
Core i7-1185G7 (Tiger Lake) im Test
Gut gebrüllt, Intel

Dank vier äußerst schneller CPU-Kerne und überraschend flotter iGPU gibt Tiger Lake verglichen zu AMDs Ryzen 4000 eine gute Figur ab.
Ein Test von Marc Sauter

  1. Tiger Lake Überblick zu Intels 11th-Gen-Laptops
  2. Project Athena 2.0 Evo-Ultrabooks gibt es nur mit Windows 10
  3. Ultrabook-Chip Das kann Intels Tiger Lake

Verkehrswende: Zaubertechnologie statt Citybahn
Verkehrswende
Zaubertechnologie statt Citybahn

In Wiesbaden wird um den Bau einer Straßenbahn gestritten, eine Bürgerinitiative kämpft mit sehr kuriosen Argumenten dagegen.
Eine Recherche von Hanno Böck

  1. Fernbus Roadjet mit zwei WLANs und Maskenerkennung gegen Flixbus
  2. Mobilität Wie sinnvoll sind synthetische Kraftstoffe?

Java 15: Sealed Classes - Code-Smell oder moderne Erweiterung?
Java 15
Sealed Classes - Code-Smell oder moderne Erweiterung?

Was bringt das Preview Feature aus Java 15, wie wird es benutzt und bricht das nicht das Prinzip der Kapselung?
Eine Analyse von Boris Mayer

  1. Java JDK 15 geht mit neuen Features in die General Availability
  2. Java Nicht die Bohne veraltet
  3. JDK Oracle will "Schmerzen" von Java beheben