Indledning
Moderne virksomhedsindholdsfiltreringssystemer fra så anerkendte producenter som Cisco, BlueCoat, FireEye har ret meget til fælles med deres mere kraftfulde modparter - DPI-systemer, som aktivt implementeres på nationalt plan. Essensen af begges arbejde er at inspicere indgående og udgående internettrafik og på baggrund af sort/hvide lister træffe en beslutning om at forbyde internetforbindelsen. Og da de begge baserer sig på lignende principper i det grundlæggende i deres arbejde, vil metoderne til at omgå dem også have meget til fælles.
En af de teknologier, der giver dig mulighed for ganske effektivt at omgå både DPI og virksomhedssystemer, er domæne-fronting teknologi. Dens essens er, at vi går til en blokeret ressource, gemmer os bag et andet, offentligt domæne med et godt omdømme, som naturligvis ikke vil blive blokeret af noget system, for eksempel google.com.
Der er allerede skrevet en hel del artikler om denne teknologi, og der er givet mange eksempler. De populære og nyligt diskuterede DNS-over-HTTPS- og krypterede-SNI-teknologier, samt den nye version af TLS 1.3-protokollen, gør det dog muligt at overveje en anden mulighed for domænefronting.
Forståelse af teknologien
Lad os først definere lidt grundlæggende begreber, så alle har en forståelse af, hvem der er hvem, og hvorfor alt dette er nødvendigt. Vi nævnte eSNI-mekanismen, hvis funktion vil blive diskuteret yderligere. eSNI-mekanismen (encrypted Server Name Indication) er en sikker version af SNI, kun tilgængelig for TLS 1.3-protokollen. Hovedideen er at kryptere blandt andet information om hvilket domæne anmodningen sendes til.
Lad os nu se på, hvordan eSNI-mekanismen fungerer i praksis.
Lad os sige, at vi har en internetressource, der er blokeret af en moderne DPI-løsning (lad os for eksempel tage den berømte torrent-tracker rutracker.nl). Når vi forsøger at få adgang til en torrent-trackers hjemmeside, ser vi udbyderens standardstub, der indikerer, at ressourcen er blokeret:
På RKN-webstedet er dette domæne faktisk opført i stoplisterne:
Når du forespørger på whois, kan du se, at selve domænet er "skjult" bag cloud-udbyderen Cloudflare.
Men i modsætning til "specialisterne" fra RKN, forbød mere teknisk kyndige medarbejdere fra Beeline (eller undervist af den bitre erfaring fra vores berømte regulator) ikke dumt webstedet efter IP-adresse, men tilføjede domænenavnet til stoplisten. Du kan nemt verificere dette, hvis du ser på, hvilke andre domæner der er gemt bag den samme IP-adresse, besøger et af dem og ser, at adgangen ikke er blokeret:
Hvordan sker dette? Hvordan ved udbyderens DPI, hvilket domæne min browser er på, da al kommunikation foregår via https-protokollen, og vi endnu ikke har bemærket udskiftningen af https-certifikater fra Beeline? Er han clairvoyant eller bliver jeg fulgt?
Lad os prøve at besvare dette spørgsmål ved at se på trafikken gennem wireshark
Skærmbilledet viser, at først henter browseren serverens IP-adresse via DNS, derefter sker der et standard TCP-håndtryk med destinationsserveren, og derefter forsøger browseren at etablere en SSL-forbindelse med serveren. For at gøre dette sender den en SSL Client Hello-pakke, som indeholder navnet på kildedomænet i klartekst. Dette felt er påkrævet af cloudflare-frontend-serveren for at kunne dirigere forbindelsen korrekt. Det er her, udbyderen DPI fanger os og bryder vores forbindelse. Samtidig modtager vi ingen stub fra udbyderen, og vi ser standard browserfejlen som om siden er deaktiveret eller simpelthen ikke virker:
Lad os nu aktivere eSNI-mekanismen i browseren, som skrevet i instruktionerne til :
For at gøre dette åbner vi Firefox-konfigurationssiden about: config og aktiver følgende indstillinger:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Herefter vil vi kontrollere, at indstillingerne fungerer korrekt på cloudflares hjemmeside. og lad os prøve tricket med vores torrent tracker igen.
Voila. Vores foretrukne tracker åbnede uden nogen VPN eller proxy-servere. Lad os nu se på trafikdumpen i wireshark for at se, hvad der skete.
Denne gang indeholder ssl-klienten hello-pakken ikke eksplicit destinationsdomænet, men i stedet dukkede et nyt felt op i pakken - encrypted_server_name - det er her værdien af rutracker.nl er indeholdt, og kun cloudflare frontend-serveren kan dekryptere dette Mark. Og hvis ja, så har udbyderen DPI intet andet valg end at vaske hænder og tillade sådan trafik. Der er ingen andre muligheder med kryptering.
Så vi så på, hvordan teknologien fungerer i browseren. Lad os nu prøve at anvende det på mere specifikke og interessante ting. Og først vil vi lære den samme krølle at bruge eSNI til at arbejde med TLS 1.3, og samtidig vil vi se, hvordan selve den eSNI-baserede domænefronting fungerer.
Domænefronting med eSNI
På grund af det faktum, at curl bruger standard openssl-biblioteket til at oprette forbindelse via https-protokollen, skal vi først og fremmest give eSNI-support der. Der er endnu ingen eSNI-understøttelse i openssl-mastergrenene, så vi skal downloade en speciel openssl-gren, kompilere og installere den.
Vi kloner depotet fra GitHub og kompilerer som normalt:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Dernæst kloner vi depotet med curl og konfigurerer dets kompilering ved hjælp af vores kompilerede 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
Her er det vigtigt at angive alle de mapper, hvor openssl er placeret korrekt (i vores tilfælde er dette /opt/openssl/) og sørge for, at konfigurationsprocessen går igennem uden fejl.
Hvis konfigurationen lykkes, vil vi se linjen:
ADVARSEL: esni ESNI aktiveret, men markeret med EKSPERIMENTEL. Brug med forsigtighed!
$ makeEfter succesfuld opbygning af pakken, vil vi bruge en speciel bash-fil fra openssl til at konfigurere og køre curl. Lad os kopiere det til mappen med krølle for nemheds skyld:
cp /opt/openssl/esnistuff/curl-esni og lav en test https-anmodning til cloudflare-serveren, mens du samtidig optager DNS- og TLS-pakker i Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/I serversvaret vil vi udover en masse debugging information fra openssl og curl modtage et HTTP svar med kode 301 fra 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/
hvilket indikerer, at vores anmodning blev leveret til destinationsserveren, hørt og behandlet.
Lad os nu se på trafikdumpen i wireshark, dvs. hvad udbyderen DPI så i denne sag.
Det kan ses, at curl først vendte sig til DNS-serveren for en offentlig eSNI-nøgle til cloudflare-serveren - en TXT DNS-anmodning til _esni.cloudflare.com (pakke nr. 13). Derefter, ved hjælp af openssl-biblioteket, sendte curl en TLS 1.3-anmodning til cloudflare-serveren, hvor SNI-feltet var krypteret med den offentlige nøgle, der blev opnået i det foregående trin (pakke #22). Men ud over eSNI-feltet inkluderede SSL-hello-pakken også et felt med det sædvanlige - åbne SNI, som vi kan angive i enhver rækkefølge (i dette tilfælde - ).
Dette åbne SNI-felt blev ikke taget i betragtning på nogen måde, når det blev behandlet af cloudflare-servere og tjente kun som en maske for udbyderens DPI. Cloudflare-serveren modtog vores ssl-hello-pakke, dekrypterede eSNI'en, udtrak den originale SNI derfra og behandlede den, som om intet var hændt (den gjorde alt nøjagtigt som planlagt, da eSNI blev udviklet).
Det eneste, der kan fanges i dette tilfælde fra et DPI-synspunkt, er den primære DNS-anmodning til _esni.cloudflare.com. Men vi åbnede kun DNS-anmodningen for at vise, hvordan denne mekanisme virker indefra.
For endelig at trække tæppet ud under DPI, bruger vi den allerede nævnte DNS-over-HTTPS-mekanisme. En lille forklaring - DOH er en protokol, der giver dig mulighed for at beskytte dig mod et man-in-the-middle-angreb ved at sende en DNS-anmodning over HTTPS.
Lad os udføre anmodningen igen, men denne gang vil vi modtage offentlige eSNI-nøgler via https-protokollen, ikke DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Anmodningstrafikdumpet vises på skærmbilledet nedenfor:
Det kan ses, at curl først får adgang til mozilla.cloudflare-dns.com-serveren via DoH-protokollen (https-forbindelse til server 104.16.249.249) for at hente værdierne af offentlige nøgler til SNI-kryptering fra dem og derefter til destinationen server, gemmer sig bag domænet .
Ud over ovenstående DoH-resolver mozilla.cloudflare-dns.com, kan vi bruge andre populære DoH-tjenester, for eksempel fra det berømte onde selskab.
Lad os køre følgende forespørgsel:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Og vi får svaret:
< 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
I dette tilfælde henvendte vi os til den blokerede rutracker.nl-server ved at bruge DoH-resolveren dns.google (der er ingen tastefejl her, nu har den berømte virksomhed sit eget første-niveau-domæne) og dækkede os selv med et andet domæne, som strengt taget er forbudt for alle DPI'er at blokere under smerte ved døden. Baseret på det modtagne svar kan du forstå, at vores anmodning blev behandlet.
Som en ekstra kontrol af, at udbyderens DPI reagerer på den åbne SNI, som vi sender som en dækning, kan vi sende en anmodning til rutracker.nl under dække af en anden forbudt ressource, for eksempel en anden "god" torrent-tracker:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Vi modtager ikke svar fra serveren, fordi... vores anmodning vil blive blokeret af DPI-systemet.
En kort afslutning på første del
Så vi var i stand til at demonstrere funktionaliteten af eSNI ved hjælp af openssl og curl og teste driften af domænefronting baseret på eSNI. På samme måde kan vi tilpasse vores yndlingsværktøjer, der bruger openssl-biblioteket til at arbejde "under dække" af andre domæner. Flere detaljer om dette i vores næste artikler.
Kilde: www.habr.com