Innledning
Moderne bedriftsinnholdsfiltreringssystemer fra så anerkjente produsenter som Cisco, BlueCoat, FireEye har ganske mye til felles med sine kraftigere motparter - DPI-systemer, som aktivt implementeres på nasjonalt nivå. Essensen av arbeidet til begge er å inspisere innkommende og utgående Internett-trafikk og, basert på svart/hvite lister, ta en beslutning om å forby Internett-tilkoblingen. Og siden begge baserer seg på lignende prinsipper i det grunnleggende i arbeidet sitt, vil metodene for å omgå dem også ha mye til felles.
En av teknologiene som lar deg ganske effektivt omgå både DPI og bedriftssystemer er domenefronting-teknologi. Essensen er at vi går til en blokkert ressurs, gjemmer oss bak en annen, offentlig domene med et godt rykte, som åpenbart ikke vil bli blokkert av noe system, for eksempel google.com.
Det er allerede skrevet ganske mange artikler om denne teknologien og mange eksempler er gitt. Imidlertid gjør de populære og nylig diskuterte DNS-over-HTTPS og krypterte SNI-teknologiene, samt den nye versjonen av TLS 1.3-protokollen, det mulig å vurdere et annet alternativ for domenefronting.
Forstå teknologien
La oss først definere litt grunnleggende begreper slik at alle har en forståelse av hvem som er hvem og hvorfor alt dette er nødvendig. Vi nevnte eSNI-mekanismen, hvis drift vil bli diskutert videre. eSNI-mekanismen (encrypted Server Name Indication) er en sikker versjon av SNI, kun tilgjengelig for TLS 1.3-protokollen. Hovedideen er å kryptere blant annet 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 Internett-ressurs som er blokkert av en moderne DPI-løsning (la oss for eksempel ta den berømte torrent-trackeren rutracker.nl). Når vi prøver å få tilgang til en torrent-trackers nettside, ser vi leverandørens standardstubb som indikerer at ressursen er blokkert:
På RKN-nettstedet er dette domenet faktisk oppført i stopplistene:
Når du spør whois, kan du se at selve domenet er "gjemt" bak skyleverandøren Cloudflare.
Men i motsetning til "spesialistene" fra RKN, forbød ikke mer teknisk kunnskapsrike ansatte fra Beeline (eller lært av den bitre erfaringen til vår berømte regulator) nettstedet etter IP-adresse, men la til domenenavnet på stopplisten. Du kan enkelt bekrefte dette hvis du ser på hvilke andre domener som er skjult bak den samme IP-adressen, besøker en av dem og ser at tilgangen ikke er blokkert:
Hvordan skjer dette? Hvordan vet leverandørens DPI hvilket domene nettleseren min er på, siden all kommunikasjon skjer via https-protokollen, og vi ennå ikke har lagt merke til erstatningen av https-sertifikater fra Beeline? Er han klarsynt eller blir jeg fulgt?
La oss prøve å svare på dette spørsmålet ved å se på trafikken gjennom wireshark
Skjermbildet viser at først henter nettleseren serverens IP-adresse via DNS, deretter oppstår et standard TCP-håndtrykk med målserveren, og deretter prøver nettleseren å etablere en SSL-forbindelse med serveren. For å gjøre dette sender den en SSL Client Hello-pakke, som inneholder navnet på kildedomenet i klartekst. Dette feltet kreves av cloudflare frontend-serveren for å rute tilkoblingen riktig. Det er her leverandøren DPI fanger oss og bryter forbindelsen vår. Samtidig mottar vi ingen stubber fra leverandøren, og vi ser standard nettleserfeil som om siden er deaktivert eller rett og slett ikke fungerer:
La oss nå aktivere eSNI-mekanismen i nettleseren, som skrevet i instruksjonene for :
For å gjøre dette åpner vi Firefox-konfigurasjonssiden about: config og aktiver 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 at innstillingene fungerer som de skal på cloudflares nettside. og la oss prøve trikset med vår torrent tracker igjen.
Voila. Vår favorittsporer åpnet uten VPN eller proxy-servere. La oss nå se på trafikkdumpen i wireshark for å se hva som skjedde.
Denne gangen inneholder ssl-klienten hello-pakken ikke eksplisitt måldomenet, men i stedet dukket det opp et nytt felt i pakken - encrypted_server_name - det er her verdien til rutracker.nl finnes, og bare cloudflare frontend-serveren kan dekryptere dette felt. Og i så fall har ikke leverandøren DPI noe annet valg enn å vaske hendene og tillate slik trafikk. Det er ingen andre alternativer med kryptering.
Så vi så på hvordan teknologien fungerer i nettleseren. La oss nå prøve å bruke det på mer spesifikke og interessante ting. Og først skal vi lære den samme krøllen å bruke eSNI for å jobbe med TLS 1.3, og samtidig vil vi se hvordan den eSNI-baserte domenefronten i seg selv fungerer.
Domenefronting med eSNI
På grunn av det faktum at curl bruker standard openssl-biblioteket for å koble til via https-protokollen, må vi først og fremst gi eSNI-støtte der. Det er ingen eSNI-støtte i openssl-mastergrenene ennå, så vi må laste ned en spesiell openssl-gren, kompilere og installere den.
Vi kloner depotet fra GitHub og kompilerer som vanlig:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Deretter kloner vi depotet med curl og konfigurerer dets kompilering ved å bruke vårt kompilerte 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 viktig å spesifisere korrekt alle katalogene der openssl befinner seg (i vårt tilfelle er dette /opt/openssl/) og sørge for at konfigurasjonsprosessen går gjennom uten feil.
Hvis konfigurasjonen er vellykket, vil vi se linjen:
ADVARSEL: esni ESNI aktivert, men merket med EKSPERIMENTELL. Bruk med forsiktighet!
$ makeEtter vellykket bygging av pakken, vil vi bruke en spesiell bash-fil fra openssl for å konfigurere og kjøre curl. La oss kopiere den til katalogen med krøll for enkelhets skyld:
cp /opt/openssl/esnistuff/curl-esni og foreta en test https-forespørsel til cloudflare-serveren, mens du samtidig registrerer DNS- og TLS-pakker i Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/I serversvaret vil vi i tillegg til mye feilsøkingsinformasjon fra openssl og curl motta 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 indikerer at forespørselen vår ble levert til målserveren, hørt og behandlet.
La oss nå se på trafikkdumpen i wireshark, dvs. hva leverandøren DPI så i dette tilfellet.
Det kan sees at curl først vendte seg til DNS-serveren for en offentlig eSNI-nøkkel for cloudflare-serveren - en TXT DNS-forespørsel til _esni.cloudflare.com (pakke nr. 13). Deretter, ved å bruke openssl-biblioteket, sendte curl en TLS 1.3-forespørsel til cloudflare-serveren der SNI-feltet ble kryptert med den offentlige nøkkelen som ble oppnådd i forrige trinn (pakke #22). Men i tillegg til eSNI-feltet, inkluderte SSL-hello-pakken også et felt med den vanlige - åpen SNI, som vi kan spesifisere i hvilken som helst rekkefølge (i dette tilfellet - ).
Dette åpne SNI-feltet ble ikke tatt i betraktning på noen måte når det ble behandlet av cloudflare-servere og fungerte kun som en maske for leverandørens DPI. Cloudflare-serveren mottok ssl-hello-pakken vår, dekrypterte eSNI-en, hentet ut den originale SNI-en derfra og behandlet den som om ingenting hadde skjedd (den gjorde alt nøyaktig som planlagt ved utvikling av eSNI).
Det eneste som kan fanges opp i dette tilfellet fra et DPI-synspunkt er den primære DNS-forespørselen til _esni.cloudflare.com. Men vi åpnet DNS-forespørselen bare for å vise hvordan denne mekanismen fungerer fra innsiden.
For å endelig trekke teppet ut fra under DPI bruker vi den allerede nevnte DNS-over-HTTPS-mekanismen. En liten forklaring - DOH er en protokoll som lar deg beskytte deg mot et man-in-the-middle-angrep ved å sende en DNS-forespørsel over HTTPS.
La oss utføre forespørselen på nytt, men denne gangen vil vi motta offentlige eSNI-nøkler 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/Forespørselstrafikkdumpen vises i skjermbildet nedenfor:
Det kan sees at curl først får tilgang til mozilla.cloudflare-dns.com-serveren via DoH-protokollen (https-tilkobling til server 104.16.249.249) for å hente verdiene til offentlige nøkler for SNI-kryptering fra dem, og deretter til destinasjonen server, gjemmer seg bak domenet .
I tillegg til ovennevnte DoH-løser mozilla.cloudflare-dns.com, kan vi bruke andre populære DoH-tjenester, for eksempel fra det berømte onde selskapet.
La oss kjøre følgende spørring:
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 vendte vi oss til den blokkerte rutracker.nl-serveren ved å bruke DoH-resolveren dns.google (det er ingen skrivefeil her, nå har det berømte selskapet sitt eget førstenivådomene) og dekket oss med et annet domene, som strengt tatt er forbudt for alle DPIer å blokkere under smerte av døden. Basert på svaret du har mottatt, kan du forstå at forespørselen vår ble behandlet.
Som en ekstra sjekk av at leverandørens DPI svarer på den åpne SNI, som vi overfører som et deksel, kan vi sende en forespørsel til rutracker.nl under dekke av 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 vil ikke motta svar fra serveren, fordi... vår forespørsel vil bli blokkert av DPI-systemet.
En kort avslutning på første del
Så vi var i stand til å demonstrere funksjonaliteten til eSNI ved å bruke openssl og curl og teste driften av domenefronting basert på eSNI. På samme måte kan vi tilpasse favorittverktøyene våre som bruker openssl-biblioteket til å fungere "under dekke" av andre domener. Mer informasjon om dette i våre neste artikler.
Kilde: www.habr.com