Einführung
Moderne Unternehmenssysteme zur Inhaltsfilterung, von namhaften Herstellern wie Cisco, BlueCoat, FireEye, weisen viele Ähnlichkeiten mit ihren leistungsstärkeren Verwandten auf – den DPI-Systemen, die auf nationaler Ebene intensiv implementiert werden. Das wesentliche Ziel beider Systeme ist es, den ein- und ausgehenden Internetverkehr zu kontrollieren und auf Grundlage von Schwarz-/Weißlisten Entscheidungen über die Blockierung von Internetverbindungen zu treffen. Da beide Systeme in ihren Grundprinzipien ähnlich arbeiten, werden auch die Methoden, sie zu umgehen, viele Gemeinsamkeiten aufweisen.
Eine der Technologien, die es ermöglicht, sowohl DPI- als auch Unternehmenssysteme relativ effektiv zu umgehen, ist die Technologie des Domain Fronting. Dabei greifen wir auf eine blockierte Ressource zu, indem wir uns hinter einer anderen, öffentlich zugänglichen Domain mit gutem Ruf verbergen, die sicher nicht von irgendeinem System blockiert wird, beispielsweise google.com.
Über diese Technologie wurden bereits viele Artikel verfasst und zahlreiche Beispiele angeführt. Dennoch ermöglichen beliebte und in letzter Zeit viel diskutierte Technologien wie DNS-over-HTTPS und encrypted-SNI sowie die neue Version des Protokolls TLS 1.3, eine weitere Variante des Domain Fronting zu betrachten.
Lassen Sie uns die Technologie näher untersuchen.
Zunächst sollten wir uns ein wenig mit den grundlegenden Begriffen befassen, damit jeder versteht, wer wer ist und warum das alles notwendig ist. Wir haben den Mechanismus eSNI erwähnt, dessen Funktionsweise weiter unten erläutert wird. Der Mechanismus eSNI (encrypted Server Name Indication) ist eine sichere Variante von SNI, die nur für das Protokoll TLS 1.3 verfügbar ist. Das Hauptziel besteht darin, unter anderem Informationen darüber zu verschlüsseln, an welche Domain die Anfragen gerichtet werden.
Lassen Sie uns nun die Funktionsweise des Mechanismus eSNI in der Praxis betrachten.
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). Beim Versuch, auf die Seite des Torrent-Trackers zuzugreifen, sehen wir das Standard-Banner des Anbieters, das anzeigt, dass die Ressource blockiert ist:
Auf der Website des RKN ist diese Domain tatsächlich in den Sperrlisten enthalten:
Bei einer whois-Anfrage ist zu erkennen, dass die Domain selbst hinter dem Cloud-Anbieter Cloudflare 'versteckt' ist.
Aber im Gegensatz zu den "Spezialisten" aus der RKN haben die technisch versierteren Mitarbeiter von Beeline (oder aufgrund der schlechten Erfahrung mit unserem berühmten Regulierer) die Website nicht einfach nach der IP-Adresse gesperrt, sondern haben speziell den Domainnamen. Das lässt sich leicht überprüfen, wenn man sieht, welche anderen Domains sich hinter dieser IP-Adresseverbergen, eine davon besucht und sieht, dass der Zugriff nicht blockiert ist:
Wie kommt es dazu? Wie erkennt der Provider-DPI, auf welcher Domain sich mein Browser befindet, obwohl alle Kommunikationen über das Protokoll https laufen und wir bislang keine https-Zertifikatsänderungen von Beeline bemerkt haben? Ist er etwa ein Hellseher, oder werde ich überwacht?
Lassen Sie uns versuchen, diese Frage zu beantworten, indem wir den Verkehr über Wireshark betrachten.
Auf dem Screenshot sieht man, dass der Browser zunächst die IP-Adresse des Servers über DNS erhält, dann findet ein Standard-TCP-Handshake mit dem Zielserver statt, und danach versucht der Browser, eine SSL-Verbindung mit dem Server herzustellen. Dazu sendet er ein Paket SSL Client Hello, in dem der Name der ursprünglichen Domain im Klartext enthalten ist. Dieses Feld ist für den Frontend-Server von Cloudflare notwendig, um die Verbindung richtig zu routen. Hier fängt uns der Provider-DPI und trennt unsere Verbindung. Dabei erhalten wir keine Fehlermeldung vom Provider, sondern sehen einen Standardfehler des Browsers, als ob die Seite nicht verfügbar oder einfach nicht erreichbar ist:
Jetzt aktivieren wir den eSNI-Mechanismus im Browser, wie in den Anweisungen für Firefox :
Das machen wir, indem wir die Konfigurationsseite von Firefox öffnen about:config und die folgenden Einstellungen aktivieren:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Anschließend überprüfen wir die Funktionalität der Einstellungen auf der Cloudflare-Seite unter dem Link und versuchen noch einmal den Trick mit unserem Torrent-Tracker.
Voilà. Unser beliebter Tracker öffnete sich ohne VPN oder Proxy-Server. Lassen Sie uns nun den Datenverkehrsdump in Wireshark betrachten, um herauszufinden, was passiert ist.
Diesmal enthält das SSL-Client-Hello-Paket keinen expliziten Zielnamen, stattdessen gibt es ein neues Feld im Paket – encrypted_server_name – genau dort befindet sich der Wert rutracker.nl, und nur der Frontend-Server von Cloudflare kann dieses Feld entschlüsseln. Da das so ist, bleibt dem DPI-Anbieter nichts anderes übrig, als sich die Hände zu waschen und diesen Datenverkehr zuzulassen. Es gibt keine anderen Optionen für die Verschlüsselung.
So funktioniert die Technologie im Browser – das haben wir gesehen. Jetzt versuchen wir, sie für spezifischere und interessantere Dinge anzuwenden. Zunächst bringen wir curl bei, eSNI für die Arbeit mit TLS 1.3 zu verwenden, und schauen uns gleichzeitig an, wie das Domain-Fronting auf Basis von eSNI funktioniert.
Domain-Fronting mit eSNI
Da curl für die Verbindung über das HTTPS-Protokoll die Standardbibliothek OpenSSL verwendet, müssen wir zunächst sicherstellen, dass eSNI dort unterstützt wird. In den Master-Branches von OpenSSL gibt es bisher keine Unterstützung für eSNI, daher müssen wir einen speziellen OpenSSL-Branch 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
Anschließend klonen wir das Repository von curl und konfigurieren die Kompilierung unter Verwendung 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 korrekt anzugeben, in denen OpenSSL gefunden wird (in unserem Fall ist das /opt/openssl/) und sicherzustellen, dass der Konfigurationsprozess fehlerfrei verläuft.
Im Falle einer erfolgreichen Konfiguration sehen wir die Zeile:
WARNING: esni ESNI aktiviert, aber als EXPERIMENTAL gekennzeichnet. Mit Vorsicht verwenden!
$ makeNach erfolgreicher Erstellung des Pakets verwenden wir eine spezielle Bash-Datei aus dem OpenSSL-Set zur Konfiguration und zum Start von curl. Wir kopieren sie bequem in das Verzeichnis von curl:
cp /opt/openssl/esnistuff/curl-esni und führen eine Test-HTTPS-Anfrage an den Cloudflare-Server aus, während wir gleichzeitig DNS- und TLS-Pakete in Wireshark mitschneiden.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Im Server-Antwort erhalten wir neben zahlreichen Debug-Informationen von OpenSSL und curl eine HTTP-Antwort mit dem Statuscode 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/
was darauf hindeutet, dass unsere Anfrage erfolgreich an den Zielserver übermittelt, gehört und bearbeitet wurde.
Schauen wir uns nun den Datenverkehrsdump in Wireshark an, d.h. was der Anbieter-DPI in diesem Fall gesehen hat.
Es ist zu erkennen, dass curl zuerst den DNS-Server nach dem öffentlichen eSNI-Schlüssel für den Cloudflare-Server anfragte – eine TXT-DNS-Abfrage an _esni.cloudflare.com (Paket Nr. 13). Dann, unter Verwendung der OpenSSL-Bibliothek, sendete curl eine TLS 1.3-Anfrage an den Cloudflare-Server, bei der das SNI-Feld mit dem öffentlichen Schlüssel verschlüsselt wurde, der in der vorherigen Phase erhalten wurde (Paket Nr. 22). Aber neben dem eSNI-Feld wurde auch ein reguläres – offenes SNI-Feld in das SSL-Hello-Paket eingefügt, das wir in beliebiger Reihenfolge angeben können (in diesem Fall – www.hello-rkn.ru).
Dieses offene SNI-Feld wurde bei der Verarbeitung durch die Cloudflare-Server nicht berücksichtigt und diente lediglich als Tarnung für den Anbieter-DPI. Der Cloudflare-Server akzeptierte unser SSL-Hello-Paket, entschlüsselte eSNI, extrahierte das originale SNI und bearbeitete es, als wäre nichts geschehen (es wurde alles so gemacht, wie es bei der Entwicklung von eSNI geplant war).
Das Einzige, woran sich der DPI in diesem Fall festhalten könnte, ist die ursprüngliche DNS-Anfrage an _esni.cloudflare.com. Aber wir haben die DNS-Anfrage offen gemacht, nur um zu zeigen, wie dieser Mechanismus von innen funktioniert.
Um dem DPI endgültig die Grundlage zu entziehen, verwenden wir den bereits erwähnten Mechanismus DNS-over-HTTPS. Eine kurze Erläuterung – DOH ist ein Protokoll, das es ermöglicht, sich vor der „Man-in-the-Middle“-Attacke zu schützen, indem der DNS-Anfrage über das Protokoll HTTPS gesendet wird.
Wir werden die Anfrage wiederholen, aber dieses Mal erhalten wir die öffentlichen 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 Datenverkehrsdump der Anfrage ist im Screenshot unten dargestellt:
Es ist zu erkennen, dass curl zunächst den Server mozilla.cloudflare-dns.com über das DoH-Protokoll anfragt (HTTPS-Verbindung zum Server 104.16.249.249), um von ihnen die Werte der öffentlichen Schlüssel zur Verschlüsselung des SNI zu erhalten, und dann bereits zum Zielserver, wobei er sich dabei hinter der Domain versteckt. www.hello-rkn.ru.
Neben dem oben genannten DoH-Resolver mozilla.cloudflare-dns.com können wir auch andere beliebte DoH-Dienste nutzen, zum Beispiel von der berühmten bösen Corporation.
Wir werden eine solche Anfrage ausführen:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Und wir erhalten eine 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 auf den gesperrten Server rutracker.nl zugegriffen, wobei wir den DoH-Resolver dns.google verwendet haben (es gibt hier keinen Schreibfehler, jetzt hat das berühmte Unternehmen eine eigene Top-Level-Domain) und uns bereits hinter einer anderen Domain versteckt haben, deren Blockierung von allen DPI strikt untersagt ist, unter Androhung der Todesstrafe. Anhand der erhaltenen Antwort kann man erkennen, dass unsere Anfrage erfolgreich verarbeitet wurde.
Als zusätzliche Überprüfung, dass der DPI des Providers auf den offenen SNI reagiert, den wir als Tarnung senden — können wir eine Anfrage an rutracker.nl stellen, indem wir uns hinter einer anderen, ebenfalls gesperrten Ressource verstecken, zum Beispiel einem weiteren 'guten' Torrent-Tracker:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Wir erhalten keine Antwort vom Server, da unsere Anfrage vom DPI-System blockiert wird.
Eine kleine Schlussfolgerung zum ersten Teil
Wir haben also die Funktionsfähigkeit von eSNI mit Hilfe von openssl und curl demonstriert und die Funktion des Domain-Frontening basierend auf eSNI überprüft. Auf die gleiche Weise können wir unsere bevorzugten Werkzeuge, die die openssl-Bibliothek verwenden, anpassen, um unter der Tarnung anderer Domains zu arbeiten. Weitere Informationen dazu finden Sie in unseren nächsten Artikeln.
Quelle: habr.com
