Domän-fronting baserat på TLS 1.3

Introduktion

Moderna företagsinformationssystem för innehållsfiltret, från välkända tillverkare som Cisco, BlueCoat, FireEye, har mycket gemensamt med sina kraftfullare släktingar – DPI-system som intensivt införs på nationell nivå. Båda systemen arbetar för att övervaka inkommande och utgående internettrafik och fatta beslut om att blockera internetanslutningar baserat på svarta/vita listor. Eftersom de båda grundar sig på liknande principer kommer även metoderna för att kringgå dem att ha mycket gemensamt.

En av teknologierna som gör det möjligt att effektivt kringgå både DPI och företagsystem är domänfronting-tekniken. Dess kärna ligger i att vi går till en blockerat resurs, döljer oss bakom en annan offentlig domän med gott rykte, som i förväg inte kommer att blockeras av något system, till exempel google.com.

Det har redan skrivits många artiklar om denna teknologi och många exempel har tagits upp. De populära och ofta diskuterade teknologierna DNS-over-HTTPS och encrypted-SNI, samt den nya versionen av protokollet TLS 1.3, ger oss möjlighet att överväga ännu ett alternativ för domänfronting.

Låt oss reda ut teknologin

Först ska vi definiera de grundläggande begreppen så att alla har en förståelse för who is who och varför allt detta är viktigt. Vi nämnde mekanismen eSNI, vars arbete kommer att behandlas vidare. Mekanismen eSNI (encrypted Server Name Indication) är en skyddad version av SNI, tillgänglig endast för protokollet TLS 1.3. Huvudsyftet är att kryptera även information om vilken domän som begäran skickas till.

Låt oss nu se hur mekanismen eSNI fungerar praktiskt.

Anta att vi har en internetresurs som blockeras av en modern DPI-lösning (låt oss ta det berömda torrent-tracker — rutracker.nl som exempel). När vi försöker besöka torrent-trackers webbplats ser vi ISP:ns standardblockering som meddelar att resursen blockeras:

På RKN:s webbplats finns denna domän faktiskt med på stopp-listorna:

Vid en whois-förfrågan är det tydligt att själva domänen "döljs" bakom den molnbaserade leverantören Cloudflare.

Men till skillnad från "specialisterna" från RKN, har de mer tekniskt kunniga medarbetarna från Beeline (eller de som lärt sig av den bittra erfarenheten från vår berömda regulator) inte bara stängt av webbplatsen på IP-adressen, utan istället lagt till domännamnet. Det är lätt att övertyga sig om detta genom att se vilka andra domäner som döljer sig bakom samma IP-adress, besöka en av dem och se att tillgången inte är blockerad:

Hur kan detta vara möjligt? Hur vet användarens DPI hur vilken av domänerna som min webbläsare begär, när alla kommunikationer sker via protokollet https, och byten av https-certifikat från Beeline har vi inte märkt av ännu? Är det en spåman eller följer någon efter mig?

Vi ska försöka svara på detta fråga genom att titta på trafiken genom Wireshark.

På skärmdumpen syns att webbläsaren först får IP-adressen till servern via DNS, sedan sker den vanliga TCP-handshake med destinationsservern, och därefter försöker webbläsaren etablera en ssl-anslutning med servern. För detta skickar den paketet SSL Client Hello, där det ursprungliga domännamnet finns synligt. Detta fält behövs av front-end-servern Cloudflare för korrekt routing av anslutningen. Det är här som den provider-baserade DPI fångar oss genom att bryta vår anslutning. Vi får ingen blockeringsmeddelande från tjänsteleverantören och ser standard webbläsarfel som om webbplatsen är avstängd eller bara inte fungerar:

Nu låt oss aktivera eSNI-mekanismen i webbläsaren, som det står i instruktionerna för Firefox :
Därför öppnar vi konfigurationssidan för Firefox about:config och aktiverar följande inställningar:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

Efter detta ska vi kontrollera inställningarnas korrekthet på Cloudflare-sidan genom länken och försöka finten med vår torrent-tracker igen.

Voila. Vår älskade tracker öppnades, utan några VPN:er eller proxyservrar. Låt oss nu titta på trafiken i Wireshark, vad hände.

Den här gången innehåller paketet ssl client hello inte domännamnet i klartext, utan i paketet har ett nytt fält tillkommit — encrypted_server_name — där värdet rutracker.nl finns, och endast Cloudflare front-end-servern kan dekryptera detta fält. Eftersom det är så, finns det inget annat kvar för tjänsteleverantörens DPI än att tvätta händerna och låta sådan trafik passera. Det finns inga andra alternativ för kryptering.

Så, vi har sett hur teknologin fungerar i webbläsaren. Nu ska vi försöka använda den för mer specifika och intressanta saker. Till att börja med ska vi lära curl att använda eSNI för att arbeta med TLS 1.3, och samtidigt se hur domänfrontning på basis av eSNI fungerar.

Domänfrontning med eSNI

