Tor

didi

><>
Moin,

habe mir aus dem App-Cafe Tor installiert. Vidalia Kontroll-Panel startet
ordnungsgemäß und verbindet sich mt dem Tor-Netzwerk. Nun erwarte ich,
wie bei anderen Distributionen, dass FireFox mit Tor-Verbindung gestartet wird.
Tut sich aber nix. Was mache ich falsch?

Gruß didi ><>

PC-BSD 9.2; xfce; Laptop asus x7bj
 
Ich vermute, dass es sich bei dem Paket nur um Tor handelt und nicht um das Tor-Bundle. Sprich du müsstest einen Firefox selbst installieren und an Tor "anpassen".
 
Danke für die Antwort. FireFox habe ich mal installiert und auch in den vidalia-Einstellungen bissel "rumgeändert" -
leider ohne Erfolg. Wenn ich mir das so unter windows anschaue denke ich doch, dass es sich um eine speziell
angepasste Version von FireFox handelt. Aber wie die anpassen und wie die dann in vidalia integrieren?

Gruß didi ><>
 
http://wiki.ubuntuusers.de/Tor/Programme_zur_Nutzung_von_Tor_konfigurieren

Firefox

Firefox kann direkt auf den Tor-Proxy zugreifen und braucht keinen zusätzlichen HTTP-Proxyserver.
Unter "Bearbeiten - Einstellungen - Erweitert - Netzwerk - Festlegen, wie sich Firefox mit dem Internet
verbindet - Einstellungen - Manuelle Proxy-Konfiguration" wählen.
Der Haken bei "Für alle Protokolle diesen Proxy-Server verwenden" muss entfernt werden.
Bei "SOCKS-Host:" 127.0.0.1 sowie beim darauf folgenden "Port:" 9050 eingetragen werden.
Auch muss "SOCKS(v5)" gewählt werden. Alle anderen Einträge (HTTP-Proxy, SSL-Proxy, FTP-Proxy)
werden frei gelassen.
Des Weiteren muss die Option "network.proxy.socks_remote_dns" auf "true" gesetzt werden.
Hierfür in das URL-Adressfeld "about:config" eingeben, anschliessend im Suchfeld
"network.proxy.socks_remote_dns" eingeben und den Wert von "false" auf "true" setzen.

Hat mit Tor und TorK funktioniert! Gruß didi ><>
 
Seid bitte extrem vorsichtig mit solchen Dingen, denn auch wenn das im Tor Browser Bundle so aussieht ist das bei weitem kein normaler Firefox mit zwei, drei Extensions, sondern ein mittlerweile ziemlich stark gepatchter "fork". Wenn du auch nur grundlegende Anonymität haben willst, dann empfehle ich dir dringend das Bundle zu verwenden. Außerdem ist es viel einfacher.
 
Danke Dir sehr für den Hinweis, Athaba.
Dass es sich bei dem FireFox im Bundle um eine stark angepasste Version handelt,
hatte ich ja in meinem vorletzten Beitrag vermutet. Die Frage ist: Gibt es das Bundle für PC-BSD?
 
Für starke Anonymität sollte auf keinen Fall das übliche System, mit dem man tagtäglich arbeitet, verwendet werden. Hier sollte tails in einer VM eingesetzt werden, die durch eine vorgeschaltete Firewall bis auf die Tor-Server komplett gefiltert ist, damit keinerlei Traffic leaken kann. Zusätzlich bietet es sich an, die MAC-Adressen der tails-VM sowie des direkt angrenzenden Routers zufällig zu würfeln und keine weiteren Hosts im Segment zu haben.

Jede "Session" im Sinne von "Vorgang" oder "Aufgabe" sollte außerdem immer durch einen Reboot getrennt werden.

Clientseitiger "state" im Sinne von Daten, die einen identifizierbar machen, sind das Schlimmste Übel, was einem passieren kann bei dem Versuch, wirklich anonym zu sein,
 
Danke auch für diese Antwort, TCM.
Tails befindet sich in meinem ständigen "Repertoire" der aktuell gerbrannten CD's. ;)
Intererssant dabei ist auch der Windows-XP-TäuschungsModus.
 
