Domene-fronting basert på TLS 1.3

Innledning

Moderne bedriftsinnhold filtreringssystemer fra prominente produsenter som Cisco, BlueCoat, og FireEye har mye til felles med de mer kraftfulle søsknene sine — DPI-systemene, som blir sterkt implementert på nasjonalt nivå. Kjernen i både dem og de andre er å inspisere innkommende og utgående internett-trafikk, og basert på svarte/hvite lister, ta beslutninger om å blokkere internettforbindelser. Siden både bruker lignende prinsipper i sin funksjonalitet, vil også metodene for å omgå dem ha mye til felles.

En av teknologiene som gjør det mulig å omgå både DPI og bedriftsfiltreringssystemer effektivt, er domain fronting-teknologi. Den går ut på å få tilgang til en blokkert ressurs ved å dekke seg bak et annet, offentlig domene med et godt omdømme, som engelske google.com, og således ikke vil bli blokkert av noe system.

Det er skrevet en god del artikler om denne teknologien, og mange eksempler er blitt gitt. Imidlertid gir populære og nylig omtalte teknologier som DNS-over-HTTPS og encrypted-SNI, samt den nye versjonen av protokollen TLS 1.3, muligheten til å vurdere en annen variant av domain fronting.

La oss se nærmere på teknologien

På først, la oss definere de grunnleggende begrepene slik at alle har en forståelse av hvem som er hvem og hvorfor alt dette er nødvendig. Vi har nevnt mekanismen eSNI, hvis funksjon vil bli gjennomgått videre. Mekanismen eSNI (encrypted Server Name Indication) er den sikre versjonen av SNI, kun tilgjengelig for protokoll TLS 1.3. Hovedpoenget er å kryptere, inkludert informasjon om hvilket domene forespørselen sendes til.

La oss nå se på hvordan eSNI-mekanismen fungerer i praksis.

La oss si at vi har en nettressurs som blokkeres av et moderne DPI-løsning (la oss ta et kjent torrenttracker som eksempel - rutracker.nl). Når vi prøver å få tilgang til torrenttrackeren, ser vi en vanlig provider-feilmelding om at ressursen er blokkert:

På nettstedet til RKN oppføres dette domenet virkelig i svartelistene:

Ved å forespørre whois kan vi se at selve domenet er 'skjult' bak den skybaserte tjenesteleverandøren Cloudflare.

Men i motsetning til «ekspertene» fra RKN, så valgte de mer teknisk kyndige ansatte fra Beeline (eller de som har lært av den bitre erfaringen med vår berømte regulator) å ikke bare blokkere nettsiden etter IP-adressen, men spesifikt legge til domenenavnet. Dette kan lett bekreftes hvis man ser hva andre domener som skjuler seg bak dette samme IP-adressen, besøker et av dem og ser at tilgangen ikke er blokkert:

Hvordan kan dette skje? Hvordan finner providerens DPI ut hvilket domene nettleseren min går til, når all kommunikasjon skjer over https-protokollen, og vi har ikke lagt merke til at Beeline har byttet ut https-sertifikater? Er det en form for klarsyn eller blir jeg overvåket?

La oss prøve å svare på dette spørsmålet ved å se på trafikken gjennom Wireshark.

På skjermbildet ser vi at nettleseren først får IP-adressen til serveren via DNS, deretter skjer den standard TCP-håndtrykkingen med destinasjonsserveren, og til slutt prøver nettleseren å etablere en SSL-tilkobling til serveren. For dette sender den pakken SSL Client Hello, som inneholder navnet på den opprinnelige domenen i klartekst. Dette feltet er nødvendig for front-end-serveren til Cloudflare for å kunne rute forbindelsen riktig. Det er her providerens DPI fanger oss, og bryter forbindelsen. Vi får ingen melding fra provider, og ser bare den vanlige nettleserfeilen, som om nettsiden er stengt eller bare ikke fungerer:

Nå la oss aktivere eSNI-mekanismen i nettleseren, slik det er skrevet i instruksjonen for Firefox :
For dette åpner vi konfigurasjonssiden i Firefox about:config og aktiverer følgende innstillinger:

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

Etter dette vil vi sjekke om innstillingene fungerer korrekt på Cloudflare-siden med lenken og prøve trikset med torrent-trackeren vår igjen.

Voilà. Vår favoritt tracker åpnet seg, uten bruk av VPN eller proxy-servere. La oss nå se på trafikks dumpen i Wireshark, hva skjedde.

Denne gangen inneholder pakken SSL Client Hello ikke domenenavnet i klartekst, men en ny felt er lagt til pakken - encrypted_server_name - der verdien rutracker.nl befinner seg, og dette feltet kan kun dekrypteres av front-end-serveren til Cloudflare. Dermed har ikke providerens DPI noe annet å gjøre enn å vaske hendene sine og la slik trafikk passere. Det er ikke noen andre muligheter med kryptering.

Nå, hvordan fungerer teknologien i nettleseren — vi har sett på det. Nå la oss prøve å bruke den til mer spesifikke og interessante ting. Først vil vi lære curl å bruke eSNI for å jobbe med TLS 1.3, og samtidig se hvordan domenefronting fungerer basert på eSNI.

