 Danke, dass ihr hier seid. Dieser Talk handelt über eine neue Entwicklung in der großen Firewall von China, eine Zusammenarbeit zwischen einigen Leuten, vor allem Roya und David, die beide fantastische Forscherinnen sind, die den guten Kampf kämpfen und Technik und Überwienung der Firewall machen. Sie können leider nicht hier sein. Sie haben es nicht nach Hamburg geschafft. Ich bin der Backup derjenige, der die Arbeit präsentiert und ich hoffe, ich werde Ihnen gerecht werden. Nun, während wir über die große Firewall reden, wir reden über die große Firewall von China und in der Wissenschaft wurde eine Menge Zeit schon verwendet, die Systeme in den letzten paar Jahren zu erforschen. Also es gibt hier eine Bibliografie, die ich pflege und es gibt inzwischen ein recht gutes Verständnis von vielen Aspekten dieses Systems. Wir wissen zum Beispiel, was blockiert wird. Wir haben Listen von Schlüsselwörtern, von Domains, von UALs, die alle blockiert werden, wenn ihr versucht, sie in China zu ... Wir haben auch ein Verständnis darüber, wie dieses Ding arbeitet. Zum Beispiel, wir haben TCP-Reset-Segmente eingestreut, um Verbindung zu schließen, das gleiche gilt für DNS. Es ist ein bisschen eine größere Herausforderung, aber wir wissen, wo diese Systeme im Netzwerk sind. Es hat da ein bisschen hin- und hergegeben in den letzten Jahren, wir waren teilweise nicht sicher, ob es über die ganzen Provinzen die zentralisiert ist oder ob es sich aber als zentrales System im Werkbau und im Rückgrat des Netzwerks handelt. Wir haben ein besseres Verständnis bekommen. Wir sind ganz gut darin, aber das große Problem ist, dass es immer noch schwierig ist für uns mit fortlaufenden Messungen, fortlaufenden Messungen zu machen. Die sind also alles einmalige Messungen. Wir bekommen die Daten, komplicieren sie, aber es könnte sich morgen wieder ändern und vielleicht nacken man das. Meine Co-Altoren zum Beispiel arbeiten daran das zu ändern, indem sie Systeme vorschlagen, die fortlaufen, messen können, wie die Zensur sich in der Zeit verändert. Bevor ich also mit dem zentralen Teil starte, möchte ich euch einen Kurs über die üblichsten Methoden der Zensur in China überbittgeben. Viele Domains sind blockiert. Dies ist also das ganz normale DNS-Blocking oder DNS-Proisening, das ist nicht besonders dran. Wenn jetzt jemand einen Web-Server außerhalb von China zugreifen will, innerhalb von China sitzt, dann ist ein Traffic wesentlichen, also mit der liegt einer Deep-Packet-Inspection. Also wir haben hier ein, diese, das Alkeneer, das ist ein Deep-Packet-Inspection-Gerät und in deinem Datenstrom werden dann Muster erkannt, das vielleicht ein Muster entspricht und dann gibt es eine falsche Antwort. Ich habe diese IP-Adressen nicht erfunden, also was hier passiert, wenn man mit China Facebook zugreifen will, dann bekommt man eine chinesische IP-Adresse zurück, die keinen Sinn ergibt. IP-Adressen gibt also einen Satz von etwa zehn IP-Adressen, die gerne zurückgegeben werden, um hier umzuleiten. Wir wissen nicht genau, warum es zehn sind, aber das ist die Art von DNS-Prosening, die sie machen. Und interessanterweise ist es so, dass es gibt ein Client, wenn man lange genug wartet, mehrere Millisekunden, dann bekommt man mit diesem Client tatsächlich auch die originale IP-Adresse. Das ist das seltsameste, denn wenn jetzt in China sitzt und eine blockierte Domain aufsuchen wollen, bekommt jetzt tatsächlich zwei Antworten. Das ist also in Wirklichkeit eine Race-Condition. Die Fiber versucht, die intensierte Antwort schneller zu geben als die echte Antwort für diesen Webserver. Und dies funktioniert ziemlich gut für die Firewall, nicht immer. Manchmal kommt die Ursprüngliche, die die echte Antwort schneller an und dann funktioniert die Sperre nicht. Aber grundsätzlich bekommt man zwei Antworten und die frühere normalerweise gewinnt. Das ist also nichts wahnsinnig Besonderes. Es gibt außerdem Schlüsselwörter, die blockiert werden. Wenn also die Bissewörter im DNS-Request blockiert werden, wieder gibt es ein Die-Packet-Inspection-Gerät, dass deinen Get-Request sich anschaut, also nicht in den Mainz, sondern in der URL. Die Geschichte ist aber genau die gleiche. Wieder eine Race-Condition, sie versuchen einfach, dieses Resets-Segment, den Browser zu senden, bevor die eigentliche Webseite zurückkommt. Man könnte nun sagen, dass man das überwinden kann, aber DNS ist immer noch grundlegend das Problem und die wirkungsvollste Aktion den HTTPS, was man verwenden könnte, um diese Keyword-Blockade zu überwinden, ist immer noch abhängig von einer frühen DNS-Lookup. Man nimmt also jetzt als Lösung den gesamten Netzwerk Traffic und schlägt das ein oder verhüllt das ein in irgendein Protokoll. Es gibt neben der eigentlichen Schutz gibt es noch jede Menge weitere Features, die man damit bekommt. Es gibt verschiedene Tools, die versuchen also den Traffic einzuhüllen, um den DNS, den Die-Packet-Inspection-Boxen schwerer zu machen, dort hineinzuschauen. Das ist wirklich ein Problem für den Firework. Datenverkehr, der verschküsselt ist, durch so einen Protokoll, ist schwer. Gas und diese Die-Packet-Inspection-Boxes müssen man mehr oder weniger raten. Was ist in dieser Connection drin? Was ist drin? Ist hier der HTTPS drin oder VPN oder Tor? Es ist nicht völlig unmöglich, dies zu lernen. Man kann einige Indizien anschauen, das offensichtlich sind Portnummern. Wenn es sich um Port 443 handelt, dann ist es wahrscheinlich HTTPS, wenn es 393 ist, ist es vielleicht verschlüsselt. Man kann auch an den Typ der Verschlüsselung auf den Typ der Verschlüsselung schauen. Viele Protokolle benutzen TLS, aber es gibt andere wie z.B. SSH, die haben ihre eigene Krotografie, die sich nicht auf TLS stützt. Wenn man aber nur die Protokolle anschaut, die TLS benutzen, dann kann man immer noch die typischen, die Herstellung der Verschlüsselung anschauen. Viele Protokolle benutzen DLS oder konfigurieren oder setzen es auf auf verschiedene Weise. Wenn man also sehr genau, sehr vorsichtig hineinschaut und diese Unterschiede sich anschaut, dann kann man dies für Blockadeentscheidungen verwenden. Und man kann auch noch versuchen, Traffic Float zu analysieren. Es gibt Timing, es gibt die Richtung, in der die Pakete laufen, all diese Dinge können benutzt werden. All das, was man dadurch bekommt, ist eigentlich nur ein informiertes Raten. Also, wenn man wissen will, dass man blockiert, gibt es eine gewisse Unsicherheit, die bleibt. Und dies ist schlecht für Censur, weil dadurch natürlich auch nebenbei noch weitere Schäden entstehen, Kolatoralschaden. Wer erinnert sich an dieses Problem hier vor ein paar Jahren, als die Firewall Team Traffic zu GitHub beeinflussen wollte? Und ein paar Tage über einige Tage hinweg wurde die Censur schrittweise angehoben und sie scheinen also zu schauen, wie weit sie gehen kann, wie weit sie den Zugriff auf GitHub blockieren könnten, bevor man es an dagegen aufschrie. Es gab einen Punkt zu dem GitHub dann völlig unerreichbar war. Es gab einen, und das lag daran, dass es ein Umgehungstool gab, das auf GitHub gehostet war. Es gab einen Aufschrei, dieses wurde nicht einfach toleriert und zu irgendeiner Zeit wurde dies tatsächlich zurückgenommen und haben GitHub wieder entblockiert. Und das ist ein gutes Beispiel, wie Kolatoralschaden wirklich den Sensoren wehtun. Und es ist wichtig für uns, das zu wissen, wir können unsere Umgehungsprotokolle auf eine Weise entwerfen, dass dieser Kolatoralschaden maximiert wird. Das System, der großen Firewall ist so entworfen, es ist eine kluge Weise entworfen. Sie haben einen Weg gefunden, diese Unsicherheiten zu eliminieren und Sicherheit zu gewinnen, wenn alles, was man hat, eigentlich ein verschlüsseltes Protokoll ist. Und worauf sie gekommen sind, ist aktiv probing. So wir nennen das in unserer Forschung, also aktives Test. Es ist recht einfach zu verstehen, wenn man sich vorstellt, dass eine TLS-Verbindung eine undurchsichtige Verbindung aufgenommen wird zwischen einem Klein in China und einem Server in Deutschland. Die große Firewall im ersten Schritt schaut sich das TLS sehr genau an. Was ist das? Schauen wir uns den Handshake an. Gibt es da Informationen, die man nutzen kann, um etwas zu lernen? Und im Fall von Tor, schaut es nach etwas, was sich die Siphonlist der TLS-Klients nennt. Wirklichen eine Liste, die der Kleint einen Server setzt, um ihm zu sagen, was für Server er supportet. Und stellt sich heraus, dass dies mehr oder weniger einmalig ist für Tor. Tor versucht hier nun sich einzustellen, zwischen Firefox und Apache. Und das geht gut, bis anders passiert. Es ist ein ärgerlicher Spiel, was man nicht spielen muss. Und das ist etwas, was die große Firewall ausmützt. Die denkt vielleicht, schauen wir mal, das könnte eine Torverbindung sein, weil sie nicht völlig sicher ist, könnte eine unbekannte Protokolle noch existieren. Diese genauso aussehen, aber wir haben keine Ahnung. Wir müssen mit Sicherheit haben, oder? Wenn wir jetzt irgendwas blockieren und es ist ein wahnsinnig wichtiges finanzielles Ding, eine Anwendung, dann haben wir nichts wirklich gewonnen. Also was wir tun, im nächsten Schritt ist sie starten einen kurzlebigen Computer, einen kurzlebigen Testcomputer, der denselben Server in Deutschland anpingt oder sich verbindet mit ihm und versucht, das Torprotokoll mit ihm zu sprechen. Das ist ein Ratischspiel, keine Ahnung, ob das funktioniert. Sie versuchen es. Im schlimmsten Fall hat der Server keine Idee, was das für ein Müll ist. Und beendet die Verbindung, aber vielleicht antwortet der Server mit einem Torhandshake. Wenn das passiert, dann hat die Firewall das, was sie braucht. Die DC hat eine Art Köder-Trafik gesendet und die unweisterlich genau, dass es sich um ein Torhserver handelt. Wenn dies passiert, kann man diesen Server blockieren und den Zugriff verhindern. Dies ist also sehr schön von einer ingenieursmäßigen Perspektive aus. Man muss sich jetzt nicht sehr viel um IP-Adressen kümmern und DHCP kramen. So ist es völlig dynamisch. Was man nur tun muss, ist, den Traffic anschauen, während er die Landeshands überwindet, instruzieren und Test starten. Im ersten Schritt ist die Packet Inspection auf sehr viel Traffic und dann ein kleiner Teil des Traffic, der verdächtig ist und um den zu verstehen, gibt es dann aktives Testen. Und ich rede von Torh hier, weil einfach weil das das interessantste Beispiel ist. Es gibt eine Menge andere Protokolle, die auch aktiv getestet werden. Also, das System scheint modular zu sein. Sie können einfach Module für weitere Protokolle schreiben. Was wir diesen Punkt geteilt haben, wir hatten ein Forschungsprojekt und starteten Datensätze zusammen. Der erste Datensatz, den nannten wir am Ende den Schattendatensatz. Dies ist also im Wesentlichen, was man tut, wenn man so etwas hacken möchte, man versucht also Beobachtungspunkte in China zu finden, bei zwei verschiedenen ISPs. Wir haben hier einen großen ISP in China Unicom und CERNET kurz für das chinesische Forschungs- und Bildungsnetzwerk. Und es zählt sich heraus, dass die etwas verschiedenfilterndes interessant ist. Nicht jeder ist also gleich, wenn es um Paketfilter durch China geht. Einige werden mehr gefiltert als andere. Und was wir getan haben, wir hatten dieses System in zwei verschiedenen Netzwerken und dann haben wir also wiederholt Verbindungen aufgenommen zu Bridges, die wir selbst kontrolliert haben. Bridges sind im Wesentlichen Tor Relays, die nicht veröffentlicht werden, um die Zensur zu umgehen. Und wir haben drei verschiedene Arten von Verbindungen aufgenommen. Normale Torverbindungen, die nicht sehr nützlich sind für die Umgehung von Zensuren. Und dann haben wir, was wir OB, FS2 und 3 genannt haben. Das sind Protokolle, die entworfen wurden, um die Zensur zu umgehen. Und das haben wir immer wieder getan, etwa alle Zemene. Und wir haben also eine Menge Verbindungsanfragen gehabt. Und es stellte sich heraus, dass es nicht so hilfreich war, wie wir erwartet hatten, denn wir hatten nicht eine Menge aktives Probing oder Testing, was wir dann beobachten konnten. Wir zeugten dann einen zweiten Danntat zu dem wir den Sibyl hatten. Wir wüssten sich einen kleinen Athena der 600 verschiedene Ports, dass sich an 600 verschiedene Ports verwendet. Er hat im Wesentlichen eine Tabelle verwendet, um die Fireball auszutrickst oder ihr vorzugaukeln, dass man 600 verschiedene Brücken hat, Bridge Server. Und es gab also eine Menge Probing, was wir dann beobachten konnten. Und letztendlich hatten wir dann ein drittes Daten, ein dritten Datendatz, den wir den Log Datendatz nannten. Dies ist ein wesentlicher Einserver, der ist ein Log, falls wir das begreifen. Das ist sehr cool. Wir konnten uns die Logs anschauen und konnten nun über die Zeit feststellen, wie sich das aktive Testen des Probing entwickelt hat über die Zeit. Das erste interessante Ding war, wo all diese IP-Adressen hierher kamen. Wir haben unsere drei Daten jetzt angeschaut und insgesamt hatten wir etwas mehr als 16.000 verschiedene IP-Adressen, von denen das Probing aus geführt wurde. Also eindeutiger, also einmalige, wenig Wiederholung, 95 Prozent wurden nur einmal gesehen. Wir haben die Verslux ausgeführt und haben Strings wie EDSL gefunden. Das sieht aus, ob all diese Adressen oder viele davon von ISP-Pools stammen. Und die DNS-Records, die WHOIS-Records hatten die gleiche Information. Scheint sich also ein großen Pool von ISPs, die sind also nicht die Users, diese Automatisierte Systeme. Das war also sehr seltsam für uns. Und dann gibt es einen Schnittmengen zwischen den Datennetzen und es gibt eine IP-Adresse, die all diese Daten sehr oft auftaucht. Und viele Daten in der Verbindung kamen von dieser IP-Adresse. Die ist also offenbar eine eigene Scanning-Maschine. Die ist jetzt gerade nicht online, probiert es nicht aus. Sie hatte vor kurzem noch, war noch online, hat einen auf den SSH-Port. Aber das sieht zu dir, aber es scheint also ein eigenes, abgestelltes System zu sein, unterschiedlich von allem anderen. Und was dies heißt für uns ist, wir können jetzt nicht einfach eine Blocklist erstellen von aktiven Probes und sagen, stellt das in eure IP-Tables ein und keine Probe mehr wird jemals wieder auftauchen. Die List ist zu groß und sie ist auch nicht vollständig. Also unsere Annahme war, vielleicht kapern sie all diese IP-Adressen. Vielleicht gehören sie in diese Adressen gar nicht. Sie baugen sie nur aus für eine kurze Weile für einen Test und geben sie dann zurück. Es war seltsam. Wir konnten leider nicht schaffen, diese Probes mit diesen Probes zu kommunizieren außerhalb der Testverbindungen, diese selbstimizierten. Also die wurden gefiltert, sie konnten keinen Trace-Foot ausführen zu ihnen. Es gab dann Time Ops, einige Hops vor dem Ziel. Wir konnten zu den Probes keine Gespräche aufnehmen. Also sie redet mit uns, aber ungekehrt war es nicht möglich. Es war also nicht viel Interaktion möglich und wir hatten also dann nur noch die Chance, Muster in all den Daten, die wir sammelt wurden, zu finden. Und wir haben die systematisch versucht einfach von unten nach oben im TCP Modell. Wir haben also zunächst mal in der IP-Schicht nach Mustern gesucht und wir haben hier nicht sehr viel Interessantes gefunden. Es gibt eine relativ enge Verbindung von TTL-Werten, was nicht unbedingt erstaunlich ist, kann mit Routing erklärt werden, aber wir hatten auf den anderen Leeres interessantes Zeug. Also zum Beispiel die meisten dieser 16.000 IP-Adressen nutzen alle 16.000 möglichen Portnormale aus. Man normalerweise in modernen Betriebssystemen nicht findet. Sie nutzen die Anzahl der bekannten Portnummern und nicht mehr, aber hier wurde das alles benutzt. Und wir hatten auch interessante Muster in Timestamp-Werten, aber wir haben hier nicht die Zeit, es findet sich in unserem Forschungspapier. Dies gab uns den Eindruck, dass es hier kein normalen TCP-Stack in dem Kernhahn vielleicht irgendwie programmiert um die Probing-Aktivitäten besser zu skalieren, gewissens nicht genau. Die interessantesten Muster, die wir fanden waren in den Sequenz-Nummern, die zu Beginn der TCP-Verbindung genutzt wurden. Um euch kurz zu erinnern, TCP hat eine 32-Bit-Nummer als Segment-Nummer, und das hat die Schöne eingeschafft, dass man dadurch einen Angriff hat, oder einen Schutz gegen Angreifer, die sich außerhalb des Fahrt befinden, weil es schwer wird, diese Sequenz-Nummer zu raten, und was man nun tut, ist die Initialen Sequenz-Nummer zu randomisieren, zufall. Und das kann man in einem Diagramm aufzeichnen, und hier ist, was man vielleicht erwartet, wenn man eine Menge von Sequenz-Nummern über die Zeit glottet. In der X-Axis die Zeit, und in der Y-Axis ist der Wert der initialen Sequenz-Nummer einer TCP-Kommunikation, jeder Punkt hier ist also ein Startsegment einer TCP-Verbindung, das wir hier gefunden haben. Dies ist also ein reales Beispiel aus einem modernen Linux-Kang. Ich habe das alles extrahiert und hier geplottet, und es scheint sicher mein Zufall, es musste zu handeln, wie man es erwarten würde. Und man würde nun das gleiche Bild eigentlich erwarten, wenn man an die Active-Probes schaut. Also all diese Synth-Segmente, die Initialen-Segmente einer TCP-Verbindung, wo es sich anschaut, sieht man nicht etwa Zufall, sondern dies. Und das ist wirklich seltsam, oder? Ein etwas schräges Muster, man kann dies verbinden, und dann wird es ein bisschen offensichtlicher. Dies ist also ein Zick-Sack-Muster, es geht nach oben, bis es auf die Null zurück geht und diese Sequenz-Nummern sind perfekt korreliert mit der Zeit. Also die Sequenz-Nummern werden von den Zeitstellenbänden abgeleitet. Dies ist auf dem Bar ist was passiert, und das ist sehr interessant. Das ist richtig um eine Maschine hier. Dies sind die Sequenz-Nummern von Hunderten von Maschinen über verschiedenste IP-Adressen. Dies ist also ein zustandsgewundener, mehr odd-Staff in der Zustandung des Verhältn. Man findet auch interessante Sachen im TLS-Layer. Wenn das Protokoll besteht aus TCP und dann TLS und dann das Turr-Protokoll. Also auf dem TLS-Layer, über TCP-Elect, schaut man uns das Klein-Hello an. Und tatsächlich sieht das wieder seltsam aus, nicht was man normalerweise hinschätzt. Es gibt keine zufällig generierte SNI, die wir hier verlesen, die fehlt völlig. Die Verschlüsselungsalgorithmen, die gewählt werden, sind auch nicht normal, sondern was ganz Eigenes. Um euch einen Eindruck zu geben, wir haben hier die Cypher-Sutes auf einem Turr-Guard-Wähler hier aufgezeichnet. Offensichtlich keine IP-Adressen. Alles, was wir haben, hier ist die Frequenzverteilung und die Häufigkeitsverteilung der verschiedenen Verschlüsselung. Und die Spezifischen, die die Test-Probes benutzt haben, ist sehr, sehr un... nicht nur 6,76 Einträge. Also ich weiß nicht, was hier los ist, vielleicht kommen die alle von China. Das ist also nicht etwas, was ein normaler Turr-Client senden würde. Und wenn man dann auf den letzten Layer geht, das ist was zu tun, was Sie, wenn Sie sich mit einem Bridgeverbind nach dem B und TLS hergestellt wurden, ist, was machen Sie da als nächstes? Sie senden einfach eine Version an die Bridge. Und nach der Protokoll-Spezifizierung werden eine Versionsseile und eine Net-Info-Zelle ausgetauscht. Da kommt die Probe, an diesen Punkt macht die Verbindung dann sofort wieder zu. Sie kümmert sich nicht darum, einen echten Turr-Socket, die Turr-Kreislauf zu machen, weil in der Zeitung schon alles bekannt ist, was man wissen muss, eigentlich ist es eine Turr-Bridge, nachdem also Versionszellen ausgetauscht worden sind. Das ist also offensichtlich keine Referenz in der Repetierung eines Turr-Client-Sectives haben. Das scheint doch handgemacht zu sein. Und wie vorher haben wir hier eine Menge von Zustandsleakage, also bekommen mit, was der Zustand ist. Wir haben einige Abschnitte dazu in unseren Forschungspapier, aber leider haben wir keine Antwort. Sie haben Hypothesen, einige sind wahrscheinlich als andere, denken wir, wir wissen es nicht wirklich. Also wenn ihr irgendwelche Ideen habt, solltet ihr mit uns in Kontakt treten, weil wir wirklich so gern wissen, wie das Ganze funktioniert. Eine Hypothese ist, dass es sich um ein Proxen-Netz geht. Ein geographisch verteiltes Set von Proxies handelt über dem ganzen Land. Und dass die Firewall ihren Traffic irgendwie über diese Proxies turnet und sie benutzt, um die Server zu scannen. Ich denke eigentlich, dass das ein bisschen zu viel auffand sei und es einfacher erreicht werden könnte, aber wir können so da ein bisschen widersprüchlich, wir können hier nichts ausschließen. Eine zweite Hypothese ist, dass wir vielleicht einen Server haben, der in einem Rechenzentrum sitzt bei einem Service Provider verbunden mit einem Switch-Port. Immer wenn sie eine IP-Adresse borgen wollen, dann aktualisieren sie irgendwie die Access-Die-Zugs-Liste auf dem Switch und carpan sozusagen die IP-Adresse für eine Weile und benutzen sie und geben sie dann wieder ab. Das ist aber nur eine Theorie, leider wissen wir immer noch nicht, was wirklich los ist. Also, ich habe sehr viel über die Struktur des Systems geredet bisher, aber eine andere Frage ist, wie gut das System überhaupt funktioniert und das ist etwas, wo unser Schatten-Daten-Set sehr nützlich ist. Im Wesentlichen haben wir diese Verbindungen hergestellt, immer und immer wieder und jeder Punkt und diesen Diagramm repräsentiert ein Verbindungsversuch, der es entweder gescheitert oder hat funktioniert. Die oben haben geklappt und die unteren sind die gescheiterten und sowohl für Cernet als auch für Unicom haben wir diese Datensets und diese Verbindungsversuche. Und die sehr, sehr coole Sache hier ist, schaut euch die obere Linie bei beiden an. Manchmal funktionieren die Verbindungen einmalig und 24 Stunden später funktioniert es noch einmal, einmal also es ist ein sich wiederholendes Muster von Verbindungen von einer Torverbindung, die man herstellen kann, alle 24 Stunden. Das ist sehr merkwürdig, oder? Wieder, auch hier, wir wissen nicht, woran es liegt. Es gibt verschiedene Theorien, vielleicht flaschen sie ihre Blocklists alle 24 Stunden und updaten sie dann und vielleicht dauert das einfach ein paar Minuten und in dieser Zeit können Leute einfach machen, was sie wollen. Das ist eine mögliche Theorie. Und immerhin sieht es aus, als ob das alles von Akademikern einfach gemacht wird von daher, vielleicht sollte die uns glauben und nicht den Operators der Firewall. Also das ist, was die Effizienz angeht. Und wie schnell sind diese Probes? In 2012 sah es aus, als ob sie in Gruppen verarbeitet wurden. Es sei ein bisschen aus, ob es einen Job gab, der auf dem System lief und alle paar Minuten, wo dieser Cron Job aktiviert und hat diese Probing Tasks durchgeführt. Und das schien sehr gut zu funktionieren. Das hier ist eine Visualisierung davon aus 2012. Und anscheinend wurde das System verbessert. Von nicht allzu langer Zeit. Und sie haben es im Wesentlichen in eine echte System umgewandelt. Das ist sehr interessant. Auf der X-Achse seht ihr die Ports, unseres Datensets, von 0 bis 600. Also für jeden Port seht ihr, wie lange die Firewall gebraucht hat, um eine Probe zu uns zu schicken. Und die Verspätung, die Dauer ist auf der Y-Achse. Und ihr seht, die meisten Punkte sind sehr weit unten. Es gibt sehr schnell eine Probe. Da sind es nur 500 Millisekunden. Die meisten Probes brauchen nur eine halbe Sekunde von der ersten Verbindungsversucht, um diese wirklich mit einer Probe anzugehen. Also das scheint sehr schnell zu gehen und sehr effizient zu sein. Aber es gibt einige Outlier, einige Abweichungen, die wir nicht ganz erklären können. Ihr seht diese Anstiege, die dann plötzlich linear absteigen. Wir sind nicht ganz sicher, woher das kommt. Wir glauben, dass wir von diesen wahrscheinlich Imlimitationsartifakten repräsentieren. Aber im Wesentlichen, wir machen die Qualitätskontrolle für den Great Firewall gerade, deswegen können wir das auch nicht sagen. Also so viel zum Design des Systems. Ich habe nur über Tor geredet bisher, einfach, weil das ein sehr guter Beispiel ist. Also immerhin haben sie da sehr viel Arbeit reingesteckt, aber es gibt auch noch sehr viele andere Protokolle, die von diesen Probes untersucht werden und von der Firewall. Und das ist eine nicht vollständige Liste. Es sieht ein bisschen aus, als ob es in 2011 angefangen hat, als jemand einen Artikel geschrieben hat und darüber geschrieben hat, wie er merkwürdige SSH-Pakete aus China mit anscheinend das war damals, war man nicht so sicher, was es war, oder wofür es benutzt wurde, aber anscheinend waren das einfach Probes und es war einfach Probing. Probing bedeutet nicht, dass es auch etwas geblockt wird. Es kann auch sein, dass es Probing gibt, wo niemals etwas geblockt wird. Manchmal ist vielleicht einfach nur experimentiert. Dann gab es Probing bei OpenVPN für eine Weile, bei SoftEther, das ist Teil des VPN für Protokolls. Über Tor habe ich schon geredet. Auch für Google's App-Spot. Da gab es einen kleinen und sehr, sehr gutes Umgehungstool namens GoAge. Ich glaube, vielleicht haben sie diese Probing- Aktivität aktiviert, um das zu entdecken. Also vielleicht ist da mehr. Ich bin mir ziemlich sicher, dass da mehr ist. Also vielleicht, wenn ihr irgendwelche Ideen habt, dann kontaktiert uns gerne. Und wir haben uns auch etwas sehr genau angeguckt, wie die RAID5 mit OBFS2 und OBFS3 umgeht. Und es dauert nicht sehr lange, um herauszufinden, dass es da Anomalien gibt. Und es sieht wieder so aus, als ob sie einfach keine Referenz in der Präventierung nutzen, was mich eigentlich überrascht. Denn all diese Software, die Sie versuchen, hier zu proben, von Tor über das OpenVPN, das ist alles freie Software, oder? Man kann das einfach herunterladen und in seinen Probing-System einbauen und laufen lassen. Aber trotzdem aus irgendeinem Grund scheinen all diese Dinge handgemacht zu sein, vielleicht für mehr effizient. Oder niemand wollte vielleicht herauskriegen, wie man die Originalsoftware gut nutzt. Aber das seltsame, das ironische ist, dass dieses Handmachen es möglich macht, die ActiveProbes zu Fingerprinten, nachdem diese Fingerprints angefertigt haben von unseren Servern. Denn einig dieser Protokolle, also enthüllend Zustände, was wir Parfunken haben ist zum Beispiel, dass das Padding das in OBFS2 und 3 nutzt wird, ein bisschen verschieden, nicht genau nach Spezifizierung, sondern statt einem TCP-Segment oder zwei, statt zwei TCP-Segment, wird eines gesendet. Es gibt Zwelle von doppeltem Payload, was man eigentlich nicht filmen sollte in den Daten, weil das Payload eigentlich gleich verteilt sein sollte. Oft kommt man also das gleiche Payload von zwei verschiedenen IP-Adressen. Und selbst für eine einzige sollten also Verschneidung sehr, sehr gering sein. Und wir hatten also zwei verschiedenen IP-Adressen mit gleichen Payload. Also hier werden Zustände wirklich quer durch die Bank in Protokollen offengelegt in der Kommunikation. Wir haben hier also so was wie das. Log eines Web-Service uns angeschaut und haben uns angeschaut, wie das Probing über die Zeit sich entwickelt hat. Und wir haben dann also am Ende dieses Diagramm hier erzeugt und konnten eine Menge von Probes in den Daten infizieren. Wir sind recht sicher, dass wir hier keine falschen Positiven haben, also dass das, was wir sehen, wirklich nur Probes sind. Es geht hier zurück bis 2013 und viele der Protokolle beziehen sich einfach darauf, wie oft wir etwas einem bestimmten Tag gesehen haben. Und das gibt eine gewisse Idee, wie die Firewall sich über die Zeit entwickelt. Wie gesagt, es ist nicht völlig, es ist nicht ein völlig vorstellenes Diagramm, aber wir können etwas lernen davon. Bis zum Ende von 2013 gab es offenbar eine Menge von Probing und dann für einige Monate hat es fast vollständig aufgehört. Es gibt einen kleinen Fluss noch von Probing, aber wir wissen nicht, was sich hier getan hat. Es gab also wirklich kaum Probing. Dann sehen wir auch neue Protokolle eingeführt werden und vielleicht einfach gekastet werden hier. Es ist sehr cool zu sehen, wie diese Dinge über die Zeit anfangen zu passieren. Aber wieder mit einem Kornsalz ist es nicht vollständig. Es gibt bestimmt noch mehr als das, was wir hier einfangen konnten in diesem Diagramm. Und auf unserer Projekt- Website haben wir auch Anweisungen. Ihr könnt auf euren Websites oder auf euren Boxen hier Code ablaufen lassen, um Probes zu finden. Also das ist so etwas einfaches vielleicht, wie nach bestimmten Postrequests zu greppen, in den Logs zu greppen, oder T-Sepidump für diese seltsame IP-Adresse ausführen. Sie scheint im Moment nicht aktiv zu sein diesen Tagen, aber dies wäre also ein sehr einfacher Weg, um ein interessantes Zeug zu bekommen. Und ihr könnt nicht nur nach Umgehungsprotokollen suchen, sondern vielleicht gibt es also noch weitere Informationen, die ihr herausfinden könnt. Und das Interessante hier über das aktive Probing, das es aktiv ist. Also viele Sensorsysteme tendieren dazu völlig passiv oder meist passiv zu sein. Sie sitzen da, warten auf verdächtigen Traffic, und dann beenden sie die Verbindung oder vielleicht lassen die Protokolle blockieren. Also sie machen irgendwas um die Verbindung zu verhindern. Mehr oder weniger passiv, man kann nicht wirklich interagieren mit ihnen. Dies ist komplett anders bei diesem Aktiv Probing, wie der Name schon sagt. Dies ist ein aktives System, das sich mit dir verbindet, es mit dir redet. Das muss es tun, denn sonst kann es nicht blockieren. Das Interessante hier ist, die Natur, diese aktive Natur macht es möglich auf unerwartete Weise damit zu interagieren. Wir haben keine komplette Liste, aber es gibt ein paar Dinge, die man machen kann, um das Leben des Aktiv Probing ein bisschen schwerer zu machen. Also eine Sache ist, wie groß ist die Blockliste, die sie haben? Wir hatten diesen Diszipldatensatz und hatten etwa 600 Ports, wir hatten 600 Verbindungen von 600 Ports zu einem bestimmten Torport, 600 neue Einträge in der Blockliste. Das ist natürlich noch nicht so viel, jeder Computer hat mehr als 60.000 Ports, das kann man benutzen, also jede einzelne IP-Adresse kann 60.000 neue Einträge in die Blockliste hinzufügen. Das ist was man mit einer Adresse tun kann und dann kann man natürlich einfach horizontal skalieren. Ein einfaches 24-Netzwerk kann mehr als 60 Millionen Adressen hinzufügen, also relativ einfach das Limit, relativ schnell zu erreichen. Das ist ähnliches für Falldeskriptoren tun. Falldeskriptoren sind durch das Betriebssystem vorgeschrieben, wir wissen nicht, was die Grenzen sind für jedes System, aber einfach indem man viele Verbindungen aufbaut und sie offen hält, kann man vielleicht sich diesen Limit annähern. Also einfach eine Menge Probes auf sich ziehen und diese da nicht weggehen lassen. Schickt einfach keine Daten. Nehmt sich diese Verbindung auf, aber sendet keine Daten, lasst die Verbindung offen. Irgendwann gibt es dann wohl Timeouts, man muss also hier auch wieder horizontal skalieren, aber es ist aber nicht klar, was passiert, wenn das System jetzt keine Falldeskriptoren mehr hat. Wird es einfach aufhören, weitere Systeme zu testen, oder ist es nicht klar, was passiert? Das ist also ein Weg, um einfach zu verhindern, dass das neue Umgebungsserver auch blockiert werden. Und mein persönlicher Liebling ist wahrscheinlich dieser hier. Ich muss hier eine Ehre geben, den Autoren des VPN-Gate-Papiers. Das ist wirklich großartig. VPN-Gate ist ein Umgehungssystem, das auf VPN-Server aufbaut. Die Idee ist, dass man eine Menge VPN-Server hat. Ich denke, Sie haben mehr als 100 über den ganzen Globus verteilt und gibt diese Liste dann den Nutzern, die Zensur umgehen und sie suchen sich einen VPN-Server aus, der für sie funktioniert. Wenn du nun die Great Firewall, die große Firewall verwaltest, dann würdest du einfach einen Grundjob aufsetzen, der diese Liste jeden Tag sich zieht und sie einfach der Blockliste hinzufügt. Sehr einfach. Aber das Ding ist, das gibt den Menschen, die VPN-Gate ausführen, Kontrolle über die Firewallen, oder denjenigen, die diese Blockliste, die IP-Adress, nicht die Blockliste, die IP-Adress-Liste verteilen. Man kann also dann die IP-Liste der großen Firewall kontrollieren. Was verrückt ist irgendwie, oder? Es geht hier nicht nur um die IP-Adressen von VPN-Servern, es geht einfach um IP-Adressen. Was passiert also? Wenn ich jetzt Windows Update als IP-Adresse hier einführe, dann kann auf einmal ganz China keine Windows-Updates mehr machen, denn die IP-Adressen sind geblockt. Das gleiche gilt für DNS Rootserver. Man kann also ein DNS für ein ganzes Land auf einmal brechen, oder die Google-Infrastruktur. Und dies wurde nun in großer Tiefe diskutiert in den VPN-Gate-Papieren. Es gibt ein mehrere Abschnitte darüber, in denen dieses Katz- und Maus-Spielen sehr genau beschrieben wird. Es ist wirklich sehr schön, das zu lesen. Tag 1 taten wir dies. Die große Firewall-Regel. Das ist so am nächsten Tag. Und letztendlich dauerte es so zwei bis drei Tage, bis die Verwalter der Firewall bemerkten, dass also auf diesen Wege beliebige IP-Adressen in den Blockchain eingeführt wurden. Und von da an starteten Sie die IP-Adressen zur Wertefizierung. Es ist nicht ganz klar, wie wir wahrscheinlich prüfen, wem die Adressen gehören. Versuche sich mit ihnen zu verbinden. Auf jeden Fall schluckten wir nicht einfach mehr ohne Weiteres, was man der Firewall gab. Dies ist also mein Favorit, wie man mit der Firewall ein bisschen spielen und sie ein bisschen durcheinander bringen kann. Also wir haben darüber geredet, wie das System arbeitet, aber noch nicht sehr viel, wie man es umgehen kann. Es zeigt sich, dass nicht alles verloren ist, und wir haben immer noch Wege, Wege, die wir nutzen können, um die Konnektivität in China zu entflussen. Eines, was man tun kann, ist, sich anzuschauen, wie die große Firewall mit TCP-Segmenten umgeht. Wenn wir über die Packet-Inspection reden, dann drehen wir viel über Pattern-Matching, muss da ein TCP-Segmenten, aber es ist da noch sehr viel mehr drin. Man muss den TCP-Stream wieder zusammensetzen, was nicht trivial ist, wenn man zu tun hat, mit Netzwerkpaketen, die handgefertigt sind, um dies sehr, sehr schwer zu machen. Das kann man machen. Also absichtlich es schwer zu machen, die TCP-Segmente wieder zusammenzufügen. Und wir haben dies also vor einer Weile schon ausgenutzt zu einer Zeit, als die Great Firewall, die große Firewall, keines Strems zusammengesetzt hat, vielleicht aus Performance-Grunden. Es ist einfach, Paket für Paketzuskehren ohne zusammenzusetzen. Wir schrieben ein Tool, das die TCP-Fenz der größte Windowsize auf einem Server manipuliert, was man verwenden kann, um den Client zu instruieren, dass eine Signatur in zwei Stücke geteilt werden soll. Und dies war genug, um die Packet-Inspection zu umgehen. Den Client einfach instruieren, dass die Signatur in zwei Stücke geteilt werden soll, und die Firewall kann sie dann nicht mehr identifizieren. Und dies arbeitet bis, funktioniert bis vor einem Jahr. Es war niemals die Absicht, das auf Dauer beizubehalten, aber es war eine schöne Idee. Und dann gab es also ein Forschungspapier, in dem all diese kleinen, schönen Hacks angestellt wurden, die man machen kann, wie man einen TCP-Segment so deformieren kann, dass es wirklich hart wird, für die Firewall sie wieder zusammenzusetzen. Es gibt dann eine Menge Wahrheiten. Und es ist sehr, sehr schön. Einige diese Dinge sind sehr, sehr schwer für die Firewalls zu reparieren, aber leider ist es auch sehr, sehr schwer dies auszunutzen. Es geht letztendlich darum, dass ich einigen Leuten sage, okay, warum lässt du nicht dieses Kernelmodul für eine Weile laufen, für ein Wochenende, dass dein TCP-Stag auf merkwürdiger Weise motiviert, und die Firewall kann deinen Traffic nicht mehr scannen. Aber diese Dinge sind einfach ein Albtraum, dies auszurollen, und das haben sich nicht sehr viel benutzen können. Also, man kann schöne Dinge machen hier mit der Netfilter API, aber es ist einfach nicht sehr schön, das zu auszurollen, sexuell zu verteilen. Was also sich als sehr viel erfolgreich erwiesen hat, sind die Plugable Transports im Tourprotokoll als Idee. Das hat das Tourprotokoll vor einem, das Tourprojekt vor einigen Jahren eingeführt, als zu merken, dass man diesen Wettlauf sehr viel leichter machen kann, wenn man die Umgehung und die Anonymisierung trennt. Wir verlegen einfach die Anonymisierung in ein separates Programm. Wir haben einen zusätzlichen Proxy, der direkt vor den Tourinstanzen sitzt, und der den Traffic eine verrückte Weise durcheinanderbringt, sodass also der TourKline mit einem zusätzlichen Sox-Interface redet. Da wir von Sox reden, es ist sehr einfach, dies für viele verschiedene Anwendungen zu nutzen, und das Entscheidende ist, dass dies in keiner Weise spezifisch ist für Tour, viele Projekte benutzen dies, es ist im Wesentlichen eine offene Spezifikation, und dies war sehr nösslich für einen Haufen von VPN-Providern, die einfach VPN-Provider, die Leuten in bestimmten Ländern Zugang geben wollen. Man tut einen Server, den man OBS-Proxy nennt, üblicherweise nach vorne, und dann geht das. Es ist ein sehr flexibles System, man kann Payloads modifizieren, genauso wie man Flussinformationen, Datenflussinformationen verändern kann, Paketlängen und solche Dinge. Es gibt hier auch wieder APIs oder APIs für verschiedene Dinge. Sie war am Anfang, sie war die erste Sprache, dann man, dass es ziemlich schwer ist, in Sie das zu schreiben, dann gibt es eine Implementierung in Python, inzwischen, und einen in Go. Vielleicht könnt ihr eine Visualisierung sehen von dem Payload von Vanillator, verglichen mit OBS2 und 3, und der Punkt in diesem Egram ist, wenn man sich oben links das anschaut, Vanillator sieht nicht sehr zufällig aus. Was man hier sieht, ist, er nutzt einfach nicht die gesamte Bereite des Beitraums aus in dem Handshake, und dies ist, was die Umgehungsprotokolle versuchen zu fixen. Zu dieser Zeit haben wir mindestens vier Protokolle, die in China funktionieren. Das Grambeshoot und OBS4 sind speziell entworfen worden, um dem Active Probing zu widerstehen. Sie haben ein Secret, es gibt ein Share Secret, dass man außerhalb des Kanals teilt, und wenn ein Klein nicht beweisen kann, dass ihr dieses Share Secret kennt, dann redet man einfach nicht mit ihm. Es gibt außerdem Meek, was sehr aufregend ist, dies nutzt das Kollateralschadenproblem aus. Was es tut, ist, es tunnelt allen Traffic über ein Content Delivery Netzwerk, also was man auch als Domain Fronting kennt. Dies ist sehr cool, denn die Idee ist, wenn man ein Sensor ist, ist man auf einmal gezwungen Entscheidungen zu machen. Muss man dieses gesamte Content Delivery Netzwerk jetzt blocken, und alles was da angeboten wird, oder wird man alle User durch, und ermöglicht dadurch die Umgehung, und die Antwort üblicherweise ist, nein, das mache ich nicht, das wäre verrückt. Es gibt so viele Websites, die auf Content Delivery Netzwerks gehostet sind heutzutage, dass es einfach zu viel Arbeit für ein Sensor wäre. Das ist also die Idee von Meek, und FDI steht für Format Transforming Encryptions, das ist also ein schöner Hack, um beliebige Byte Streams mit einem Haufen von Regular Expressions zu bearbeiten, die man angibt. Das ist also das Interessante, dass es handelt sich hier nicht um Science Fiction, das sind getestete und in einsatzbefindliche Systeme. Man kann einen Browser benutzen, einen wesentlichen Fenster aufgehen lassen, dass einen die Auswahl gibt über einen Umgehungsprotokoll, also z.B. Dinge wie WebRTC, was eine Menge ärgerliche Probleme fixen könnte, das sieht wirklich vielversprechender aus. Das bringt mich zum Ende meines Talks, wir haben mit unserer Forschungspapier und der das ist alles frei und offen und die Daten und der Code und hier sind unsere E-Mail-Adressen, vielen Dank. Okay, perfekt, thanks so far, Philipp. We have about 13 minutes left for questions. Ich kann Fragen, Versuche. So we can get you on tape and everybody on the stream can also hear your question. Okay, also da vorne Mikro 1, vielen Dank. Danke für den Talk. Ich habe eine Frage, gibt es irgendwelche ähnliche Projekte für das Nordkoreanische Internet, zählen Sie auf eine ähnliche Art oder zählen Sie überhaupt? Ich kenne keine Systeme in anderen Ländern. Es würde mir nicht überraschen, wenn dies zu irgendeinem Punkt passiert. Diese Sachen kann man einfach in die Pack-Inspection-Boxes tun und verkaufen in anderen Ländern. Ich habe nichts gesehen, aber ich würde nicht überraschen sein. Eine Sache, bevor wir mit dem Q&A weiter machen, wenn ihr wirklich gehen müsst, bevor das Q&A zu Ende ist, dann macht das bitte leise und ruhig. Und einfach auch, um den Speaker hier zu respektieren und damit etwas Q&A in Ruhe zu Ende machen können, also Mikro 2. Du hast gewundert wegen der Probes und wo sie herkommen, viele Computer in China laufen immer noch auf Windows XP und ihre Virusscanner sind von staatlichen Firmen. Also, naja, vielleicht ist das einfach was mit dem Botnet zu tun. Ja, interessante Frage. Wir haben darüber nachgedacht, wir können dies nicht ausschließen. Unsere Idee war, es wäre schwer dies geheim zu halten, oder? Aber andererseits hat niemand das gemerkt, vielleicht. Also, Mikro 3, bitte. Habt ihr irgendwelche Analysen gemacht, was IPv6 angeht? Das befügt ja noch mehr Komplexität und neue Herausforderungen dazu. Leider haben wir das nicht getan. Wir haben dieses Gericht viel gehört, dass IPv6 gegen Sensor gefeilt ist. Ich weiß nicht, ob das stimmt. Es hört sich cool an, aber leider habe ich keine wirklichen Informationen. Also, gibt es noch irgendwelche Fragen von dem Signal Angel aus dem Internet? Okay. Frage von Alex C.C.P. Gibt es irgendwelche Ingenieure aus den, von innen, die irgendwelche, irgendwelche Dinge geliegt haben über die große Firewall? Nicht, dass ich wüsste, aber dieses eine der Gründe war, unsere E-Mail-Adressen hier auf dem Folge sind, nehme ich an. Also, dann noch eine Frage von dem Signal Angel aus dem RSI. Welche Gründe gibt es anzunehmen, dass China nur Probes von China und innerhalb von China benutzt? Ja, ich denke, es denkt von der Infrastruktur. Vielleicht ist es einfach einfacher technisch. Es gibt vielleicht einen technischen Grund und sicherlich auch einen politischen. Man kann dies in einem eigenen Land tun, wenn man stattdessen mit diesem netzwertlichen anderen Ländern herum spielt. Das hat große Auswirkungen. Ich denke, das ist der Grund. Es gibt wohl technische und politische Gründe, diesen nicht zu tun. Es gibt tatsächlich Forschung, die sich anschaut, was es für Kolateral-Traffic auf DNS-Servern in China gibt, DNS-Präusening. Also, Traffic, der durch China in durchläuft, ist auch tatsächlich dem DNS-Präusening ausgesetzt, obwohl Sender und Empfänger außerhalb von China sind. Das scheint nun versehentlich zu sein. Okay, noch eine Frage aus dem Raum Mikro 4, bitte. Ja, es hat nämlich gefragt, ob sie jemals die Quelle blocken anstatt nur das Ziel zu blocken. Nicht per IP-Adresse, glaube ich. Das Interessante ist, sie blockieren, glaube ich, das Syn-Ack-Segment der TCP-Verbindung. Was mehr oder weniger ähnlich ist zu den Blockieren der Quelle. Das fand ich erstaunlich. Ich denke, wenn man eine TCP-Verbindung blockieren möchte, dann lässt man einfach das Syn-Segment, das allererste im Handshake, fallen. Aber das ist nicht der Fall, wenn man versucht, sich mit einem blockierten Server zu verbinden, dann wird das Syn-Ack-Service blockiert, die Antwort auf das Syn. Wir wissen nicht genau warum. Es gibt verschiedene Theorien, die mit Access-Control-Listen auf Switches zu tun haben. Vielleicht sollen hier Leute getäuscht werden und denken, dass Trace-Route funktioniert. Vielleicht ähnlich. Also, noch eine Frage vom Signalengel. Also, Janix fragt, hat irgendjemand versucht, die Probes gegen die Chinesen zu benutzen, also ein Honeyball fortzubereiten, sie zu analysieren, auszunutzen, sie zu Fingerprinten? Ich bin mir nichts bekannt, aber ich denke, es gibt mehrere Wege, wie das System fehlschlagen kann, scheitern kann. Wenn man zum Beispiel beginnt, all diese Probe Triggering, diese Signaturen, die eine Probe auslösen zu allen möglichen Protokollen hinzufügt, dann muss das System all diese Ziele auf einmal scannen. Ich bin mir nicht bewusst, dass es Dinge gibt. Versuche gibt's Probes auszunützen, aber man könnte schon versuchen, sie zu täuschen, dass sie Dinge tun, dass sie sie nicht tun sollten. Okay, Mikro 5, du hast in der Welle gewartet. Also, ich habe mir gerade meine Logs angeschaut und ich habe einige Request gefunden. Vor Example von dem VPN Service. Brauchst du noch mehr Informationen vor der Datenset? Ja, das wäre super. Also, ich glaube, wir haben noch zahlreiche Fragen aus dem Netz, also zurück zu dem. Taxel fragt. Habt ihr irgendeine Idee, was die Algorithmen angeht, die benutzt werden hinter den Initial Sequence Numbers, die die GFE Probes benutzen? Nein, haben wir nicht. Was klar zu sein scheint, ist, dass sie aus Zeitstempeln, aus der Zeitabklette werden, aber der genaue Algorithmen ist, wie sie es tun. Das ist mir nicht bewusst. Also, dann Mikro 1 wieder. Ich habe eher eine Idee, welche Technik sie benutzen. Ich habe einige Sachen gehört über Firmen aus dem westlichen Firmen, die da mitspielen. Ich denke, es gibt eigentlich genug Know-how dort, sodass sie sich nicht auf andere Länder verlassen müssen. Aber die Technikfrage ist interessant. Es könnte also ein TCP-Stack im Userspace sein, zum Beispiel. Wir wissen nicht, ob da jemand Experte ist. Aber wir könnten sie vielleicht schauen, sich die Pakete anschauen. Wir haben die Captures Online, die gesammelten Pakete, um vielleicht herauszufinden, welcher TCP-Stack verwendet wird. Okay, Mikro 3 bitte. Hallo. Also, einige schnelle Gedanken, nachdem ich den Talk gehört habe. Die Sequenz-Nummern und die IP-Stack-Nummern. Also, ich habe mich gefragt, ob sie ihr darüber nachgedacht habt über eine einzige Maschine und mehrere Maschinen, die über mehrere Adressen arbeiten. Ich habe im Wesentlichen einen Netzwerk benutzt und ich konnte diesen Paketen mit verschiedenen Identitäten antworten. Also, vielleicht kann man das auf einer höheren Ebene tun. Du kannst die Identität steuern und dann kannst du von verschiedenen IP-Adressen antworten. Also, habt ihr das schon mal nachgedracht oder habt ihr es schon mal versucht? Ich weiß nicht, ob ich völlig verstehe, was du sagst, hört sich an wie etwas, was man sich anschauen sollte. Wir haben noch mehr Muster in den TCP-TS-Wert, der also nahelegt, dass es sich über eine kleine Anzahl physischer Systeme handelt, vielleicht zehn. Ich habe in der Vergangenheit schon ein bisschen damit herumgespielt. Ich hatte einen Server und mit einem Python-Script konnte ich den Traffic überwachen. Auf einige von diesen Requests antworten mit verschiedenen Identitäten von über 100 IP-Adressen. Also, ich konnte entscheiden, ob ich antworte oder nicht. Also, vielleicht tun Sie etwas nur in einer größeren Menge, also nur eine Idee. Also, weil wir jetzt noch einige Fragen haben, noch eine Frage von Micro 3. Können die eine Schätzung abgeben bezüglich des Mechanismus? Was ist effizienter? Das DNS Poisoning oder das Big Packet Inspection? Die Packet Inspection hat eigentlich das nur das Ziel, das Inpaketen, was man findet und dann DNS Poisoning vielleicht macht. Ich meine, wenn man die vergleicht, also wenn Sie einfach die IP blocken und dich daran hindern, den Server zu benutzen, oder ob Sie einfach sagen, denn du kannst Facebook.com einfach nicht benutzen. Es liegt so aus, als ob die Länder mehr und mehr von IP-Adressen abgehen. Es ist so schwer, mit denen umzugehen. Man möchte unabhängig sein von Endpunkten und so IP-Adressen, Content-Divirial Networks. Also es gibt zu viel Verbreitung von IP-Adressen und Veränderungen. Also man möchte dynamischer werden, nur auf die Bytes schauen, die wirklich fliegen anstatt auf die Endpunkte. Denn für das DNS Poisoning, das klingt ein bisschen, als ob man das einfach mit DNS Sack lösen könnte, wenn man die Antworten einfach authentiziert und dann einfach die benutzt, die authentiziert ist. Ja, sicher. Es gibt Wege, das zu lösen. Man kann auch einfach warten auf die zweite Antwort Okay, danke. Okay, die letzten beiden Minuten macht, stellt bitte schnelle, konziere Fragen. Also es gibt viele Papers über die große Firewall und ihr habt über die Fingerprints geredet, die die große Firewall benutzt. Die Forschung, die ihr macht führt das zu einer Änderung in diesen Fingerprints, die in der Firewall benutzt werden? Ja, das ist eine gute Frage. Sie ändern sich sowieso mit der Zeit. Menschen verwenden verschiedene Systeme, Fingerprints ändern sich dadurch, aber wir reden hier nicht über Tage oder Wochen, sondern Fingerprints scheint es ändern sich innerhalb von Monaten oder nur Jahren. Ich denke, es gibt einfach nicht so viele Menschen, die arbeiten an der großen Firewall, die an neuen Techniken nicht ständig anpassen können. Es gibt Änderungen, aber darüber in der Öffentlichkeit zu reden, ist nicht die Antriebskraft für Änderungen. Passen Sie sich denn an, an die Forschung, die es gibt in vielen Teilen der Welt oder ändern Sie es einfach aus anderen Gründen? Es gibt sicher einige Anpassungen, die passiert. Das Ding ist, niemand kümmert sich darum, ob du dein eigenes Umgebungstool hast, das vielleicht von fünf benutzt wird. Worum es geht, ist Umgebungstools auf großem Maßstab. Egal wie gut oder schlecht dein Tool ist, sobald tausende Menschen es benutzen, wird man dort hinschauen. Das ist wirklich etwas, was nun auslöst, dass man anarbeitet. Jetzt haben wir leider keine Zeit mehr. Entschuldigung für die Leute, die noch Fragen haben. Philipp bleibt noch etwas. Ihr habt seine Kontaktdetails gesehen. Wir haben hier auch Kontaktdetails übersetzt.