Zuletzt bearbeitet:
Wenn du auf die Download-Seite von Tor gehst gibt es da einen Punkt für alle Versionen. Da gibt es da Build scripts, die das Bundle selbst bauen.

Leider kann man heutzutage vieles nutzen um Leute zu tracken:
https://panopticlick.eff.org/

Da gibt es viele fiese Tricks, ETags statt Cookies, wenn JavaScript an ist sogar Zeug wie die genaue Fensterauflösung, etc. Jedenfalls ist es immer gut was zu verwenden, was viele verwenden. Talis und das Browser Bundle haben auch den Vorteil. Viele Leute begehen den Fehler alles zu deaktivieren was ihnen einfällt, aber damit macht man dann sehr leicht ein Pattern, das nur auf einen selbst zutrifft. Das Tor Browser Bundle tut einiges in die Richtung, aber das Tor-Projekt macht extrem viel, auch in Richtung Anti-Zensur und auch wenn es zu vielem fertige oder fast Ideen gibt kann es natürlich immer besser sein.

Noch ein Tipp: Wenn du Tor länger verwendest, dann vergiss nicht zwischen den Dingen, die du so tust eine neue Identität zu nehmen (verhindert zum Beispiel ETag-Tacking). Das Ganze ist ziemlich spannend, vor allem auch mit JavaScript führt das ja immer zu Diskussionen. Grundsätzlich kann man sich ja denken es ist eine Lücke, andererseits bedeutet das sowohl, dass man eher wie andere Leute aussieht und andererseits mehr Browser Bundle User (weil die Lieblingswebsites damit funktionieren) und damit eine höhere Anonymität für den Einzelnen. Deshalb ist Tails auch wirklich gut. Da bleibt nicht mehr viel übrig, was nicht "normalisiert" ist. Aber auch da gibt es einige Dinge, die ein Angreifer ausnutzen kann.
 
Man kann spaßeshalber mal panopticlick mit tails aufrufen, einmal mit dem default-Browserfenster (nicht maximiert) und einmal maximiert und den Unterschied beachten.

Das Javascript im tails-Browser und auch ETags sind total egal, solange man nicht 2 verschiedene Sachen in der gleichen Session macht - und damit meine ich nicht dieses "neue Identität"-Feature von Tor, sondern knallhart rebooten und dabei alle beteiligten MAC-Adressen neu würfeln.

Ich hab bei mir auf dem Router ein komplett eigenes Subnetz für die Tails-VM, was in der VM wie eine Standard-Fritzbox-Installation aussieht, d.h. das Interface kriegt - solange die Tails-VM nicht läuft - alle 5min eine zufällige MAC-Adresse mit einem der AVM-Präfixe und zufälligem Suffix[1]. Das Subnetz ist auch das Fritzbox-typische 192.168.178/24.

Die Tails-VM hat eine feste MAC-Adresse eingestellt, die am Router blockiert ist, d.h. solange die VM nicht ihre MAC-Adresse verwürfelt hat, kriegt sie kein Netz. Auf dem Router läuft bei Bedarf ein Script, was sich aus einer woanders laufenden Tor-Installation alle bekannten Tor-Nodes + Port holt und diese in pf reinfummelt. Das ist dann auch der einzig erlaubte Traffic für die VM (plus Traffic zum DHCP-Server, der nur für dieses Subnetz ohne irgendwelche Namen/IDs/... läuft) - kein DNS, NTP oder sonstwas. Tails braucht nur die Tor-Nodes.

Das einizge, was einem damit gefährlich werden kann, sind Exploits in Tails, die nicht nur root in der VM kriegen, sondern auch noch aus der VM ausbrechen können und irgendwie ins Internet kommen. Das Management-Interface vom VM-Server hat natürlich kein Internet.

Edit: Besser als eine VM ist natürlich ein echter Rechner. Aber auch und besonders hier ist wichtig, die MAC-Adressen zu verwürfeln.


[1]:
Code:
#!/bin/sh

PATH=/usr/bin:/usr/sbin:/bin:/sbin

interface=[...]

[ -n "$(pfctl -i ${interface} -ss)" ] && exit 0