Domenefronting med eSNI

Siden curl for å koble til via https-protokollen bruker standardbiblioteket openssl, må vi først sørge for at eSNI støttes der. Det finnes for øyeblikket ingen støtte for eSNI i master-grenene av openssl, så vi må laste ned en spesialgren av openssl, kompilere den og installere den.

Vi kloner depotet fra GitHub og komprimerer som vanlig:

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

$ make
$ cd esnistuff
$ make

Videre kloner vi depotet fra curl og konfigurerer kompileringen med vår sammensatte 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 viktig å angi alle katalogene hvor openssl befinner seg riktig (i vårt tilfelle — det er /opt/openssl/) og sørge for at konfigurasjonsprosessen går uten feil.

Ved vellykket konfigurasjon — vil vi se linjen:

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

$ make

Etter vellykket bygging av pakken vil vi bruke en spesiell bash-fil fra openssl for å konfigurere og kjøre curl. Vi kopierer den til katalogen med curl for enkelhet:

cp /opt/openssl/esnistuff/curl-esni 

og utfører en test https-forespørsel til cloudflare-serveren, samtidig som vi registrerer DNS- og TLS-pakker i Wireshark.

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

I serverens svar, i tillegg til en mengde feilsøkingsinformasjon fra openssl og curl, mottar vi 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/

som vitner om at forespørselen vår ble vellykket levert til destinasjonsserveren, hørt og behandlet.

La oss nå se på trafikksdumpen i Wireshark, altså hva leverandørens DPI så i dette tilfellet.

Det er tydelig at curl først kontaktet DNS-serveren for den offentlige eSNI-nøkkelen for cloudflare-serveren — TXT DNS-forespørsel til _esni.cloudflare.com (pakke nr. 13). Deretter, ved hjelp av openssl-biblioteket, sendte curl en TLS 1.3-forespørsel til cloudflare-serveren hvor SNI-feltet var kryptert med den offentlige nøkkelen som ble mottatt i forrige trinn (pakke nr. 22). Men i tillegg til eSNI-feltet ble det i SSL-hello-pakken også lagt inn et felt med standard — åpen SNI, som vi kan spesifisere i vilkårlig rekkefølge (i dette tilfellet — www.hello-rkn.ru).

Dette åpne SNI-feltet ble ikke vurdert av cloudflare-serverne og fungerte bare som en maskering for providers DPI. Cloudflare-serveren mottok vår ssl-hello-pakke, dekrypterte eSNI, hentet den originale SNI og håndterte den som om ingenting hadde skjedd (gjorde alt akkurat slik det var planlagt under utviklingen av eSNI).

Det eneste som kan bli et problem for DPI i dette tilfellet er den primære DNS-forespørselen til _esni.cloudflare.com. Men vi gjorde DNS-forespørselen åpen bare for å vise hvordan denne mekanismen fungerer innvendig.

For å fjerne grunnlaget for DPI helt bruker vi den allerede nevnte mekanismen DNS-over-HTTPS. En liten forklaring – DOH – er en protokoll som beskytter mot «man-in-the-middle»-angrep ved å sende DNS-forespørselen via HTTPS-protokollen.

La oss gjøre forespørselen på nytt, men denne gangen vil vi få de offentlige eSNI-nøklene over HTTPS, ikke DNS:

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

Trafikkdumpen for forespørselen er presentert i skjermbildet nedenfor:

Det er tydelig at curl først kontakter serveren mozilla.cloudflare-dns.com via DoH-protokollen (HTTPS-forbindelse til server 104.16.249.249), for å få de offentlige nøkkelvektene for kryptering av SNI, og deretter til målserveren, mens den skjuler seg bak domenet. www.hello-rkn.ru.

I tillegg til den nevnte DoH-oppleveren mozilla.cloudflare-dns.com kan vi også bruke andre populære DoH-tjenester, for eksempel fra den berømte ondskapens korporasjon.
La oss gjøre en slik forespørsel:

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 tilfellet har vi kontaktet den blokkerte serveren rutracker.nl ved å bruke DoH-oppløser dns.google (det er ikke en skrivefeil, nå har det berømte selskapet fått sitt eget toppnivådomene) og skjult oss bak et annet domene, som er strengt forbudt å blokkere av alle DPI-systemer under trussel om dødsstraff. Svarene vi mottar viser at forespørselen vår ble behandlet vellykket.

Som en ekstra sjekk på at leverandørens DPI reagerer på åpen SNI, som vi bruker som dekning — kan vi sende en forespørsel til rutracker.nl mens vi skjuler oss bak en annen forbudt ressurs, for eksempel en annen "god" torrent-tracker:

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

Vi får ikke noe svar fra serveren, da forespørselen vår vil bli blokkert av DPI-systemet.

En liten konklusjon til første del

Vi har klart å demonstrere funksjonaliteten til eSNI ved hjelp av openssl og curl og sjekke ytelsen til domene-fronting basert på eSNI. På samme måte kan vi tilpasse våre favorittverktøy som bruker openssl-biblioteket for å fungere "under dekke" av andre domener. Mer om dette i våre kommende artikler.

Kilde: habr.com