Inleiding
Moderne korporatiewe inhoudfilterstelsels van bekende vervaardigers soos Cisco, BlueCoat, FireEye het nogal baie in gemeen met hul kragtiger eweknieë - DPI-stelsels, wat aktief op nasionale vlak geïmplementeer word. Die kern van albei se werk is om inkomende en uitgaande internetverkeer te inspekteer en, gebaseer op swart/wit lyste, 'n besluit te neem om die internetverbinding te verbied. En aangesien albei van hulle staatmaak op soortgelyke beginsels in die basiese beginsels van hul werk, sal die metodes om dit te omseil ook baie in gemeen hê.
Een van die tegnologieë wat jou toelaat om beide DPI en korporatiewe stelsels redelik effektief te omseil, is domein-front-tegnologie. Die essensie daarvan is dat ons na 'n geblokkeerde hulpbron gaan, wegkruip agter 'n ander, publieke domein met 'n goeie reputasie, wat natuurlik nie deur enige stelsel, byvoorbeeld google.com, geblokkeer sal word nie.
Heelwat artikels is reeds oor hierdie tegnologie geskryf en baie voorbeelde is gegee. Die gewilde en onlangs bespreekte DNS-oor-HTTPS en geïnkripteer-SNI-tegnologieë, sowel as die nuwe weergawe van die TLS 1.3-protokol, maak dit egter moontlik om 'n ander opsie vir domeinfronting te oorweeg.
Verstaan die tegnologie
Kom ons definieer eers 'n bietjie basiese konsepte sodat almal 'n begrip het van wie is wie en hoekom dit alles nodig is. Ons het die eSNI-meganisme genoem, waarvan die werking verder bespreek sal word. Die eSNI (geënkripteerde bedienernaam-aanduiding)-meganisme is 'n veilige weergawe van SNI, slegs beskikbaar vir die TLS 1.3-protokol. Die hoofpunt is om, onder andere, inligting te enkripteer oor na watter domein die versoek gestuur word.
Kom ons kyk nou hoe die eSNI-meganisme in die praktyk werk.
Kom ons sê ons het 'n internethulpbron wat deur 'n moderne DPI-oplossing geblokkeer word (kom ons neem byvoorbeeld die bekende torrent tracker rutracker.nl). Wanneer ons probeer om toegang tot 'n torrent-spoorsnyer se webwerf te kry, sien ons die verskaffer se standaardstub wat aandui dat die hulpbron geblokkeer is:
Op die RKN-webwerf is hierdie domein eintlik in die stoplyste gelys:
As jy navraag doen oor whois, kan jy sien dat die domein self “versteek” is agter die wolkverskaffer Cloudflare.
Maar anders as die "spesialiste" van RKN, het meer tegnies vaardige werknemers van Beeline (of geleer deur die bitter ervaring van ons bekende reguleerder) nie domweg die webwerf per IP-adres verbied nie, maar die domeinnaam by die stoplys gevoeg. Jy kan dit maklik verifieer as jy kyk watter ander domeine agter dieselfde IP-adres weggesteek is, een van hulle besoek en sien dat toegang nie geblokkeer is nie:
Hoe gebeur dit? Hoe weet die verskaffer se DPI op watter domein my blaaier is, aangesien alle kommunikasie via die https-protokol plaasvind en ons nog nie die vervanging van https-sertifikate van Beeline opgemerk het nie? Is hy heldersiend of word ek gevolg?
Kom ons probeer om hierdie vraag te beantwoord deur na die verkeer deur draadhaai te kyk
Die skermkiekie wys dat die blaaier eers die bediener se IP-adres via DNS verkry, dan vind 'n standaard TCP-handdruk met die bestemmingbediener plaas, en dan probeer die blaaier om 'n SSL-verbinding met die bediener te vestig. Om dit te doen, stuur dit 'n SSL Client Hello-pakkie, wat die naam van die brondomein in duidelike teks bevat. Hierdie veld word deur die cloudflare-voorkantbediener vereis om die verbinding korrek te stuur. Dit is waar die verskaffer DPI ons vang en ons verbinding verbreek. Terselfdertyd ontvang ons geen stomp van die verskaffer nie, en ons sien die standaardblaaierfout asof die webwerf gedeaktiveer is of eenvoudig nie werk nie:
Laat ons nou die eSNI-meganisme in die blaaier aktiveer, soos geskryf in die instruksies vir :
Om dit te doen, maak ons die Firefox-konfigurasiebladsy oop about: config en aktiveer die volgende instellings:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Hierna sal ons kyk of die instellings reg werk op die cloudflare-webwerf. en kom ons probeer weer die truuk met ons torrent-spoorsnyer.
Voila. Ons gunsteling spoorsnyer het oopgemaak sonder enige VPN- of proxy-bedieners. Kom ons kyk nou na die verkeershoop in wireshark om te sien wat gebeur het.
Hierdie keer bevat die ssl-kliënt hallo-pakket nie eksplisiet die bestemmingsdomein nie, maar in plaas daarvan het 'n nuwe veld in die pakket verskyn - encrypted_server_name - dit is waar die waarde van rutracker.nl vervat is, en slegs die cloudflare-voorkantbediener kan dit dekripteer veld. En indien wel, dan het die verskaffer DPI geen ander keuse as om sy hande te was en sulke verkeer toe te laat nie. Daar is geen ander opsies met enkripsie nie.
Dus, ons het gekyk na hoe die tegnologie in die blaaier werk. Kom ons probeer dit nou op meer spesifieke en interessante dinge toepas. En eerstens sal ons dieselfde krul leer om eSNI te gebruik om met TLS 1.3 te werk, en terselfdertyd sal ons sien hoe die eSNI-gebaseerde domeinfront self werk.
Domain fronting met eSNI
As gevolg van die feit dat curl die standaard openssl-biblioteek gebruik om via die https-protokol te koppel, moet ons eerstens eSNI-ondersteuning daar verskaf. Daar is nog geen eSNI-ondersteuning in die openssl-meestertakke nie, so ons moet 'n spesiale openssl-tak aflaai, saamstel en installeer.
Ons kloon die bewaarplek vanaf GitHub en stel soos gewoonlik saam:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Vervolgens kloon ons die bewaarplek met krul en konfigureer die samestelling daarvan met behulp van ons saamgestelde openssl-biblioteek:
$ 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
Hier is dit belangrik om al die gidse waar openssl geleë is korrek te spesifiseer (in ons geval is dit /opt/openssl/) en seker te maak dat die konfigurasieproses sonder foute deurgaan.
As die konfigurasie suksesvol is, sal ons die reël sien:
WAARSKUWING: esni ESNI geaktiveer, maar gemerk EXPERIMENTAL. Gebruik met omsigtigheid!
$ makeNadat ons die pakket suksesvol gebou het, sal ons 'n spesiale bash-lêer van openssl gebruik om curl te konfigureer en uit te voer. Kom ons kopieer dit gerieflikheidshalwe na die gids met krul:
cp /opt/openssl/esnistuff/curl-esni en maak 'n toets https-versoek aan die cloudflare-bediener, terwyl jy gelyktydig DNS- en TLS-pakkies in Wireshark opneem.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/In die bedienerantwoord, sal ons, benewens baie ontfoutingsinligting van openssl en curl, 'n HTTP-reaksie met kode 301 van cloudflare ontvang.
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/
wat aandui dat ons versoek suksesvol by die bestemmingsbediener afgelewer is, gehoor en verwerk is.
Kom ons kyk nou na die verkeershoop in wireshark, m.a.w. wat die verskaffer DPI in hierdie geval gesien het.
Dit kan gesien word dat krul eers na die DNS-bediener gedraai het vir 'n publieke eSNI-sleutel vir die cloudflare-bediener - 'n TXT DNS-versoek aan _esni.cloudflare.com (pakket No. 13). Toe, met behulp van die openssl-biblioteek, het curl 'n TLS 1.3-versoek na die cloudflare-bediener gestuur waarin die SNI-veld geïnkripteer is met die publieke sleutel wat in die vorige stap verkry is (pakkie #22). Maar, benewens die eSNI-veld, het die SSL-hello-pakket ook 'n veld ingesluit met die gewone - oop SNI, wat ons in enige volgorde kan spesifiseer (in hierdie geval - ).
Hierdie oop SNI-veld is op geen manier in ag geneem wanneer dit deur cloudflare-bedieners verwerk is nie en het slegs gedien as 'n masker vir die verskaffer DPI. Die cloudflare-bediener het ons ssl-hello-pakkie ontvang, die eSNI ontsyfer, die oorspronklike SNI daarvandaan onttrek en dit verwerk asof niks gebeur het nie (dit het alles presies gedoen soos beplan toe eSNI ontwikkel is).
Die enigste ding wat in hierdie geval uit 'n DPI-oogpunt gevang kan word, is die primêre DNS-versoek aan _esni.cloudflare.com. Maar ons het die DNS-versoek slegs oopgemaak om te wys hoe hierdie meganisme van binne af werk.
Om die mat uiteindelik onder DPI uit te trek, gebruik ons die reeds genoemde DNS-oor-HTTPS-meganisme. 'N Klein verduideliking - DOH is 'n protokol wat jou toelaat om teen 'n man-in-die-middel-aanval te beskerm deur 'n DNS-versoek oor HTTPS te stuur.
Kom ons voer die versoek weer uit, maar hierdie keer sal ons publieke eSNI-sleutels ontvang via die https-protokol, nie DNS nie:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Die versoekverkeerstorting word in die skermkiekie hieronder gewys:
Dit kan gesien word dat krul eers toegang tot die mozilla.cloudflare-dns.com-bediener verkry via die DoH-protokol (https-verbinding met bediener 104.16.249.249) om van hulle die waardes van publieke sleutels vir SNI-enkripsie te verkry, en dan na die bestemming bediener, skuil agter die domein .
Benewens die bogenoemde DoH-resolver mozilla.cloudflare-dns.com, kan ons ander gewilde DoH-dienste gebruik, byvoorbeeld van die beroemde bose korporasie.
Kom ons voer die volgende navraag uit:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/En ons kry die antwoord:
< 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
In hierdie geval het ons na die geblokkeerde rutracker.nl-bediener gedraai met die DoH-resolver dns.google (daar is geen tikfout hier nie, nou het die beroemde korporasie sy eie eerstevlakdomein) en onsself bedek met 'n ander domein, wat streng is verbied vir alle DPI's om onder pyn van dood te blokkeer. Op grond van die antwoord wat ontvang is, kan jy verstaan dat ons versoek suksesvol verwerk is.
As 'n bykomende kontrole dat die verskaffer se DPI reageer op die oop SNI, wat ons as 'n omslag oordra, kan ons 'n versoek aan rutracker.nl rig onder die dekmantel van 'n ander verbode hulpbron, byvoorbeeld 'n ander "goeie" torrent-spoorsnyer:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Ons sal nie 'n antwoord van die bediener ontvang nie, want... ons versoek sal deur die DPI-stelsel geblokkeer word.
'n Kort afsluiting van die eerste deel
Ons kon dus die funksionaliteit van eSNI demonstreer deur openssl en curl te gebruik en die werking van domeinfronting op grond van eSNI te toets. Op dieselfde manier kan ons ons gunsteling gereedskap wat die openssl-biblioteek gebruik, aanpas om "onder die dekmantel" van ander domeine te werk. Meer besonderhede hieroor in ons volgende artikels.
Bron: will.com