macprefixes=$(cat /var/db/oui.txt | sed -En 's/^[[:space:]]*([-0-9A-F]{8})[[:space:]]+\(hex\).*AVM GmbH.*$/\1/p' | sed 's/-/:/g')

ifconfig ${interface} lladdr $(printf "%s:%02X:%02X:%02X" $(echo ${macprefixes} | tr ' ' '\n' | head -n $(((RANDOM%$(echo ${macprefixes} | wc -w))+1)) | tail -n 1) $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))

/var/db/oui.txt ist http://standards.ieee.org/develop/regauth/oui/oui.txt
 
Die Diskussion hat erst einmal dazu geführt, dass ich mich noch mal mit Tails beschäftigt habe
und so, wie ich das rauslese, scheint es doch eine recht sichere Alternative zu sein. Ich benutze
Tails nicht in einer VM, sondern boote von CD/USB-Stick.
Die Kombination Vidalia/FireFox mag in PC-BSD nicht die sicherste sein aber immerhin zeigen die
Testseiten die Benutzung von Tor. Danke für die Antworten.

Gruß didi ><>
 
@TCM:

Ich halte deine Ratschläge bzw. dein Setup für einigermaßen bedenklich. Das hat mehrere Gründe:

Zu allererst verstehe ich nicht ganz was du dir durch die ganze Prozedur erhoffst. Dass du ins Tor-Netzwerk verbindest kannst du nicht verschleiern. Wozu die neue MAC- und deshalb auch IP-Adresse? Viel mehr machst du da eher eine große Ankündigung nach draußen und wer weiß wie sich damit das Netzwerk verhält.

Ein weiterer Punkt ist, dass du wenn du all deine Daten, auch die von Tor abschüttelst deine Guard-Nodes (die Nodes, die Tor auswählst, zu denen du dann immer verbindest um diverse Arten von Attacken zu verhindern) verlierst, was dich/deine Anonymität unsicherer machst.

Außerdem stellt das Ganze ein ziemlich eindeutiges Verhalten dar, das man wohl ziemlich leicht tracken kann. Mit so einem Verhaltensmuster bist du dann wenn du dich ins Tor-Netz verbindest erkennbar und danach ist sowas, wie deine MAC-Adresse ja ohnehin nicht mehr interessant. Weiß jetzt nicht

Etags und JavaScript sind nicht egal, weil du damit Daten zum Korrelieren sammeln kannst, genauso wie mit Cookies, etc. Verhaltensprofile kann man auf so viele Arten machen von ganz low level an der Technik, bis ganz High Level, Click Tracking, was du schreibst, etc. Wenn du also extrem vieles speziell machst fällst du unheimlich leicht solchen Attacken zum Opfer. Dann bist du Pseudonym und wenn man das dann noch möglicherweise mit deinem üblichen Verhalten (oder Interessen) korreliert bist du schnell identifiziert. Und wenn du auf eine einzigartige oder seltene Art und Weise das Tor-Netz benutzt dann kann man jemanden auch ziemlich leicht über Sessions hinweg tracken.

Oder was ist, wenn deine Firewall zu restriktiv ist, dann leakst du dadurch eventuell Informationen. Connections, die da sein sollten fehlen, weil du zum Beispiel nicht zu einem Tor-Node kommst.

Ein weiteres Problem kann die VM sein. Den Hostrechner kann beobachten, was die Maschine tut, die VM selbst kann dich ausspionieren. Meist kommt in Virtualisierungen leichter rein, als raus. Das kann man ausschließen, wenn man das mit einem Computer, statt einer VM macht. Aber wie gesagt, den Entry-Guard-Schutz verliert man dann.

Generell dürften die Maßnahmen nicht viel bringen. Der beste Angriffspunkt ist der erste Hop. Da funktionieren einige Attacken. Genau deshalb gibt es ja Entry Guards. Wenn du nun nur die in der of erlaubst, dann erlaubst du dem wahrscheinlichsten Angreifer was. Klar, an und für sich immer noch besser als wahrscheinliche Angreifer und unwahrscheinliche Angreifer. Das Problem ist nur, dass wenn du jetzt immer komplett neu verbindest du entweder deine Entry-Guards verlierst oder dich die ohnehin leicht erkennen, wegen der vorangegangenen Dinge. Also bringt das MAC/IP ändern nicht sonderlich viel. Mal abgesehen, dass der Angreifer am ersten Hop mit einem Scan mit hping gegen den Router (oder auf unzählige andere Arten) wohl ohnehin rausbekommt, dass du es bist und eine neue MAC/IP hast.

