Introduktion
Moderne virksomhedssystemer til indholdsfiltrering fra kendte producenter som Cisco, BlueCoat og FireEye har en del til fælles med deres mere kraftfulde slægtninge - DPI-systemerne, som intensiveret implementeres på nationalt niveau. Fælles for begge er, at de skanner indgående og udgående internettrafik og, baseret på sorte/hvide lister, træffer beslutning om at blokere internetforbindelsen. Da begge typer i deres grundprincipper bygger på lignende teorier, vil der også være mange fælles metoder til at omgå dem.
En af de teknologier, der effektivt kan omgå både DPI og virksomhedssystemer, er domænforklædningsteknologien. Ideen er, at vi tilgår en blokeret ressource, mens vi skjuler os bag et andet, offentligt domæne med et godt omdømme, som med sikkerhed ikke vil blive blokeret af noget system, for eksempel google.com.
Der er allerede skrevet en del artikler om denne teknologi, og mange eksempler er blevet nævnt. Dog giver populære og på det seneste meget diskuterede teknologier som DNS-over-HTTPS og encrypted-SNI, samt den nye version af protokollen TLS 1.3, mulighed for at overveje en anden variant af domænforklædning.
Lad os se nærmere på teknologien
Først skal vi definere nogle grundlæggende begreber, så alle forstår, hvem der er hvem, og hvorfor alt dette er nødvendigt. Vi nævnte mekanismen eSNI, hvis funktionalitet vil blive gennemgået senere. Mekanismen eSNI (encrypted Server Name Indication) er en sikker version af SNI, der kun er tilgængelig for protokollen TLS 1.3. Hovedideen er at kryptere også oplysningerne om, hvilket domæne anmodningen sendes til.
Lad os nu overveje eSNI-mekanismens funktionalitet i praksis.
Lad os sige, at vi har en internetressource, der blokeres af en moderne DPI-løsning (vi tager for eksempel den berømte torrent-tracker - rutracker.nl). Ved forsøg på at tilgå torrent-trackerens hjemmeside, ser vi udbyderens standardblokeringsmeddelelse om, at ressourcen er blokeret:
På RKN's hjemmeside er dette domæne faktisk på sortlisten:
Ved forespørgsel af whois kan vi se, at selve domænet er "skjult" bag cloud-udbyderen Cloudflare.
Men i modsætning til "specialisterne" fra RKN valgte de mere teknisk kyndige medarbejdere fra Beeline (eller dem, der har lært af de bitre erfaringer fra vores berømte regulator) ikke bare at blokere hjemmesiden efter IP-adressen, men satte præcist domenenavnet. Det kan man let bekræfte ved at se, hvilke andre domæner der skjuler sig bag denne IP-adresse, besøge et af dem og se, at adgangen ikke er blokeret:
Hvordan er det muligt? Hvordan finder providerens DPI ud af, hvilket af domænerne min browser besøger, når alle kommunikationer foregår via https-protokollen, og vi endnu ikke har bemærket, at Beeline har ændret https-certifikaterne? Er det en synsk person, eller er jeg under overvågning?
Lad os prøve at besvare dette spørgsmål ved at se på trafikken gennem Wireshark.
På skærmbilledet kan man se, at browseren først får IP-adressen til serveren via DNS, derefter finder der en standard TCP-håndtryk sted med destinationsserveren, og så forsøger browseren at etablere en SSL-forbindelse med serveren. For dette sender den pakken SSL Client Hello, som indeholder navnet på den oprindelige domæne i åben form. Dette felt er nødvendigt for frontend-serveren Cloudflare for korrekt at kunne dirigere forbindelsen. Her fanger providerens DPI os og bryder vores forbindelse. Under dette modtager vi ingen blokering fra udbyderen, og ser en standard browserfejl som om hjemmesiden er offline eller bare ikke virker:
Lad os nu aktivere eSNI-mekanismen i browseren, som beskrevet i vejledningen til Firefox :
For at gøre dette åbner vi Firefox' konfigurationsside about:config og aktiverer 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 indstillingskorrektheden på Cloudflare-siden linket og prøve tricket med vores torrent-tracker en gang til.
Voila. Vores elskede tracker åbnede sig uden nogen VPN eller proxy-servere. Lad os nu se på trafikkens dump i Wireshark for at finde ud af, hvad der skete.
Denne gang indeholder ssl client hello-pakken ikke eksplicit domænet, men i stedet er et nyt felt dukket op i pakken - encrypted_server_name - hvor værdien rutracker.nl findes, og kun Cloudflare front-end serveren kan decifrere dette felt. Og i så fald er der ikke andet for DPI fra udbyderen end at vaske hænder og tillade sådan trafik. Der er ingen andre muligheder for kryptering.
Så hvordan fungerer teknologien i browseren - det har vi set. Lad os nu prøve at anvende den til mere specifikke og interessante ting. Först vil vi lære curl at bruge eSNI til at arbejde med TLS 1.3, og samtidig se, hvordan domænefrokastningen fungerer baseret på eSNI.
Domænefrokastning med eSNI
Da curl til HTTPS-forbindelse bruger den standardiserede openssl-bibliotek, skal vi først sørge for, at eSNI understøttes der. I master-grene har openssl endnu ikke eSNI-understøttelse, så vi skal downloade en specialgren af openssl, kompilere og installere den.
Vi kloner repoet fra GitHub og kompilere som normalt:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Dernæst kloner vi repoet fra curl og konfigurerer dets kompilering med vores samlede 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
Det er vigtigt at angive alle kataloger, hvor openssl findes korrekt (i vores tilfælde er det /opt/openssl/) og sikre, at konfigurationsprocessen gennemføres uden fejl.
Ved en vellykket konfiguration vil vi se linjen:
WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!
$ makeEfter en vellykket opbygning af pakken vil vi bruge en speciel bash-fil fra openssl til at konfigurere og starte curl. Vi kopierer den til curl-katalogen for nemheds skyld:
cp /opt/openssl/esnistuff/curl-esni og udfører en test-HTTPS-anmodning til Cloudflare-serveren, mens vi samtidig optager DNS- og TLS-pakker i Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/I serverens svar, udover meget fejlfindinginformation fra openssl og curl, vil vi modtage en HTTP-respons med statuskode 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/
som vidner om, at vores anmodning blev leveret til den tiltænkte server, hørt og behandlet.
Lad os nu se på trafikdumpen i Wireshark, altså hvad udbyderens DPI så i dette tilfælde.
Det ses, at curl først henvendte sig til DNS-serveren for den offentlige eSNI-nøgle for Cloudflare-serveren - en TXT DNS-anmodning til _esni.cloudflare.com (pakke nr. 13). Derefter, ved at bruge openssl-biblioteket, sendte curl en TLS 1.3-anmodning til Cloudflare-serveren, hvor SNI-feltet blev krypteret med den offentlige nøgle, der blev modtaget i det foregående trin (pakke nr. 22). Men bortset fra eSNI-feltet blev der også indsat et felt med det almindelige - åbne SNI i SSL-hello-pakken, som vi kan angive i vilkårlig rækkefølge (i dette tilfælde - www.hello-rkn.ru).
Dette felt med det åbne SNI blev ikke taget i betragtning ved behandlingen af Cloudflare-serverne og var kun en maskering for udbyderens DPI. Cloudflare-serveren accepterede vores ssl-hello-pakke, dechifrerede eSNI, udtræk den oprindelige SNI derfra og behandlede den som var der ikke sket noget (den gjorde alt som det var planlagt ved udviklingen af eSNI).
Det eneste, man kan hænge sig op på i dette tilfælde set fra DPI-synsvinklen, er den primære DNS-anmodning til _esni.cloudflare.com. Men vi gjorde DNS-anmodningen offentlig blot for at vise, hvordan denne mekanisme fungerer indefra.
For endelig at fjerne jorden under fødderne på DPI bruger vi allerede nævnte mekanisme DNS-over-HTTPS. En lille forklaring - DOH - protokollen, der gør det muligt at beskytte mod angreb "manden i midten" ved at sende DNS-anmodningen via HTTPS-protokollen.
Lad os udføre anmodningen igen, men denne gang vil vi modtage de 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/Trafikdumpen for anmodningen er vist på skærmbilledet nedenfor:
Det ses, at curl først henvender sig til serveren mozilla.cloudflare-dns.com via DoH-protokollen (https-forbindelse til server 104.16.249.249) for at få værdierne for de offentlige nøgler til kryptering af SNI, og derefter til den tiltænkte server, mens den skjuler sig bag domænet www.hello-rkn.ru.
Udover den nævnte DoH-resolver mozilla.cloudflare-dns.com kan vi også bruge andre populære DoH-tjenester, for eksempel fra den berømte onde virksomhed.
Lad os udføre sådan en anmodning:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Og vi får et svar:
< HTTP/1.1 301 Permanent 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
I dette tilfælde har vi henvendt os til den blokerede server rutracker.nl ved hjælp af en DoH-resolver fra dns.google (der er ingen tastefejl, nu har den berømte virksomhed fået sit eget topdomæne) og skjult os bag et andet domæne, som er strengt forbudt at blokere af alle DPI'er under trussel om dødsstraf. Af den modtagne respons kan man forstå, at vores anmodning blev behandlet med succes.
Som en yderligere kontrol af, at udbyderens DPI reagerer på den åbne SNI, som vi bruger som dække, kan vi udføre en anmodning til rutracker.nl mens vi skjuler os bag et andet 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 vil ikke modtage et svar fra serveren, da vores anmodning vil blive blokeret af DPI-systemet.
En lille konklusion til første del
Så vi har formået at vise, at eSNI fungerer med openssl og curl og teste domænefronting baseret på eSNI. På samme måde kan vi tilpasse vores yndlingsværktøjer, der bruger openssl-biblioteket, til at fungere 'under dække' af andre domæner. Mere om dette i vores næste artikler.
Kilde: habr.com
