Introducció
Els sistemes moderns de filtratge de contingut corporatiu de fabricants tan reconeguts com Cisco, BlueCoat, FireEye tenen molt en comú amb els seus homòlegs més potents: els sistemes DPI, que s'estan implementant activament a nivell nacional. L'essència del treball d'ambdós és inspeccionar el trànsit d'Internet entrant i sortint i, a partir de llistes blanques/negre, prendre la decisió de prohibir la connexió a Internet. I com que tots dos es basen en principis similars en els conceptes bàsics del seu treball, els mètodes per evitar-los també tindran molt en comú.
Una de les tecnologies que us permet evitar amb força eficàcia els sistemes DPI i corporatius és la tecnologia de domini. La seva essència és que anem a un recurs bloquejat, amagant-nos darrere d'un altre, de domini públic amb bona reputació, que òbviament no serà bloquejat per cap sistema, per exemple google.com.
Ja s'han escrit molts articles sobre aquesta tecnologia i s'han donat molts exemples. Tanmateix, les populars i discutides tecnologies DNS sobre HTTPS i SNI xifrat, així com la nova versió del protocol TLS 1.3, permeten considerar una altra opció per al fronting del domini.
Entendre la tecnologia
Primer, anem a definir una mica els conceptes bàsics perquè tothom entengui qui és qui i per què cal tot això. Hem esmentat el mecanisme eSNI, el funcionament del qual es tractarà més endavant. El mecanisme eSNI (encriptat Server Name Indication) és una versió segura de SNI, disponible només per al protocol TLS 1.3. La idea principal és xifrar, entre altres coses, la informació sobre a quin domini s'envia la sol·licitud.
Ara mirem com funciona el mecanisme eSNI a la pràctica.
Suposem que tenim un recurs d'Internet bloquejat per una solució DPI moderna (per exemple, el famós rastrejador de torrents rutracker.nl). Quan intentem accedir al lloc web d'un rastrejador de torrents, veiem el taló estàndard del proveïdor que indica que el recurs està bloquejat:
Al lloc web de RKN, aquest domini apareix realment a les llistes de parades:
Quan consulteu whois, podeu veure que el propi domini està "amagat" darrere del proveïdor de núvol Cloudflare.
Però, a diferència dels "especialistes" de RKN, els empleats més tècnics de Beeline (o ensenyats per l'amarga experiència del nostre famós regulador) no van prohibir estúpidament el lloc per adreça IP, sinó que van afegir el nom de domini a la llista de parades. Podeu comprovar-ho fàcilment si observeu quins altres dominis s'amaguen darrere de la mateixa adreça IP, visiteu un d'ells i comproveu que l'accés no està bloquejat:
Com passa això? Com sap el DPI del proveïdor en quin domini està el meu navegador, ja que totes les comunicacions es fan mitjançant el protocol https i encara no hem notat la substitució dels certificats https de Beeline? És clarivident o em segueixen?
Intentem respondre aquesta pregunta mirant el trànsit a través de Wireshark
La captura de pantalla mostra que primer el navegador obté l'adreça IP del servidor mitjançant DNS, després es produeix una encaixada de mans TCP estàndard amb el servidor de destinació i, a continuació, el navegador intenta establir una connexió SSL amb el servidor. Per fer-ho, envia un paquet SSL Client Hello, que conté el nom del domini d'origen en text clar. Aquest camp és requerit pel servidor frontend de cloudflare per encaminar correctament la connexió. Aquí és on ens atrapa el proveïdor DPI, trencant la nostra connexió. Al mateix temps, no rebem cap taló del proveïdor i veiem l'error estàndard del navegador com si el lloc estigués desactivat o simplement no funcionés:
Ara activem el mecanisme eSNI al navegador, tal com està escrit a les instruccions de :
Per fer-ho obrim la pàgina de configuració de Firefox about: config i activeu la configuració següent:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Després d'això, comprovarem que la configuració funcioni correctament al lloc web de cloudflare. i tornem a provar el truc amb el nostre rastrejador de torrents.
Voila. El nostre rastrejador preferit es va obrir sense cap VPN ni servidor intermediari. Mirem ara l'abocador de trànsit a Wireshark per veure què va passar.
Aquesta vegada, el paquet de salut del client ssl no conté explícitament el domini de destinació, sinó que va aparèixer un camp nou al paquet: encrypted_server_name; aquí és on es troba el valor de rutracker.nl i només el servidor frontend de cloudflare pot desxifrar-ho. camp. I si és així, el proveïdor DPI no té més remei que rentar-se les mans i permetre aquest trànsit. No hi ha altres opcions amb el xifratge.
Per tant, vam mirar com funciona la tecnologia al navegador. Ara intentem aplicar-ho a coses més específiques i interessants. I primer, ensenyarem el mateix curl a utilitzar eSNI per treballar amb TLS 1.3 i, al mateix temps, veurem com funciona el front del domini basat en eSNI.
Fronting de domini amb eSNI
A causa del fet que curl utilitza la biblioteca estàndard openssl per connectar-se mitjançant el protocol https, primer hem de proporcionar-hi suport eSNI. Encara no hi ha suport d'eSNI a les branques mestres d'openssl, així que hem de descarregar una branca especial d'openssl, compilar-la i instal·lar-la.
Clonem el repositori des de GitHub i compilem com de costum:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
A continuació, clonem el dipòsit amb curl i configurem la seva compilació mitjançant la nostra biblioteca openssl compilada:
$ 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
Aquí és important especificar correctament tots els directoris on es troba openssl (en el nostre cas, aquest és /opt/openssl/) i assegurar-se que el procés de configuració transcorre sense errors.
Si la configuració és correcta, veurem la línia:
ADVERTIMENT: esni ESNI habilitat però marcat EXPERIMENTAL. Feu servir amb precaució!
$ makeDesprés de crear el paquet amb èxit, utilitzarem un fitxer bash especial d'openssl per configurar i executar curl. Copiem-lo al directori amb curl per comoditat:
cp /opt/openssl/esnistuff/curl-esni i feu una sol·licitud https de prova al servidor cloudflare, alhora que enregistreu paquets DNS i TLS a Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/A la resposta del servidor, a més de molta informació de depuració d'openssl i curl, rebrem una resposta HTTP amb el codi 301 de 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/
que indica que la nostra sol·licitud s'ha lliurat correctament al servidor de destinació, escoltada i processada.
Ara mirem l'abocador de trànsit a Wireshark, és a dir. què va veure el proveïdor DPI en aquest cas.
Es pot veure que curl va recórrer primer al servidor DNS per obtenir una clau eSNI pública per al servidor cloudflare: una sol·licitud TXT DNS a _esni.cloudflare.com (paquet núm. 13). A continuació, utilitzant la biblioteca openssl, curl va enviar una sol·licitud TLS 1.3 al servidor cloudflare en què el camp SNI estava xifrat amb la clau pública obtinguda al pas anterior (paquet #22). Però, a més del camp eSNI, el paquet SSL-hello també incloïa un camp amb l'habitual - SNI obert, que podem especificar en qualsevol ordre (en aquest cas - ).
Aquest camp SNI obert no es va tenir en compte de cap manera quan el processaven els servidors cloudflare i només servia com a màscara per al DPI del proveïdor. El servidor cloudflare va rebre el nostre paquet ssl-hello, va desxifrar l'eSNI, va extreure l'SNI original d'allà i el va processar com si no hagués passat res (ho va fer tot exactament com estava previst en desenvolupar eSNI).
L'únic que es pot captar en aquest cas des del punt de vista de DPI és la sol·licitud de DNS principal a _esni.cloudflare.com. Però vam fer la sol·licitud de DNS oberta només per mostrar com funciona aquest mecanisme des de dins.
Per treure finalment la catifa de sota DPI, utilitzem el mecanisme DNS-over-HTTPS ja esmentat. Una petita explicació: DOH és un protocol que us permet protegir contra un atac d'home-in-the-middle enviant una sol·licitud DNS a través d'HTTPS.
Tornem a executar la sol·licitud, però aquesta vegada rebrem claus eSNI públiques mitjançant el protocol https, no DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/L'abocament de trànsit de la sol·licitud es mostra a la captura de pantalla següent:
Es pot veure que curl accedeix primer al servidor mozilla.cloudflare-dns.com mitjançant el protocol DoH (connexió https al servidor 104.16.249.249) per obtenir d'ells els valors de les claus públiques per al xifratge SNI, i després a la destinació. servidor, amagat darrere del domini .
A més de la resolució de DoH anterior mozilla.cloudflare-dns.com, podem utilitzar altres serveis populars de DoH, per exemple, de la famosa corporació malvada.
Executem la consulta següent:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/I obtenim la resposta:
< 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
En aquest cas, vam recórrer al servidor rutracker.nl bloquejat, utilitzant el resolutor DoH dns.google (aquí no hi ha cap error d'ortografia, ara la famosa corporació té el seu propi domini de primer nivell) i ens vam cobrir amb un altre domini, que és estrictament prohibit que tots els DPI es bloquegin sota pena de mort. Segons la resposta rebuda, podeu entendre que la nostra sol·licitud s'ha processat correctament.
Com a comprovació addicional que el DPI del proveïdor respon a l'SNI obert, que transmetem com a coberta, podem fer una sol·licitud a rutracker.nl sota l'aparença d'algun altre recurs prohibit, per exemple, un altre rastrejador de torrents "bon":
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/No rebrem resposta del servidor, perquè... la nostra sol·licitud serà bloquejada pel sistema DPI.
Una breu conclusió de la primera part
Així, vam poder demostrar la funcionalitat d'eSNI mitjançant openssl i curl i provar el funcionament del fronting de domini basat en eSNI. De la mateixa manera, podem adaptar les nostres eines preferides que utilitzen la biblioteca openssl per treballar "amb la disfressa" d'altres dominis. Més detalls sobre això als nostres propers articles.
Font: www.habr.com