Eftersom curl för att ansluta via https använder det standardbiblioteket openssl, måste vi först säkerställa stöd för eSNI där. I master-grenen av openssl finns det för närvarande inget stöd för eSNI, så vi måste ladda ner en speciell gren av openssl, kompilera och installera den.

Vi klonar repositoriet från GitHub och kompilerar som vanligt:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

Därefter klonar vi repositoriet med curl och konfigurerar dess kompilering med vår kompilerade openssl-bibliotek:

$ 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

Här är det viktigt att ange alla kataloger där openssl finns korrekt (i vårt fall är det /opt/openssl/) och se till att konfigurationsprocessen har genomförts utan fel.

Vid framgångsrik konfiguration kommer vi att se raden:

WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!

$ make

Efter att paketet har byggts framgångsrikt ska vi använda en speciell bash-fil från openssl för att konfigurera och köra curl. Vi kopierar den till katalogen med curl för bekvämlighet:

cp /opt/openssl/esnistuff/curl-esni 

och gör en test https-förfrågan till cloudflare-servern, samtidigt som vi spelar in DNS- och TLS-paket i Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

I svaret från servern, förutom mycket felsökningsinformation från openssl och curl, får vi ett HTTP-svar med kod 301 från 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/

vilket indikerar att vår förfrågan framgångsrikt nått måservern, hörts och behandlats.

Nu ska vi titta på trafikdumpen i Wireshark, det vill säga vad leverantörens DPI såg i det här fallet.

Det är tydligt att curl först kontaktade DNS-servern för att få den offentliga eSNI-nyckeln för cloudflare-servern – en TXT DNS-förfrågan på _esni.cloudflare.com (paket nr 13). Därefter, med hjälp av openssl-biblioteket, skickade curl en TLS 1.3-förfrågan till cloudflare-servern där SNI-fältet var krypterat med den offentliga nyckeln som erhölls i föregående steg (paket nr 22). Men förutom eSNI-fältet innehöll SSL-hello-paketet även ett vanligt – öppet SNI-fält, som vi kan ange i valfri ordning (i det här fallet – www.hello-rkn.ru).

Detta öppna SNI-fält beaktades inte av cloudflare-servrarna och fungerade endast som en maskering för leverantörens DPI. Cloudflare-servern accepterade vårt ssl-hello-paket, dekrypterade eSNI, extraherade den ursprungliga SNI och behandlade den som om ingenting hade hänt (gjorde allt precis som planerat vid utvecklingen av eSNI).

Det enda vi kan hakka upp oss på ur DPI-synpunkt är den primära DNS-förfrågan på _esni.cloudflare.com. Men vi gjorde DNS-förfrågan öppen bara för att visa hur denna mekanism fungerar inifrån.

För att helt slå undan marken under DPI använder vi den redan nämnda mekanismen DNS-over-HTTPS. En kort förklaring – DOH – är ett protokoll som skyddar mot "man-in-the-middle"-attacker genom att skicka DNS-förfrågan över HTTPS-protokollet.

Vi gör förfrågan igen, men den här gången får vi de offentliga eSNI-nycklarna via HTTPS-protokollet, istället för DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

Dumpen av förfrågetrafiken visas på skärmbilden nedan:

Det är tydligt att curl först kontaktar servern mozilla.cloudflare-dns.com via DoH-protokollet (HTTPS-anslutning till servern 104.16.249.249) för att få värdena för de offentliga nycklarna för kryptering av SNI, och sedan kontaktar den destinationsservern och döljer sig bakom domänen. www.hello-rkn.ru.

Förutom den ovan angivna DoH-upplösaren mozilla.cloudflare-dns.com kan vi också använda andra populära DoH-tjänster, till exempel från den berömda företaget av ondska.
Vi gör en sådan förfrågan:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Och vi får svaret:

< HTTP/1.1 301 Flyttad Permanently
< Datum: Sön, 03 Nov 2019 14:10:22 GMT
< Innehållstyp: text/html
< Överföringskodning: chunked
< Anslutning: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Plats: 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

I det här fallet kontaktade vi den blockerade servern rutracker.nl, med DoH-upplösaren dns.google (här finns ingen skrivfel, det berömda företaget har nu ett sitt eget toppdomän) och skyddade oss med en annan domän som strikt förbjuds att blockera av alla DPI under hot om dödsstraff. Av det mottagna svaret kan man förstå att vår förfrågan har hanterats framgångsrikt.

Som en extra kontroll av att leverantörens DPI reagerar på den öppna SNI som vi överför som skydd — kan vi göra en begäran till rutracker.nl och skydda oss med någon annan förbjuden resurs, till exempel en annan "bra" torrent-tracker:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Vi kommer inte att få något svar från servern, eftersom vår förfrågan kommer att blockeras av DPI-systemet.

En liten sammanfattning till första delen

Så, vi lyckades visa att eSNI fungerar med hjälp av openssl och curl och kontrollera hur domän-frontering baserat på eSNI fungerar. På samma sätt kan vi anpassa våra favoritverktyg som använder openssl-biblioteket för att fungera "under skydd" av andra domäner. Mer om detta i våra kommande artiklar.

Källa: habr.com