Du musst das Ganze aus der Sicht sehen, dass ich Tails nicht vertraue. Dann wird ein Schuh draus. Edit: Was machst du denn mit einer statischen MAC-Adresse, wenn das FBI deinen Browser exploitet, lokal arp -an laufen lässt und das Ergebnis über Tor leakt? Dann sind deine Tails-MAC-Adresse und deine Router-MAC-Adresse auf einmal bekannt. Das verhindere ich damit. Browser-Exploit im Tor Bundle war genau der Angriffsvektor, der aktiv genutzt wurde vor gar nicht langer Zeit.
Ich sehe nicht, wie es schaden soll, wenn ich Informationen wegwerfe. Siehe ETags und Sonstiges.
Versteh ich jetzt nicht. Was willst du denn noch erkennen, wenn die IP-Adresse in einem Fritzbox-Subnetz liegt und auch die MAC-Adresse vom Router die einer Fritzbox ist? Dass ich das Verfahren hier so genau beschreibe, heißt doch nicht, dass es dir irgendwas nützt.
Deswegen werf ich doch den State weg, inkl. MAC-Adressen. Erst sagst du, man soll die Session nicht wegwerfen wegen Guard-Nodes, dann bemängelst du, dass ETags dich tracken. Ja wie denn nu?
Deswegen hol ich ja alle aktuellen Nodes und bastel die in das pf-Ruleset rein.
Ja, VM oder nicht VM ist nochmal ein Punkt, aber spielt in der Vorgehensweise so keine Rolle. Ob ich das alles mit ner VM oder nem echten Rechner mache, ist eigtl. egal.
Seh ich absolut nicht. Auch das mit den Entry Guards erscheint mir spanisch. Was macht denn jemand, der noch nie im Tor-Netz war? Der hat auch keine Guards. Wie gesagt, jeder State ist schlecht, und wie du von außen erkennen willst, dass ich es bin, musst du nochmal genauer erklären. MAC address randomisation kommt übrigens im nächsten Tails per default, nur mach ichs halt noch für den Router mit, denn nur im Client bringts nichts.
Zunächst einmal zur Frage "Was macht jemand, der Tor zum ersten mal verwendet": Genau darum geht es bei Guard Nodes. Dass du das genau einmal, beim ersten Mal tust und der Angreifer genau eine Chance hat dich anzugreifen und du deshalb sicherer bist. Kurzum. Es geht um Statistik, wie bei allen anderen Punken übrigens auch.
Vor gar nicht allzu langer Zeit gab es zu den Entry Guards einen Blog post aus dem ich mal eine Beschreibung von drei Angriffsarten gegen die sie dich schützen zitiere:
In Tor, each client selects a few relays at random, and chooses only from those relays when making the first hop of each circuit. This entry guard design helps in three ways:
First, entry guards protect against the "predecessor attack": if Alice (the user) instead chose new relays for each circuit, eventually an attacker who runs a few relays would be her first and last hop. With entry guards, the risk of end-to-end correlation for any given circuit is the same, but the cumulative risk for all her circuits over time is capped.
Second, they help to protect against the "denial of service as denial of anonymity" attack, where an attacker who runs quite a few relays fails any circuit that he's a part of and that he can't win against, forcing Alice to generate more circuits and thus increasing the overall chance that the attacker wins. Entry guards greatly reduce the risk, since Alice will never choose outside of a few nodes for her first hop.
Third, entry guards raise the startup cost to an adversary who runs relays in order to trace users. Without entry guards, the attacker can sign up some relays and immediately start having chances to observe Alice's circuits. With them, new adversarial relays won't have the Guard flag so won't be chosen as the first hop of any circuit; and even once they earn the Guard flag, users who have already chosen guards won't switch away from their current guards for quite a while.
Der ganze Artikel ist hier zu finden.
Dann zu den anderen Punkten, wo du immer meinst, dass du alles Droppst und es damit weniger Angriffspunkte gibt. Das stimmt, wenn der Angreifer am anderen Ende sitzt. Das Problem tritt auf, wenn es darum geht, dass ein Angreifer dein Verhalten nutzt:
ETags und Cookies können dich lange tracken. Das bedeutet, dass du damit ein Verhaltensmuster produzierst. Vergleichst du das mit dem Verhaltensmuster außerhalb von Tor, dann kann man das korrelieren. Wenn du eine neue Identität schnappst, ändert sich dein Exit Node/deine IP, Cookies, ETags, Local Storage, History, etc. werden gelöscht. Damit ist die Angriffsfläche die darauf basiert weg. Da sind wir uns einig, oder?
Wie gesagt, ich weiß nicht, was beim neu Verbinden alles passiert. Die Sache ist nur folgende: Dass du Tor nutzt kannst du nicht verbergen (naja, zumindest wenn du keine Bridges, etc. verwendest und selbst da gibt es theoretische Möglichkeiten), weil jeder sehen kann, dass du zu einem Guard Node/ins Tor-Netz verbindest. Das was du verhindern willst ist das "hinein gehen" und das "heraus kommen" (am Exit Node, dessen IP du hast) miteinander zu verbinden. Klar, deine IP ist einfach mal eine andere, aber wenn jemand das Netzwerk (auch nur passiv) über wacht, dann hat er einen Anhaltspunkt, wenn du ganz laut schreist "So ich mach jetzt meine komplette Netzwerkverbindung neu". Dann kannst du womöglich Timing, Initialen Traffic, etc. nutzen um draufzukommen, dass du der bist, der am Exit gerade rausgepoppt ist. Deshalb weiß ich wie gesagt nicht, wie das Verhältnis von Vor- und Nachteilen in dem Fall ist.
Kurzum, securitymäßig ist das Konzept von dir echt cool, nur was jemand, der das Netzwerk passiv analysiert (und da gibt es viele, die die Möglichkeiten haben, wenn Traffic vorbei geht), dann kann ein Attacker dort wo du rauskommst den Angriff auf deinem Verhalten auf den Zielwebsites machen und auf der anderen Seite jemanden der den verschlüsselten Taffic, bzw. eben nur die Verbindungen und die Masse an Daten, die übertragen werden versuchen von außerhalb zu korrelieren. Entlarven wird dich wohl erst eine Kombination von mehreren Dingen. Allerdings ist das ja eine Sache von Statistik. Dein Setup schützt vor Angriffen die dich direkt Identifizieren, aber ich spreche von Angriffen wo ein Angreifer mehrere Anhaltspunkte zusammen nimmt, also dem was Panopticlick in einem ganz kleinem Spektrum (ohne Netzwerk, längerem Zeitraum, Etags, etc.) tut.
Du musst das Ganze aus der Sicht sehen, dass ich Tails nicht vertraue. Dann wird ein Schuh draus.
Edit: Was machst du denn mit einer statischen MAC-Adresse, wenn das FBI deinen Browser exploitet, lokal arp -an laufen lässt und das Ergebnis über Tor leakt? Dann sind deine Tails-MAC-Adresse und deine Router-MAC-Adresse auf einmal bekannt. Das verhindere ich damit. Browser-Exploit im Tor Bundle war genau der Angriffsvektor, der aktiv genutzt wurde vor gar nicht langer Zeit.
Okay zunächst mal. Ich stimme zu, dass das wenn es um Security geht der richtige Weg ist. Alles abriegeln und nichts und niemanden vertrauen. Von Standpunkt Anomyität hat es Macken. Dabei möchte ich auch darauf aufmerksam machen, dass diese Angriffe darauf basiert sind, dass die User veraltete Bundles. Das sollte man stehts vermeiden.
Aber ein paar Punkte dazu: Wirst du auf diese Art angegriffen kann deine Mac-Adresse geändert werden, können unzählige weitere deanonymisierende Angriffe gestartet werden. Das FBI kann einen Tor-Server haben und Tor instruieren zu ihm zu verbinden. Und da das ein Tor-Node und damit von deinem pf-Setup erlaubt ist haben die genauso deine IP-Adresse. Die MAC-Adresse schützt dich davor nicht.
Es ist viel einfacher und effektiver Tor Streams und verhalten lang genug zu beobachten um genug Daten gesammelt zu haben um diese zu korrelieren zu können. Das sind weit bekannte Schwachstellen, mit Papers wie man es angeht (und zu Glück auch schon Papers wie man es fixen kann. Das ist eben der Punkt. Wenn du was einzigartiges baust und dein Setup ist im Verhältnis zu den meisten Tor-Usern eine Ausnahme, dann machst du auf dich aufmerksam, nicht aufmerksam im Sinne von "hey, ich hab was zu verbergen", sondern aufmerksam im Sinne von vielen Verbindungen, die durch das Tor-Netz gehen. Eben auf Grund des Verhaltens der Verbindung.
[quore]Ich sehe nicht, wie es schaden soll, wenn ich Informationen wegwerfe. Siehe ETags und Sonstiges.[/quote]
ETags sind eine Möglichkeit dich zu tracken (kann man wie Cookies verwenden, auch wenn sie nicht dazu gedacht sind), während Entry Guards ein Schutz gegen diverse Attacken darstellen und es lediglich darum geht dich beim ersten Hop immer zu den selben Tor-Nodes zu verbinden. Es geht um keine andere Information.
Versteh ich jetzt nicht. Was willst du denn noch erkennen, wenn die IP-Adresse in einem Fritzbox-Subnetz liegt und auch die MAC-Adresse vom Router die einer Fritzbox ist? Dass ich das Verfahren hier so genau beschreibe, heißt doch nicht, dass es dir irgendwas nützt.
Eventuell dein Verhalten, die Tatsache, dass du jetzt neu zu allem verbinden musst, du deshalb dieses und jenes (DNS-Informationen) und so weiter besorgen musst, neue Daten über das Tor-Netz, die du dir besorgst, die Tatsache, dass du dir viel neue Daten lädst, du mit einer sehr hohen Wahrscheinlichkeit, am Exit Node gleich einen DNS Request auf check.torproject.org mit einer nachfolgenden Verbindung dorthin verursachst, dass dein Browser sich dabei so verhält, als wäre er ganz neu aufgesetzt worden. Aber es geht eben um dieses zündende Element am Beginn dieses Reset-Prozesses deines Systems, das man wohl als jemand, der das passiv beobachtet bemerken wird, gefolgt von all den anderen Dingen, die am Exit passieren werden.
[quotes]Deswegen werf ich doch den State weg, inkl. MAC-Adressen. Erst sagst du, man soll die Session nicht wegwerfen wegen Guard-Nodes, dann bemängelst du, dass ETags dich tracken. Ja wie denn nu?[/quote]
Zwei verschiedene Angriffsvektoren. Einer am Exit, der ein Profil über dich macht, der andere durch die oben beschriebenen Szenarien.
Deswegen hol ich ja alle aktuellen Nodes und bastel die in das pf-Ruleset rein.
Ständig, in Echtzeit? Genau basierend auf dem, was dein Tor-Client haben sollte? Übers Internet oder über Tor? Wenn nicht über Tor machst du dich vielleicht sichtbar, wenn über Tor kann dir der Exit beliebige Daten füttern. Oder machst du das ständig? Aber trotzdem: Geht das in Real Time? Hatte bisher nicht mit so vielen Host:Port-Regeln zu tun. Oder bei Updates der Directory Authorities. Und wenn du das tust, ein Tipp: Stell am besten sicher, dass es wirklich nur Guards sind, am Besten die, die du verwenden wirst, musst du aber wohl Tails hacken, dass die an deinen Router gesendet wird, auch wenn das wieder ein neuer Angriffspunkt wird. Hmm... Ideen? Bin neugierig.
Seh ich absolut nicht. Auch das mit den Entry Guards erscheint mir spanisch. Was macht denn jemand, der noch nie im Tor-Netz war? Der hat auch keine Guards. Wie gesagt, jeder State ist schlecht, und wie du von außen erkennen willst, dass ich es bin, musst du nochmal genauer erklären. MAC address randomisation kommt übrigens im nächsten Tails per default, nur mach ichs halt noch für den Router mit, denn nur im Client bringts nichts.
Ich hoffe das was ich oben zitiert habe hilft dir weiter. Es geht eben um die Chance eines erfolgreichen Angriffs. Ist ein heißes Thema und es gibt gerade viel Research auf dem Gebiet. Gibt auch einen FAQ-Entry:
https://www.torproject.org/docs/faq#EntryGuards
Aber ja, es ist ein komplexes Thema und das ist eben so eine Sache. Es gibt so viele Angfrissvektoren und Tor ist da einfach extrem gut und buttert ordentlich in Research und Gefahren abwägen und der einzige Grund warum es so viele bekannte Attacken gibt (wie gesagt, meist mit Lösungsanzeichen) ist eben, dass das ein cooles Projekt ist. Ich mach mir wenn ich jemanden was dazu erzähle immer sorgen, dass sich der dann denkt, dass Proxies von vertrauenswürdigen Personen oder VPNs oder so sicherer sind, also auch hier: VPNs, Proxies, auch Multihop Procies und JonDonym/JAP haben so viele Schwachstellen, gegen die sie großteils per Design nicht schützen können. Klar, Tor wird von den USA gesponsert, aber von der internationalen Fachwelt ständig auf den Prüfstand gestellt und auch wenn Tor nicht perfekt ist, hat es den restlichen Systemen sicherlich Jahre voraus.
