Einführung
Moderne Unternehmenssysteme zur Filterung von Inhalten, von renommierten Herstellern wie Cisco, BlueCoat, FireEye, haben viele Gemeinsamkeiten mit ihren leistungsstärkeren Brüdern – den DPI-Systemen, die auf nationaler Ebene intensiv implementiert werden. Der Kern beider Systeme besteht darin, den eingehenden und ausgehenden Internetverkehr zu überwachen und basierend auf schwarzen und weißen Listen Entscheidungen über das Verbot von Internetverbindungen zu treffen. Da beide Systeme in ihren Grundlagen auf ähnlichen Prinzipien basieren, werden auch die Umgehungsmethoden viele Gemeinsamkeiten aufweisen.
Eine der Technologien, die es ermöglicht, sowohl DPI- als auch Unternehmenssysteme effektiv zu umgehen, ist die Technologie des Domain-Fronting. Das Prinzip besteht darin, auf eine blockierte Ressource zuzugreifen, indem man sich hinter einer anderen, öffentlich zugänglichen Domäne mit einem guten Ruf verbirgt, die mit Sicherheit von keinem System blockiert wird, wie zum Beispiel google.com.
Zu dieser Technologie wurden bereits viele Artikel verfasst und Beispiele angeführt. Allerdings ermöglichen die in letzter Zeit viel diskutierten Technologien DNS-over-HTTPS und encrypted-SNI sowie die neue Version des TLS 1.3-Protokolls, einen weiteren Aspekt des Domain-Fronting zu betrachten.
Wir klären die Technologie
Zunächst sollten wir einige grundlegende Begriffe klären, damit jeder versteht, wer wer ist und warum das alles wichtig ist. Wir haben den Mechanismus eSNI erwähnt, dessen Funktionsweise im Folgenden behandelt wird. Der Mechanismus eSNI (encrypted Server Name Indication) ist eine gesicherte Variante von SNI, die nur für das TLS 1.3-Protokoll verfügbar ist. Das Hauptziel besteht darin, unter anderem Informationen darüber zu verschlüsseln, an welche Domain die Anfrage gesendet wird.
Lassen Sie uns nun die Funktionsweise des eSNI-Mechanismus in der Praxis betrachten.
Angenommen, wir haben eine Internet-Ressource, die von einer modernen DPI-Lösung blockiert wird (nehmen wir beispielsweise den berühmten Torrent-Tracker — rutracker.nl). Beim Versuch, auf die Website des Torrent-Trackers zuzugreifen, sehen wir die standardmäßige Meldung des Anbieters, dass die Ressource blockiert ist:
Auf der Website der RKН ist diese Domain tatsächlich auf den Sperrlisten vermerkt:
Bei einer Whois-Abfrage ist zu sehen, dass die Domain hinter dem Cloud-Anbieter Cloudflare "verborgen" ist.
Im Gegensatz zu den "Spezialisten" aus dem RKN haben die technisch versierten Mitarbeiter von Beeline (oder die durch die bittere Erfahrung unseres berühmten Regulators belehrt wurden) die Website nicht einfach nach der IP-Adresse gesperrt, sondern sie haben gezielt das Domainnamenauf die Sperrliste gesetzt. Das lässt sich leicht überprüfen, indem man schaut, welche anderen Domains hinter derselben IP-Adresseversteckt sind, eine davon besucht und sieht, dass der Zugang nicht blockiert ist:
Wie kann das sein? Wie erkennt das DPI des Anbieters, auf welche der Domains mein Browser zugreift, wenn all die Kommunikation über das Protokoll https erfolgt, und wir bisher keine Zertifikatsänderungen von Beeline bemerkt haben? Ist er etwa Hellseher oder werde ich etwa überwacht?
Lass uns versuchen, diese Frage zu beantworten, indem wir den Verkehr mit Wireshark analysieren.
Auf dem Screenshot sieht man, dass der Browser zunächst die IP-Adresse des Servers über DNS abrufen muss, dann erfolgt das Standard-TCP-Handschlag mit dem Zielserver, und anschließend versucht der Browser, eine SSL-Verbindung mit dem Server herzustellen. Dafür sendet er ein Paket. SSL Client Hello, der den ursprünglichen Domainnamen im Klartext enthält. Dieses Feld ist für den Frontend-Server von Cloudflare erforderlich, um die Verbindung korrekt zu routen. Hier gerät uns der Anbieter-DPI in die Quere und trennt unsere Verbindung. Dabei erhalten wir keinerlei Fehlermeldung vom Anbieter und sehen einfach den Standardfehler des Browsers, als ob die Website abgeschaltet oder nicht erreichbar ist:
Jetzt aktivieren wir den eSNI-Mechanismus im Browser, wie in der Anleitung für Firefox :
Dazu öffnen wir die Konfigurationsseite von Firefox about:config und aktivieren die folgenden Einstellungen:
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 über über diesen Link verfügbar und versuchen noch einmal, unser Torrent-Tracker-Trick anzuwenden.
Voilà. Unser bevorzugter Tracker ist ohne VPN und Proxy-Server zugänglich. Lassen Sie uns nun den Datenstrom in Wireshark betrachten und sehen, was passiert ist.
In dieser Version enthält das SSL-Client-Hello-Paket nicht mehr explizit die Ziel-Domain. Stattdessen ist ein neues Feld - encrypted_server_name - im Paket vorhanden, das den Wert rutracker.nl enthält. Nur der Frontend-Server von Cloudflare kann dieses Feld entschlüsseln. Somit bleibt der DPI-Anbieter keine andere Wahl, als die Hände in Unschuld zu waschen und diesen Datenverkehr zuzulassen. Alternativen zur Verschlüsselung gibt es nicht.
Nun haben wir gesehen, wie die Technologie im Browser funktioniert. Lass uns versuchen, sie für spezifischere und interessante Anwendungen zu nutzen. Zunächst werden wir lernen, wie man mit Curl eSNI für die Arbeit mit TLS 1.3 anwendet und gleichzeitig betrachten, wie 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 die Unterstützung für eSNI dort sicherstellen. In den Master-Branches von OpenSSL gibt es derzeit keine Unterstützung für eSNI, daher müssen wir einen speziellen Branch von OpenSSL herunterladen, kompilieren und installieren.
Wir klonen das Repository von GitHub und kompilieren es 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 dessen Kompilierung unter Verwendung unserer zusammengestellten 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 OpenSSL zu finden ist (in unserem Fall /opt/openssl/), korrekt anzugeben und sicherzustellen, dass der Konfigurationsprozess fehlerfrei verläuft.
Bei erfolgreicher Konfiguration sehen wir die Zeile:
WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!
$ makeNach erfolgreicher Erstellung des Pakets verwenden wir eine spezielle Bash-Datei aus dem Lieferumfang von OpenSSL zur Konfiguration und Ausführung von curl. Wir kopieren sie zur besseren Handhabung in das Verzeichnis von curl:
cp /opt/openssl/esnistuff/curl-esni und führen eine Test-HTTPS-Anfrage an den Cloudflare-Server durch, während wir gleichzeitig DNS- und TLS-Pakete in Wireshark aufzeichnen.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Im Serverantwort erhalten wir neben vielen 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 hinweist, dass unsere Anfrage erfolgreich an den Zielserver übermittelt, empfangen und bearbeitet wurde.
Schauen wir uns nun den Verkehrs-Dump in Wireshark an, also das, was in diesem Fall der Provider-DPI gesehen hat.
Man sieht, dass curl zuerst den DNS-Server nach dem öffentlichen eSNI-Schlüssel für den Cloudflare-Server angefragt hat – eine TXT-DNS-Anfrage an _esni.cloudflare.com (Paket Nr. 13). Danach hat curl unter Verwendung der OpenSSL-Bibliothek eine TLS 1.3-Anfrage an den Cloudflare-Server gesendet, in der das SNI-Feld mit dem zuvor erhaltenen öffentlichen Schlüssel verschlüsselt war (Paket Nr. 22). Zusätzlich zum eSNI-Feld wurde im SSL-hello-Paket auch ein Feld mit dem normalen – unverschlüsselten SNI eingefügt, das wir in beliebiger Reihenfolge angeben können (in diesem Fall – www.hello-rkn.ru).
Dieses Feld des unverschlüsselten SNI wurde bei der Verarbeitung durch die Cloudflare-Server nicht berücksichtigt und diente lediglich der Tarnung für den Provider-DPI. Der Cloudflare-Server hat unser SSL-hello-Paket angenommen, das eSNI entschlüsselt, den ursprünglichen SNI extrahiert und ihn wie vorgesehen bearbeitet (so wie es bei der Entwicklung des eSNI geplant war).
Das Einzige, was in diesem Fall aus Sicht von DPI relevant ist, ist die primäre DNS-Anfrage an _esni.cloudflare.com. Wir haben die DNS-Anfrage jedoch nur offengelegt, um zu zeigen, wie dieser Mechanismus im Hintergrund funktioniert.
Um der DPI endgültig die Grundlage zu entziehen, verwenden wir das bereits erwähnte Verfahren DNS-over-HTTPS. Eine kurze Erklärung – DOH ist ein Protokoll, das Schutz vor der "Man-in-the-Middle"-Attacke bietet, indem es die DNS-Anfrage über das HTTPS-Protokoll sendet.
Wir führen die Anfrage erneut aus, allerdings erhalten wir diesmal die öffentlichen eSNI-Schlüssel über das https-Protokoll und nicht über DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Der Traffic-Dump 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 aufruft (HTTPS-Verbindung zum Server 104.16.249.249), um von dort die Werte der öffentlichen Schlüssel für die Verschlüsselung von SNI zu erhalten, und anschließend den Zielserver ansteuert, während er sich 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üchtigten bösen Corporation.
Wir führen eine solche Anfrage durch:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Und wir erhalten die Antwort:
< HTTP/1.1 301 Permanently Moved
< 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 einen blockierten Server rutracker.nl erreicht, wobei wir den DoH-Resolver dns.google verwendet haben (keine Schreibfehler, das berühmte Unternehmen hat jetzt eine eigene Top-Level-Domain) und uns mit einer anderen Domain gedeckt haben, deren Blockierung jeglichem DPI unter Androhung der Todesstrafe strikt untersagt ist. Anhand der erhaltenen Antwort kann man erkennen, dass unsere Anfrage erfolgreich bearbeitet wurde.
Zur zusätzlichen Überprüfung, dass der Provider-DPI auf das offene SNI reagiert, das wir als Deckung übermitteln — können wir eine Anfrage an rutracker.nl senden, indem wir uns mit einer anderen verbotenen Ressource, beispielsweise einem weiteren ‚guten‘ Torrent-Tracker, verstecken:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Eine Antwort vom Server erhalten wir nicht, da unsere Anfrage von dem DPI-System blockiert wird.
Eine kleine Zusammenfassung zum ersten Teil
Wir konnten die Funktionalität von eSNI mit openssl und curl demonstrieren und die Funktionsweise des Domain-Fronting auf Basis von eSNI überprüfen. Ebenso können wir unsere bevorzugten Tools, die die OpenSSL-Bibliothek verwenden, anpassen, um 'unter dem Deckmantel' anderer Domains zu arbeiten. Mehr dazu in unseren nächsten Artikeln.
Quelle: habr.com
