Einführung
Moderne Content-Filtersysteme für Unternehmen von so renommierten Herstellern wie Cisco, BlueCoat, FireEye haben viele Gemeinsamkeiten mit ihren leistungsstärkeren Gegenstücken – DPI-Systemen, die auf nationaler Ebene aktiv implementiert werden. Der Kern der Arbeit beider besteht darin, den ein- und ausgehenden Internetverkehr zu überprüfen und auf der Grundlage von Black/White-Listen eine Entscheidung über das Verbot der Internetverbindung zu treffen. Und da sich beide in den Grundlagen ihrer Arbeit auf ähnliche Prinzipien stützen, werden auch die Methoden zu ihrer Umgehung viele Gemeinsamkeiten aufweisen.
Eine der Technologien, mit denen Sie sowohl DPI- als auch Unternehmenssysteme recht effektiv umgehen können, ist die Domain-Fronting-Technologie. Das Wesentliche ist, dass wir zu einer blockierten Ressource gehen und uns hinter einer anderen, öffentlichen Domain mit einem guten Ruf verstecken, die offensichtlich von keinem System, zum Beispiel google.com, blockiert wird.
Über diese Technologie wurden bereits zahlreiche Artikel geschrieben und viele Beispiele genannt. Die beliebten und kürzlich diskutierten DNS-over-HTTPS- und Encrypted-SNI-Technologien sowie die neue Version des TLS 1.3-Protokolls ermöglichen es jedoch, eine weitere Option für das Domain-Fronting in Betracht zu ziehen.
Die Technologie verstehen
Definieren wir zunächst ein paar Grundkonzepte, damit jeder versteht, wer wer ist und warum das alles nötig ist. Wir haben den eSNI-Mechanismus erwähnt, dessen Funktionsweise weiter unten besprochen wird. Der eSNI-Mechanismus (encrypted Server Name Indication) ist eine sichere Version von SNI, die nur für das TLS 1.3-Protokoll verfügbar ist. Die Hauptidee besteht darin, unter anderem Informationen darüber zu verschlüsseln, an welche Domain die Anfrage gesendet wird.
Schauen wir uns nun an, wie der eSNI-Mechanismus in der Praxis funktioniert.
Nehmen wir an, wir haben eine Internetressource, die durch eine moderne DPI-Lösung blockiert wird (nehmen wir zum Beispiel den berühmten Torrent-Tracker rutracker.nl). Wenn wir versuchen, auf die Website eines Torrent-Trackers zuzugreifen, sehen wir den Standard-Stub des Anbieters, der darauf hinweist, dass die Ressource blockiert ist:
Auf der RKN-Website ist diese Domain tatsächlich in den Stopplisten aufgeführt:
Bei der Whois-Abfrage erkennt man, dass die Domain selbst hinter dem Cloud-Anbieter Cloudflare „versteckt“ ist.
Aber im Gegensatz zu den „Spezialisten“ von RKN haben technisch versiertere Mitarbeiter von Beeline (oder durch die bittere Erfahrung unserer berühmten Regulierungsbehörde gelehrt) die Site nicht dummerweise anhand der IP-Adresse gesperrt, sondern den Domainnamen zur Stoppliste hinzugefügt. Sie können dies leicht überprüfen, indem Sie sich ansehen, welche anderen Domains sich hinter derselben IP-Adresse verbergen, eine davon besuchen und feststellen, dass der Zugriff nicht blockiert ist:
Wie kommt es dazu? Woher weiß die DPI des Anbieters, auf welcher Domain sich mein Browser befindet, da die gesamte Kommunikation über das https-Protokoll erfolgt und wir die Substitution von https-Zertifikaten durch Beeline noch nicht bemerkt haben? Ist er hellsichtig oder werde ich verfolgt?
Versuchen wir, diese Frage zu beantworten, indem wir uns den Datenverkehr über Wireshark ansehen
Der Screenshot zeigt, dass der Browser zunächst die IP-Adresse des Servers über DNS erhält, dann ein Standard-TCP-Handshake mit dem Zielserver stattfindet und dann versucht der Browser, eine SSL-Verbindung mit dem Server herzustellen. Dazu sendet es ein SSL-Client-Hello-Paket, das den Namen der Quelldomäne im Klartext enthält. Dieses Feld wird vom Cloudflare-Frontend-Server benötigt, um die Verbindung korrekt weiterzuleiten. Hier erwischt uns der Anbieter DPI und unterbricht unsere Verbindung. Gleichzeitig erhalten wir keinen Stub vom Anbieter und sehen den Standard-Browserfehler, als ob die Website deaktiviert ist oder einfach nicht funktioniert:
Aktivieren wir nun den eSNI-Mechanismus im Browser, wie in der Anleitung beschrieben :
Dazu öffnen wir die Firefox-Konfigurationsseite about: config und aktivieren Sie die folgenden Einstellungen:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Anschließend prüfen wir, ob die Einstellungen auf der Cloudflare-Website korrekt funktionieren. und versuchen wir es noch einmal mit unserem Torrent-Tracker.
Voila. Unser Lieblings-Tracker wurde ohne VPN oder Proxyserver geöffnet. Schauen wir uns nun den Traffic-Dump in Wireshark an, um zu sehen, was passiert ist.
Dieses Mal enthält das SSL-Client-Hello-Paket nicht explizit die Zieldomäne, sondern stattdessen erschien ein neues Feld im Paket – verschlüsselter_Servername – darin ist der Wert von rutracker.nl enthalten, und nur der Cloudflare-Frontend-Server kann diesen entschlüsseln Feld. Und wenn ja, dann hat der Anbieter DPI keine andere Wahl, als die Hände in Unschuld zu waschen und solchen Datenverkehr zuzulassen. Bei der Verschlüsselung gibt es keine anderen Möglichkeiten.
Also haben wir uns angeschaut, wie die Technologie im Browser funktioniert. Versuchen wir nun, es auf spezifischere und interessantere Dinge anzuwenden. Und zuerst werden wir demselben Curl beibringen, eSNI für die Arbeit mit TLS 1.3 zu verwenden, und gleichzeitig werden wir sehen, wie das eSNI-basierte Domain-Fronting selbst funktioniert.
Domain-Fronting mit eSNI
Da Curl die Standard-openssl-Bibliothek für die Verbindung über das https-Protokoll verwendet, müssen wir dort zunächst eSNI-Unterstützung bereitstellen. Es gibt noch keine eSNI-Unterstützung in den OpenSSL-Master-Zweigen, daher müssen wir einen speziellen OpenSSL-Zweig herunterladen, kompilieren und installieren.
Wir klonen das Repository von GitHub und kompilieren wie gewohnt:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Als nächstes klonen wir das Repository mit Curl und konfigurieren seine Kompilierung mithilfe unserer kompilierten OpenSSL-Bibliothek:
$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni
$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug
Hier ist es wichtig, alle Verzeichnisse, in denen sich openssl befindet, korrekt anzugeben (in unserem Fall ist das /opt/openssl/) und sicherzustellen, dass der Konfigurationsprozess fehlerfrei abläuft.
Wenn die Konfiguration erfolgreich ist, sehen wir die Zeile:
ACHTUNG: esni ESNI aktiviert, aber als EXPERIMENTAL markiert. Mit Vorsicht verwenden!
$ makeNach erfolgreicher Erstellung des Pakets verwenden wir eine spezielle Bash-Datei von OpenSSL, um Curl zu konfigurieren und auszuführen. Der Einfachheit halber kopieren wir es mit Curl in das Verzeichnis:
cp /opt/openssl/esnistuff/curl-esni und stellen Sie eine Test-https-Anfrage an den Cloudflare-Server, während Sie gleichzeitig DNS- und TLS-Pakete in Wireshark aufzeichnen.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/In der Serverantwort erhalten wir neben vielen Debugging-Informationen von OpenSSL und Curl eine HTTP-Antwort mit Code 301 von Cloudflare.
HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/
Dies zeigt an, dass unsere Anfrage erfolgreich an den Zielserver übermittelt, abgehört und verarbeitet wurde.
Schauen wir uns nun den Traffic Dump in Wireshark an, d.h. was der Anbieter DPI in diesem Fall gesehen hat.
Es ist ersichtlich, dass Curl sich zunächst an den DNS-Server wandte, um einen öffentlichen eSNI-Schlüssel für den Cloudflare-Server zu erhalten – eine TXT-DNS-Anfrage an _esni.cloudflare.com (Paket Nr. 13). Anschließend sendete Curl mithilfe der OpenSSL-Bibliothek eine TLS 1.3-Anfrage an den Cloudflare-Server, in der das SNI-Feld mit dem im vorherigen Schritt erhaltenen öffentlichen Schlüssel (Paket Nr. 22) verschlüsselt wurde. Aber zusätzlich zum eSNI-Feld enthielt das SSL-Hallo-Paket auch ein Feld mit dem üblichen offenen SNI, das wir in beliebiger Reihenfolge angeben können (in diesem Fall - ).
Dieses offene SNI-Feld wurde bei der Verarbeitung durch Cloudflare-Server in keiner Weise berücksichtigt und diente lediglich als Maske für die Provider-DPI. Der Cloudflare-Server empfing unser SSL-Hallo-Paket, entschlüsselte das eSNI, extrahierte das Original-SNI von dort und verarbeitete es, als wäre nichts passiert (er tat alles genau wie bei der Entwicklung des eSNI geplant).
Das einzige, was in diesem Fall aus DPI-Sicht abgefangen werden kann, ist die primäre DNS-Anfrage an _esni.cloudflare.com. Aber wir haben die DNS-Anfrage nur geöffnet, um zu zeigen, wie dieser Mechanismus von innen funktioniert.
Um DPI endlich den Boden unter den Füßen wegzuziehen, nutzen wir den bereits erwähnten DNS-over-HTTPS-Mechanismus. Eine kleine Erklärung: DOH ist ein Protokoll, mit dem Sie sich vor Man-in-the-Middle-Angriffen schützen können, indem Sie eine DNS-Anfrage über HTTPS senden.
Führen wir die Anfrage erneut aus, aber dieses Mal erhalten wir öffentliche eSNI-Schlüssel über das https-Protokoll, nicht über DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Der Request-Traffic-Dump ist im folgenden Screenshot dargestellt:
Es ist ersichtlich, dass Curl zunächst über das DoH-Protokoll (https-Verbindung zum Server 104.16.249.249) auf den Server mozilla.cloudflare-dns.com zugreift, um von diesem die Werte öffentlicher Schlüssel für die SNI-Verschlüsselung zu erhalten, und dann zum Ziel Server, der sich hinter der Domäne versteckt .
Zusätzlich zum oben genannten DoH-Resolver mozilla.cloudflare-dns.com können wir andere beliebte DoH-Dienste nutzen, beispielsweise vom berühmten bösen Konzern.
Lassen Sie uns die folgende Abfrage ausführen:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Und wir bekommen die Antwort:
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH
In diesem Fall haben wir uns mit dem DoH-Resolver dns.google an den blockierten Server rutracker.nl gewandt (hier gibt es keinen Tippfehler, jetzt hat das berühmte Unternehmen eine eigene First-Level-Domain) und uns mit einer anderen Domain abgedeckt, was streng genommen der Fall ist Es ist allen DPIs untersagt, bei Todesstrafe zu blockieren. Anhand der erhaltenen Antwort können Sie nachvollziehen, dass unsere Anfrage erfolgreich bearbeitet wurde.
Als zusätzliche Überprüfung, ob die DPI des Anbieters auf die offene SNI reagiert, die wir als Deckmantel übermitteln, können wir unter dem Deckmantel einer anderen verbotenen Ressource, beispielsweise eines anderen „guten“ Torrent-Trackers, eine Anfrage an rutracker.nl stellen:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Wir erhalten keine Antwort vom Server, weil... Unsere Anfrage wird vom DPI-System blockiert.
Ein kurzes Fazit zum ersten Teil
So konnten wir die Funktionalität von eSNI mithilfe von OpenSSL und Curl demonstrieren und die Funktionsweise des Domain-Frontings auf Basis von eSNI testen. Auf die gleiche Weise können wir unsere Lieblingstools, die die OpenSSL-Bibliothek verwenden, so anpassen, dass sie „unter dem Deckmantel“ anderer Domänen arbeiten. Mehr Details dazu in unseren nächsten Artikeln.
Source: habr.com