 Es geht um ein sichereres Tor-Netzwerk für die Userinnen und User und wir gehen jetzt direkt hinein und nachher gibt es Fragen oder Antworten. Danke für die Einladung, über ein Thema zu sprechen, das mir sehr wichtig ist, das Tor-Netzwerk. Das Tor-Netzwerk ist eine sehr wichtige Infrastruktur, ohne die der Tor-Bauser nicht funktionieren würde. Ich finde gerne bösartige Tor-Relays heraus, um Tor-User zu schützen. Weil das nicht ohne Risiken möglich ist, möchte ich mich schützen gegen diejenigen, die solche Relays betreiben, damit ich sie weiter bekämpfen kann. Deshalb ist dies ein voraufgezeichneter Talk und dies ist nicht meine eigene Stimme. Danke an die Menschen im Hintergrund, durch die ich diesen Vortrag in Sicherheit geben kann. Ein wenig über mich. Ich interessiere mich schon lange für den Zustand des Tor-Netzwerks. 2015 startete ich ONETRAIDER, eine öffentliche Mailing-Liste und Website mit Berichten über Relay-Gruppen und mögliche SIPPLE-Angriffe. 2017 wurde ich eingeladen, der privaten Tor-Projekt Mailing-Liste Bad Relays beizutreten, auf der Berichte über bösartige Relays untersucht werden. Für ein besseres Verständnis, wer welchen Anteil des Tor-Netzwerks betreibt, startete ich ONETSTATS. Hier ist auch zu sehen, welche Betreiber in der Lage sind, durch Ende-zu-Ende-Korrelations-Angriffe Tor-User zu de-anonymisieren, mehr dazu später. Ich betreue außerdem Ansible Relayer, eine Ansible-Rolle, die von vielen großen Relay-Betreiberinnen eingesetzt wird. Aus eigenem Interesse betreibe ich auch ein wenig Open-Source-Recherche über bösartige Akteurinnen im Tor-Netzwerk. Besonders, wenn ihre Motive zum Betrieb von Relays unklar sind. Um Verwirrung zu vermeiden in Bezug auf das Tor-Projekt, ich werde nicht vom Tor-Projekt bezahlt und ich spreche nicht für das Tor-Projekt. In diesem Vortrag betrachten wir einige Beispiele von bösartigen Akteuren im Tor-Netzwerk. Sie sind sozusagen das Ausgangsproblem, das uns zu Verbesserungen motiviert. Wir beschreiben Probleme in den aktuellen Abwehrstrategien gegen bösartige Relays und zeigen einen neuen Ansatz, der mehr Sicherheit durch die Nutzung vertrauter Relays anstrebt. Die Hauptzielgruppe sind Tor-User, etwa Tor-Browser-User, Relay-Betreiberinnen und Betreiber, Betreiberinnen von Aniendiensten wie etwa Secure-Drop und alle, denen Tor wichtig ist. Um alle auf denselben Stand zu bringen, eine kurze Erinnerung, wie Tor funktioniert und welche Arten von Relays oder Nodes es gibt. Wenn Alice mit dem Tor-Browser die Website von Bob besucht, konstruiert ihr Tor-Client eine Rube, wird drei Relays, mit der ihre Daten durch das Tor-Netzwerk geleitet werden, bevor die Pakete bei Bob ankommen. Dadurch erreicht Alice Orts Anonymität. Der erste Relay in seiner Route heißt Entry Guard Relay. Dies ist der einzige Relay, der Alice's echter IP-Adresse sieht. Dies ist also ein sensitiver Relay. Aber der Guard Relay erkennt nicht, dass Alice sich mit Bob verbinden will, er sieht nur den nächsten Relay als Ziel. Guard Relays ändern sich selten und Alice's Tor-Client wartet bis zu zwölf Wochen, bevor ein neuer Guard gewählt wird, um einige Angriffe zu erschweren. Der zweite Relay heißt Mittel oder nur Mittel Relay. Dies ist die am wenigsten sensitive Position, weil dieser Relay nur andere Relays sieht und nichts über Alice oder Bob erfährt, weil er nur verschlüsselte Datenströme weiterleitet. Und der letzte Relay heißt Exit Relay. Der Exit Relay erkennt das Ziel Bob, aber nicht, wer sich mit Bob verbindet. Der Exit Relay ist auch einer der sensitiveren Relays, weil er potentiell den Kommunikationsinhalt im Klartext sieht, falls Alice nicht ein verschlüsseltes Protokoll wie HTTPS verwendet. Obwohl Exit Relays das Ziel sehen, können sie nicht Informationen über Alice-Sites sabbeln, mit denen sich Alice im Laufe der Zeit verbindet und etwa ein Profil erstellen. Denn Alice ist das Tor-Blause, sorgt dafür, dass ihr Tor-Client für verschiedene Zieldomains verschiedene Routen aufbaut in der Adress-Leiste. Also dieses Schaubild zeigt nur eine Route, aber ein Tor-Client hält normalerweise zur jeder Zeit mehrere Routen aufrecht. In Netzwerken, die Tor-Zensieren, verwenden die User einen speziellen Relay-Typ namens Brücke oder Bridge. Der Hauptunterschied ist, dass Bridges nicht in der öffentlichen Liste aller Relays erscheinen, um Blockaden gegen sie zu erschweren. Alice muss eine Bridge manuell in ihrem Tor-Blause einstellen. Aus Redundanzgründen ist es gut, wenn mehr als eine Bridge verwendet wird, für den Fall, dass die erste Bridge offline geht oder zensiert wird. Auch eine Bridge sieht Alice's echte IP-Adresse, aber nicht die Ziel-Adresse. Mit diesem Verständnis des Tourenetzwerks fragen wir vielleicht, warum müssen wir dem Netzwerk vertrauen, wenn die Rollen sich auf verschiedene Relays verteilen? Schauen wir also auf einige Angriffs-Szenarien. Wenn ein Angreifer oder eine Angreiferin Alice's Guard und Accent Relay kennt, dann kann er sie lernen, dass Alice sich mit Bob verbindet durch Ende-zu-Ende-Korrelationsangriffe. Diese Angriffe sind passiv, kein Datenverkehr wird verändert und können daher nicht durch Testdatenverkehr an verdächtige Relays erkannt werden. Ohne Staats veröffentlicht täglich eine Liste von Betreibern, die in der Lage sind, dies zu tun. Es gibt einige Einschränkungen, die ein Turclein beachtet, um dieses Risiko zu verringern. Zum Beispiel verwendet ein Turclein nie mehr als einen Relay im selben 16er Subnetz, wenn er Routen aufbaut. Zum Beispiel wird Alice's Turclein nie diese Route aufbauen, weil Dat und Accent im selben Subnetz 192.0.-16. Deshalb ist die Anzahl verschiedener 16er Subnetze, in denen ein Angreifer seine Relays platziert oder verteilt hat, für dieses Risiko relevant. Ehrliche Relay-Betreiberinnen betreiben ihre Relay-Gruppen in der sogenannten MyFamily-Option. Dadurch liegen sie offen, was ihre Relays sind und Turcleins vermeiden automatisch die Verwendung von mehreren Relays aus der gleichen Familie in einer einzelnen Route. Bösartige Akteurinnen geben ihre Familie entweder nicht an oder geben vor, mehr als eine Familie zu sein. Eine Variante des Ende-Zu-Ende-Korrelations-Angriffs ist möglich, wenn Bob der Angreifer ist oder vom Angreifer kompomentiert wurde und der Angreifer außerdem Alice's Guard Relay betreibt. Dann kann der Angreifer auch Alice's vare IP-Adresse herausfinden, wenn sie Bob's Website besucht. Wenn große Gruppen von Nicht-Exit-Relays auffällig werden oder verdächtig werden, könnte es auch sein, dass sie hinter Aniendiensten her sind, denn Aniendienste benötigen keine Exit-Relays. Aniendienste ermöglichen Orts-Anonymität auf der Serverseite. Beim Betrieb Fehler Non-Exits könnte das Ziel sein, die wahre IP-Adresse und den Ort eines Aniendienstes zu erfahren. Manipulierende Exit-Relays sind wahrscheinlich der häufigste Angrist-Typ, den wir beobachten. Diese Angriff ist auch am leichtesten auszuführen. Bösartige Exits interessieren sich normalerweise nicht, wer alles ist oder was ihre IP-Adresse ist. Sie wollen meist nur von Datenmanipulation profitieren. Dieser Angriff kann durch das Senden von Köder-Traffic an Exits erkannt werden, aber seit dem bösartige Exits ihre Angriffe gezielter ausführen, nur auf dem Domains, ist die Erkennung nicht so trivial, wie es scheint. Der beste Schutz gegen diesen Angriff ist der Gebrauch von Verschlüsselung. Bösartige Exits können keinen Schaden bei Verbindungen zu Aniendiensten anrichten. Schauen wir uns nun einige echte Beispiele für großen und dauerhaften bösartigen Akteuren im Turnetz an. Das erste Beispiel erfasst als BTC-MIT-M20 ist als bösartige Exit im Geschäft und führt SSL-Strip-Attacken auf Exit-Relays aus, um HTTP-Datenverkehr im Klartext zu manipulieren, um Bitcoin-Adressen, um Bitcoin-Transaktionen zu sich umzulenken. Sie wurden zuerst im Jahr 2020 entdeckt und hatten ziemlich große Exit-Gruppen. In diesem Graph könnt ihr sehen, welcher Anteil der Torexits von Ihnen kontrolliert waren in der ersten Jahreshälfte 2020. Die verschiedenen Farben repräsentieren verschiedene Kontakt-Infos, die Sie auf Ihren Relays angegeben haben, um vorzugeben, dass sie verschiedene getrennte Gruppen seien. Die starken Abfälle zeigen Ereignisse, bei denen Sie aus dem Netzwerk entfernt wurden, bevor Sie dann neue Relays hinzufügen. Im Februar 2022 verwalteten Sie mehr als 27 Prozent der Bandbreite der Exit-Relays trotz verschiedener Entfernungsversuche über fast ein Jahr. Irgendwann in der Zukunft haben wir hoffentlich den HTTPS Only-Modus im Torbrowser als Standard, um diesen Angriffsvektor für immer zu beenden und bösartige Exits weniger lukrativ zu machen. Ich möchte euch anregen, dass Ihr HTTPS Only im Torbrowser testet und Website-Betreiber Ihnen hinweist, wenn Ihre Sites damit nicht funktionieren. Wenn eine Website nicht HTTPS Only unterstützt, wisst Ihr, dass sie wahrscheinlich von vornherein unsicher ist. Das zweite Beispiel, als KAX17 erfasst, ist immer noch ein wenig rätselhaft und das ist keine gute Situation. Es ist aufwändig wegen Fokus auf Non-Exit-Relays, Ihre Netzwerkvielfalt mit mehr als 200 verschiedenen 16er Subnetzen wegen Ihrer Größe. Dies ist der erste mir bekannte Fall mit mehr als 100 Gigabit pro Sekunde Non-Exit-Bandbreite, der erste mir bekannte Fall. Und Sie sind schon seit sehr langer Zeit aktiv. Schauen wir uns einige Ereignisse an, im Zusammenhang mit KAX17 in den letzten zwei Jahren. Ich entdeckte und berichtet über Sie zuerst an das Torprojekt im September 2019. Im Oktober 2019 wurden KAX17 Relays zum ersten Mal durch die Torverzeichnungsverwalter entfernt. Im Dezember 2019 veröffentlichte ich den ersten Blog-Post über Sie. Zu dieser Zeit bauten Sie Ihre Infrastruktur wieder neu auf, indem Sie neue Relays hinzufügen. Im Februar 2020 kontaktierte ich eine Email-Adresse, die auf einigen Relays verwendet wurden, die Ihre Relay-Gruppe nicht ordentlich über die MyFamily-Einstellung deklarierten. Damals sagten Sie, dass Sie stattdessen Bridges betreiben würden, sodass Sie MyFamily nicht setzen müssen. Eine Nebenbemerkung, MyFamily ist auf Bridges nicht unterstützt. Mir waren nicht klar, dass diese Email-Adresse mit KAX17 verbinden ist bis zum Oktober 2021. Im ersten Jahresheft 2020 habe ich regelmäßig große Anzahlen von Relays dem Torprojekt berichtet und sie wurden schnell entfernt bis Juni 2020, wenn die Verwaltung Ihre Praktiken änderte und keine Entfernung mehr durchführte, weil sie neue, mögliche Relay-Operatoren, Betreiberinnen nicht abschrecken wollten. Im Juni 2020 nahm eine Email-Adresse an eine Diskussion auf der Tor-Relays-Mailing-Liste teil, die ich gestartet hatte, über einen Vorschlag, große Angriffe auf das Netzwerk zu begrenzen. Inzwischen ist bekannt, dass diese Adresse mit KAX17 in Verbindung steht. Weil die Tor-Verzeihnungsverwaltung nicht mehr Relay-Gruppen entfernte, schickte ich Informationen über mehr als 600 KAX17 Relays an die öffentliche Tor-Talk-Mailing-Liste. Im Oktober 2021 wurde ich angesprochen mit der Bitte um Anonymität und mir wurde eine neue Methode zur Verfügung gestellt, um Tor-Relay-Gruppen zu erkennen, die nicht die Standard-Tor-Software verwenden. Mit dieser Methode konnten wir KAX17 ein zweites Mal erkennen. Dies hat offenbar auch die Tor-Verzeihnungsverwaltung überzeugt und im November 2021 gab es eine große Relay-Entfernungsaktion. Leider war die Zeitspanne in der KAX17 ohne Einschränkung Relays betreiben konnte ziemlich groß. Deshalb wollten wir einen Verfahren entwerfen, dass diese komplette Abhängigkeit von der Tor-Verzeihnungsverwaltung überwindet, wenn es um Sicherheitsfragen geht. Und wie ihr vielleicht erraten habt, mit KAX17 bauen ihre Positionen bereits wieder aus. Hier sind einige Charakteristika von KAX17. Nach der Veröffentlichung meines zweiten Blog-Postings im November 2021 waren die Medien schnell zur Hand mit Worten wie staatliche Akteure und advanced persistent threats, also andauernde, fortgeschrittene Bedrohung. Ich habe vorgekommen vorstellen, dass solche Entitäten so nachlässig sein würden. Weil sie immer wieder behaupten, für einen ISP zu arbeiten, ein Internet-Service-Provider in ihren Mails, schaute ich mir die Verteilung ihrer autonomen Systeme an. Offenbar arbeiten sie für mehr als einen Internet-Service-Provider. Der Graf zeigt autonome Systeme sortiert nach den IP-Adressen, die bei diesem Roster verwendet wurden. Es wurden mehr als 400 IP-Adresse bei Microsoft verwendet. Das sind keine genauen Zahlen, weil nur Relays enthalten sind seit Fall 2019 und es gibt wahrscheinlich mehr. Wenn wir ihre IP-Adressen auf Länder abbilden, dann erhalten wir dies. Aber diese Karte sollte nicht zu ernst genommen werden, weil die GUIP-Datenbank hier, die verwendet wurde, sehr veraltet war und solche Datenbanken sind nie völlig genau, aber es gibt uns eine Idee. Zur Klarstellung. Ich habe keine Belege, dass KAX-17 irgendwelche Angriffe gegen Tor-User ausführt, aber es ist schon ein wesentliches Risiko, wenn auch ein gutartiger Betreiber seine mehr als 800 Tor-Relays nicht als Family kennzeichnet. Ein guter Schutz sollte gleichermaßen gegen gutartige und bösartige Civil-Angriffe funktionieren. Der stärkste Hinweis für die Risikoeinschätzung in diesem Fall ist, dass nicht die offizielle Tor-Software auf den Relays ausgeführt wird. Es gibt noch viele offene Fragen und die Analyse von KAX-17 dauert an. Wenn ihr Input habt, kontaktiert mich gerne. Nachdem wir einige Beispiele von bösartigen Akteurinnen angeschaut haben, möchte ich kurz zusammenfassen, was einige Probleme sind. In dem Ansatz, wie wir zur Zeit das Problem bösartiger Relays behandeln. Es ist so ziemlich wie das Spiel Wack-A-Mow. Du raust drauf und sie kommen wieder, du raust noch mal, und sie kommen noch einmal und so weiter und so weiter. Und dabei trainierst du sie auch so, dass sie beim nächsten Mal noch stärker werden. Bösartige Akteure können Relays betreiben, bis sie erwischt oder bemerkt werden, oder bis sie ausreichend verdacht bei der Torverzeichnungsverwaltung erwecken und entfernt werden. Wenn dein Bedrohungsmodell nicht zudem der Torverzeichnungsverwaltung passt, hast du Pech. Oder du musst deine eigenen Ausschlusslisten führen. Der Versuch, formale Kriterien zu entwickeln, Verhaltensverbote zu deren Durchsetzung, sich die Torverzeichnungsverwaltung verpflichtet, das war erfolglos, dass eine Person beteiligt war, die Co-Entwicklung bei Tor gemacht hat. Es ist Zeit für einen Paradigmenwechsel. Die momentanen Verfahren zur Erkennung und Entfernung von bösartigen Akteuren lassen uns um Stich und sind nicht auf Dauer tragbar. Bösartige Gruppen sind in den letzten Jahren größer, schwerer erkennbar, schwerer entfernbar und beharrlicher geworden. Hier sind einige Designziele. Anstatt diesen einseitigen Wettlauf mit bösartigen Akteurinnen fortzusetzen, möchten wir User zur Selbstverteidigung ermächtigen, ohne dass die bösartige Relays selbst erkennen müssen und ohne allein von Torverzeichnissen abhängig zu sein. Wir möchten das Risiko der Deanonymisierung verringern, indem wir mindestens einen vertrauten Guard oder Exit verwenden oder beides. Wir erkennen auch, dass es zunehmend unmöglich wird, alle bösartigen Relays mit Köder-Traffik zu erkennen, also möchten wir gar nicht mehr von der Erkennbarkeit von bösartigen Relays zum Schutz der User abhängig sein. Im heutigen Tor-Netzwerk müssen wir hoffen, dass wir keinen bösartigen Guard erwischen, wenn wir die Auswahl treffen. Im vorgeschlagenen Design suchten wir uns stattdessen einen vertrauten Guard aus. Das ist schon im aktuellen Tor-Bloser möglich, indem wir irgendeinen vertrauten Guard als Bridge konfigurieren. Es würde auch unterstützt, vertraute Guards und vertraute Exits zu konfigurieren. Solche, dafür braucht es keine Code-Änderung in Tor, aber es wäre mühsam einzustellen, weil man Relay-Fingerprints konfigurieren muss, kein Wissen über Tor-Betreiber-IDs. Aber was meinen wir eigentlich mit vertrauten Relays? Vertraute Relays werden von vertrauten Betreiberinnen betrieben. Diese Betreiberinnen, von denen nehmen wir an, dass die Relays ohne bösartige Absicht betreiben. Vertraute Betreiberinnen werden durch den User ausgewählt. Users weisen das Vertrauen per Betreiberin zu, nicht pro Relay für Skalierung und um Konfigurationsänderungen zu vermeiden, wenn eine Betreiberin die Relays verändert. Weil Users die vertrauten Betreiberinnen angeben sollte, brauchen wir menschlich lesbare, authentifizierte und global eindutige Identifier für Betreiberinnen. Mit authentifiziert meinen wir, sie sollten nicht fälschbar sein, so einfach wie die aktuellen Relay-Contact-Infos, und die Einfachheit, wenn wir DNS-Domains als Identifier für Betreiberinnen, und wir werden diese wahrscheinlich auf 40 Zeichenlänge beschränken. Wie funktionieren diese authenticated Relay-Operator-ID oder kurz AROI, AROI? Wie funktionieren die? Von der Sicht der Betreiberin ist die Konfiguration eines AROIs einfach erster Schritt. Der Betreiber, die Betreiberin, gibt den gewünschten Domain, den er sie kontrolliert, über die Kontaktinfo von Tor an. Schritt zwei, die Betreiber veröffentlichen ein einfaches Textpfeil über die IANA well-known URL. In diesem Textpfeil sind dann alle Relay Fingerprints enthalten. Falls kein Webserver verfügbar ist, oder der Webserver nicht als sicher angesehen wird, dann können auch DNS-Signite TXT-Records für die Identifizierung verwendet werden. Das ist sehr gut für Skaliberkeit und Verfügbarkeit wegen des DNS-Cachings. Aber weil jeder einzelne Relay seinen eigenen TXT-Record erfordert, wird es länger dauern, als über die URE diese IDs zu verifizieren. Betreiberinnen, die gar keinen Domain zur Verfügung haben, können Freidienste wie Github-Pages verwenden, um das Textpfeil zu veröffentlichen. Aaron Sandler hat zur Bequemlichkeit diesen einfachen Contact-Info-Generator implementiert, sodass Relay-Betreiberinnen nicht die lange Spezifikationen lesen müssen, um diesen Contact-Info-String für ihre Konfiguration zu erzeugen. Für die IROE sind die Felder URL und Beweisproof die einzig relevanten Felder. Es gibt bisher schon über 1000 Relays, die die IROE, die authenticated Relay-Operator-ID, umgesetzt haben. Ohne Stats zeigt ein Icon, falls die Betreiberinnen IROE korrekt implementiert haben. Von den 24 größten Familien gemessen an Bandkreite haben alle außer acht Betreiberinnen bereits die IROE implementiert. Rechts seht ihr einige Logos von Organisationen, die Relays mit einer ordentlich aufgesetzten IROE betreiben. Der wichtigste Unterschied zwischen den Zeilen, die dieses Checkmark-Icon haben und die, in denen die es nicht haben, ist, dass der String in Zeilen, das die den nicht das Checkmark haben, beliebig gefälscht werden könnten. Dieser Graph zeigt die größten Exit-Betreiberinnen, die die IROE implementiert haben. Aber ich möchte einen wichtigen Punkt über IROE betonen. Authentifiziert darf nicht verwechselt werden mit Vertraut. Bösartige Betreiberinnen können auch ihren Domain authentifizieren und sie tun es. Eine bestimmte IROE kann vertrauenswürdig sein oder nicht. Das ist die Angelegenheit der User. Aber IROE ist anstatt Kontaktinfos zu Vertrauenszuseisen zu verwenden, ist entscheidend, weil Kontaktinfos nicht direkt vertraut werden können ohne weitere Tests. Dieser Graph zeigt, welcher Anteil der Exit-Kapazität oder Bandbreite diese IROE in Laufe der Zeit implementiert haben. Wir sind jetzt bei etwa 60 Prozent. Aber bei der Guard-Bandbreite haben wir sehr viel weniger, etwa 15 Prozent. Der Grund hierfür ist, dass Exits vor allem von großen Betreiberinnen und Organisationen betrieben werden und Guards von sehr viel mehr Menschen betrieben werden. Es gibt etwa 1.800 Guard-Familien, aber nur etwa 400 Exit-Familien. Wie verwendet ein Tour-Client IROEs? Die aktuellen Tour-Versionen wissen nicht, was IROEs sind und sie verwenden hauptsächlich Relay Fingerprints als Input für ihre Konfiguration. Wir brauchen also irgendein Werkzeug, um eine Liste von Fingerprints zu erzeugen, eine Liste von trusted, von vertrauten IROEs. Wir haben einen schnellen und unsauberen Proof-of-Konzept implementiert, der alles zusammenbringt, um zu zeigen, wie vertraute IROEs konfiguriert werden können im Tour-Client, um vertraute Exit-Relays zu verwenden. Dies soll nicht bei End-User-Rennen verwendet werden. Das ist nur eine Vorschau für die technisch Interessierten, um zu sehen, wie dies wirklich in Aktion ist und das Design besser zu verstehen. Der aktuelle Proof-of-Konzept führt alle Überprüfungen selbst aus, ohne sich auf Drittparteien zu verlassen. Aber es gibt viele Gründe, diese Überprüfungen zentral auszuführen, z.B. durch die Verzeihungsverwaltung. Und deswegen habe ich vor Kurzem einen teilweise Vorschlag dafür auf die Tour-Development Mailing Liste geschickt, um zu sehen, ob dies berücksichtigt werden wird, bevor ich eine ernsthaftere Implementierung des aktuellen Proof-of-Konzepts anfange. Ich finde es immer wichtig, ein gemeinsames Ziel zusammen mit dem Upstream zu erreichen und das zu versuchen, bevor ich eine Lösung entwickle, die außerhalb gepflegt wird. Wenn die Lösung im Upstream integriert ist, können Verbesserungen besser gepflegt werden und die Nutzungsfeindlichkeit ist wahrscheinlich besser. Hier ist ein Link zu der E-Mail an die Tour-Dev Mailing Liste für alle, die das verfolgen wollen. Zusammenfassung. Nach einem Blick auf echte Beispiele von bösartigen Akteurinnen sind wir zu dem Schluss gekommen, dass die aktuellen Ansätze, Risiken durch Relays zu minimieren, nicht den Erwartungen der User entsprechen könnten, eventuell auf lange Sicht nicht nachhaltig sind und eine Aktualisierung benötigen, um die Abhängigkeit von der Erkennung bösartiger Relays zu vermeiden, weil dies immer schwerer wird. Wir haben ein Design vorgestellt, um aktuelle Ansätze gegen bösartige Relays zu erweitern, durch vertraute, authentifizierte Relay-Operator-IDs. Wir haben gezeigt, dass der Großteil der Exit-Bandbreite bereits über AROIs läuft, aber bei der Gartbandbreite ist der Anteil deutlich geringer, was auf einen Mangel an Wissen hinweist, darüber wer die Gartbandbreite betreibt, wer die Gart-Relays betreibt. Wenn ich vor einem großen Publikum öffentlich über Änderungen in der Routenauswahl in Tor spreche, dann sehe ich es als meine Verantwortung, explizit zu sagen, dass die Konfigurationsoptionen zur Routenwahl nicht geändert werden sollten, ohne einen klaren Bedarf auf Grundlage eines persönlichen Bedrohungsmodells, um nicht aus der Masse herauszufallen. Die Nutzung vertrauter AROIs hat definitiv Nachteile, zum Beispiel Load Balancing, um nur eines zu nennen. Dank einer Vielzahl großer Vertrauter Exit-Betreiberinnen sollte es bald möglich sein, vertraute Exits zu benutzen, ohne auf trivial erkennbare Weise aufzufallen. Es ist schwerer, im Sinne von braucht länger, einen Tor-Klein zu erkennen, der seinen Pool von Exits verändert hat, wenn er nur einen kleinen Anteil von Exits ausgeschlossen hat. Wenn ein Tor-Klein auch bei Garts nur eine Teilnahme benutzt, ist dies nur auf sehr viel längere Sicht erkennbar, als bei einer Teilmenge von Exits, weil Garts nur sehr viel seltener gewechselt werden als Exits. Und zum Schluss, wenn Kleins vertraute AROIs nutzen wollen, dann brauchen sie einen Weg, diese zu finden. Idealerweise wird es einen sicheren Weg geben, diese kennenzulernen. Es gibt eine frühe Version, einer Spezifikation dafür, die auf dieser Folie verlinkt ist. Ich möchte diesen Vortrag Carsten Lösing widmen, der im letzten Jahr verstorben ist. Er war die freundlichste Person, mit der ich in der Tor-Gemeinschaft in Kontakt kam. Carsten leitete das Tor-Metrics-Team und ohne seine Arbeit meine Projekte ohne Stats und ohne Raider würden nicht existieren. Man immer ihr Metrics.top-project.org nutzt. Zum Beispiel die sogenannte Relay-Suche nutzt ihr seine Hinterlassenschaft. Danke fürs Zuhören und ich freue mich wirklich auf eure Fragen. Ich bin nicht sicher, ob ich den Fragen in Echtzeit antworten kann, aber es wäre schön, sie vorgelesen zu bekommen, sodass sie Teil der Aufzeichnung werden. Ich nehme auch gerne Hinweise über ungewöhnliche Dinge, die ihr im Tor-Netzwerk beobachtet. Und das schätzt nicht eure Macht als Turbenutzerinnen zu einem sicheren Netzwerk mit Berichten über Unregemäßigkeiten beizutragen. Die meisten großen abwärtsige Aktionen gegen bösartige Akteurinnen kamen von Userberichten. Danke sehr viel für diesen sehr informativen Gespräch. Wir switchen jetzt zu der Q&A. Danke wieder. Sehr faszinierend. Wir haben mehrere Fragen von unseren IRC-Aktüern begonnen. Wir haben viele Fragen von unseren IRC-Aktüern. Wir haben viele Fragen von unseren IRC-Aktüern. Also, ich beginne. Wenn Bridges nicht meine Familie nötigen, ist das nicht eine weit offene Lücke für Ende-zu-Ende-Kommunitionsangriffe, wo ein bösartiger Akteur irgendwie Bridges beliebt machen kann. Ja, aber Bridges sind schon lang im Kontext von meiner Familie, aus dem Grund, dass es nicht auf hohe Bridges und Exzits gleichzeitig zu betreiben, zumindest in der Akteurinversion von Tor. Zukunftige Versionen von Tor werden ein neueres und mehr betreiberfreundliches MyFamily-Setting beinhalten. Das wird vermutlich ab Tor 0.4.8 irgendwann ab 2022 verfügbar sein. Welche Art von Angreifen gibt es Statistiken? Wer aus welchem Land herraus diese Angriffe kommt? Ja, da kommt diese Frage. Es gibt Gerüchte über NSA betriebene Exzit-Nords. Ich weiß nicht über allgemeine Schmerzen, aber ich weiß nicht mehr, wenn ich melde, in meinen Blocks zu sprechen. Es gibt auch autonome Systeme, die dafür bekannt sind, sich in der Menge zu verhindern, reguläre ISPs, wie Hetzler oder Hetzler. Das ist eine schwierige Frage. Es ist auch davon abhängig, dass noch plötzlich so meine privat betriebene Brücke handelt, die nicht über BridgeDB veröffentlicht wird. Ich würde behaupten, dass es besser die Brücken, die man selbst benutzt, nicht selbst zu betreiben. Okay, was ist schlimmer? KX-17? Oder gut bekannte effektionswürdige Betreiber betreiben 20 % des Tor-Exit-Systems. Im Moment würde ich sagen, KX-17 ist schlimmer. Ist die Anonymität nicht verändert, wenn man eine effektionswürdige Regaliste verwendet? Ja, das ist allerdings ein Trade-off. Dass die Nutzer machen müssen. Das sinkt auch stark für den Betrobs-Nudel ab. Okay, ich denke, wir haben alle Fragen. Vielen Dank.