Aber kannst du mal beschreiben, warum du die Dinge tust, die du tust? Ich bin auch kein Profi, also vielleicht alles nur Stuss.
 
@TCM:

Ich halte deine Ratschläge bzw. dein Setup für einigermaßen bedenklich. Das hat mehrere Gründe:

Zu allererst verstehe ich nicht ganz was du dir durch die ganze Prozedur erhoffst. Dass du ins Tor-Netzwerk verbindest kannst du nicht verschleiern. Wozu die neue MAC- und deshalb auch IP-Adresse? Viel mehr machst du da eher eine große Ankündigung nach draußen und wer weiß wie sich damit das Netzwerk verhält.
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.

Ein weiterer Punkt ist, dass du wenn du all deine Daten, auch die von Tor abschüttelst deine Guard-Nodes (die Nodes, die Tor auswählst, zu denen du dann immer verbindest um diverse Arten von Attacken zu verhindern) verlierst, was dich/deine Anonymität unsicherer machst.
Ich sehe nicht, wie es schaden soll, wenn ich Informationen wegwerfe. Siehe ETags und Sonstiges.

Außerdem stellt das Ganze ein ziemlich eindeutiges Verhalten dar, das man wohl ziemlich leicht tracken kann. Mit so einem Verhaltensmuster bist du dann wenn du dich ins Tor-Netz verbindest erkennbar und danach ist sowas, wie deine MAC-Adresse ja ohnehin nicht mehr interessant. Weiß jetzt nicht
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.

Etags und JavaScript sind nicht egal, weil du damit Daten zum Korrelieren sammeln kannst, genauso wie mit Cookies, etc. Verhaltensprofile kann man auf so viele Arten machen von ganz low level an der Technik, bis ganz High Level, Click Tracking, was du schreibst, etc. Wenn du also extrem vieles speziell machst fällst du unheimlich leicht solchen Attacken zum Opfer. Dann bist du Pseudonym und wenn man das dann noch möglicherweise mit deinem üblichen Verhalten (oder Interessen) korreliert bist du schnell identifiziert. Und wenn du auf eine einzigartige oder seltene Art und Weise das Tor-Netz benutzt dann kann man jemanden auch ziemlich leicht über Sessions hinweg tracken.
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?

Oder was ist, wenn deine Firewall zu restriktiv ist, dann leakst du dadurch eventuell Informationen. Connections, die da sein sollten fehlen, weil du zum Beispiel nicht zu einem Tor-Node kommst.
Deswegen hol ich ja alle aktuellen Nodes und bastel die in das pf-Ruleset rein.

Ein weiteres Problem kann die VM sein. Den Hostrechner kann beobachten, was die Maschine tut, die VM selbst kann dich ausspionieren. Meist kommt in Virtualisierungen leichter rein, als raus. Das kann man ausschließen, wenn man das mit einem Computer, statt einer VM macht. Aber wie gesagt, den Entry-Guard-Schutz verliert man dann.
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.

Generell dürften die Maßnahmen nicht viel bringen. Der beste Angriffspunkt ist der erste Hop. Da funktionieren einige Attacken. Genau deshalb gibt es ja Entry Guards. Wenn du nun nur die in der of erlaubst, dann erlaubst du dem wahrscheinlichsten Angreifer was. Klar, an und für sich immer noch besser als wahrscheinliche Angreifer und unwahrscheinliche Angreifer. Das Problem ist nur, dass wenn du jetzt immer komplett neu verbindest du entweder deine Entry-Guards verlierst oder dich die ohnehin leicht erkennen, wegen der vorangegangenen Dinge. Also bringt das MAC/IP ändern nicht sonderlich viel. Mal abgesehen, dass der Angreifer am ersten Hop mit einem Scan mit hping gegen den Router (oder auf unzählige andere Arten) wohl ohnehin rausbekommt, dass du es bist und eine neue MAC/IP hast.
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.
 
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.
 
Zurück
Oben