Hyrje
Sistemet moderne të filtrimit të përmbajtjes së korporatave, nga prodhues të njohur si Cisco, BlueCoat, FireEye, kanë shumë të përbashkëta me homologët e tyre më të fuqishëm — sistemet DPI, të cilat po implementohen me forcë në nivel kombëtar. Qëllimi i të dyja është të kontrollojnë trafikun e internetit që hyn dhe del dhe, në bazë të listave të bardha/ të zeza, të marrin vendimin për ndalimin e lidhjes me internetin. Dhe duke qenë se të dyja varen nga parime të ngjashme, metodat për të kaluar ato gjithashtu do të kenë shumë të përbashkëta.
Një nga teknologjitë që lejon kalimin mjaft efikas si për DPI ashtu edhe për sistemet korporative, është teknologjia e domain fronting. Thelbi i saj është se ne qasemi në një burim të bllokuar, duke u mbuluar me një domain tjetër publik, me një reputacion të mirë, i cili sigurisht nuk do të bllokohet nga asnjë sistem, për shembull google.com.
Për këtë teknologji janë shkruar tashmë mjaft artikuj dhe janë dhënë shumë shembuj. Megjithatë, teknologjitë popullore dhe të diskutueshme së fundmi si DNS-over-HTTPS dhe encrypted-SNI, si dhe versioni i ri i protokollit TLS 1.3 ofrojnë mundësinë për të shqyrtuar një tjetër opsion për domain fronting.
Të kuptojmë teknologjinë
Fillimisht, le të sqarojmë disa nga konceptet bazë, në mënyrë që të gjithë të kenë një ide se kush është kush dhe përse është e nevojshme kjo. Ne përmendëm mekanizmin e eSNI, funksionin e të cilit do ta shqyrtojmë më vonë. Mekanizmi eSNI (encrypted Server Name Indication) është një version i sigurt i SNI, i disponueshëm vetëm për protokollin TLS 1.3. Thelbi është të kriptohet gjithashtu informata për atë se cilit domain i dërgohet kërkesa.
Tani le të shqyrtojmë funksionimin e mekanizmit eSNI në praktikë.
Supozoni se kemi një burim interneti që bllokohet nga një zgjidhje moderne DPI (të marrim për shembull, njohurinë e famshme torrent — rutracker.nl). Kur përpiqemi të hyjmë në faqen e torrentit — ne shohim një bllokim standard të ofruesit se burimi është bllokuar:
Në faqen e RKN, ky domain është me të vërtetë i regjistruar në listat e bllokimit:
Kur bëhet një kërkesë whois — duket se vetë domeni është "fshehur" prapa ofruesit cloud, Cloudflare.
Por diferencia de los "especialistas" de la RKN, los empleados más técnicos de Beeline (o aquellos que han aprendido por amarga experiencia de nuestro famoso regulador) no decidieron simplemente bloquear el sitio por dirección IP, sino que lo incluyeron en la lista de bloqueo precisamente por el nombre de dominio. Esto se puede comprobar fácilmente si miramos qué otros dominios se esconden detrás de este mismo adresën IP, visitando uno de ellos y viendo que el acceso no está bloqueado:
¿Cómo es posible esto? ¿Cómo sabe el DPI del proveedor a cuál de los dominios se dirige mi navegador, si todas las comunicaciones ocurren a través del protocolo https y no hemos notado aún sustituciones de certificados https por parte de Beeline? ¿Es acaso un vidente o me están espiando?
Intentemos responder a esta pregunta observando el tráfico a través de Wireshark.
En la captura de pantalla se puede ver que primero el navegador obtiene la dirección IP del servidor a través de DNS, luego se realiza el apretón de manos TCP estándar con el servidor de destino y después el navegador intenta establecer la conexión ssl con el servidor. Para esto envía el paquete SSL Client Hello, que contiene el nombre del dominio de origen en texto claro. Este campo es necesario para que el servidor frontal de Cloudflare pueda enrutear la conexión correctamente. Es aquí donde el DPI del proveedor nos atrapa, rompiendo nuestra conexión. En este caso, no recibimos ningún mensaje de error del proveedor, y vemos el error estándar del navegador como si el sitio estuviera desconectado o simplemente no funcionara:
Ahora activemos el mecanismo eSNI en el navegador, como se indica en las instrucciones para Firefox :
Para ello, abrimos la página de configuración de Firefox about:config y activamos las siguientes configuraciones:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Después de esto, verificaremos la correcta operación de las configuraciones en el sitio de Cloudflare en linkun y volveremos a probar el truco con nuestro tracker de torrents.
¡Voilà! Nuestro querido tracker se abrió, sin ninguna VPN ni servidores proxy. Ahora observemos el volcado de tráfico en Wireshark para ver qué sucedió.
Esta vez, el paquete ssl client hello no contiene explícitamente el dominio de destino, y en su lugar ha aparecido un nuevo campo en el paquete: encrypted_server_name – allí se encuentra el valor rutracker.nl, y solo el servidor frontal de Cloudflare puede desencriptar este campo. Así que el DPI del proveedor no tiene otra opción más que lavarse las manos y permitir dicho tráfico. No hay otras alternativas con cifrado.
Pra ndaj, si funksionon teknologjia në shfletues — ne e shqyrtuam. Tani le të përpiqemi ta aplikojmë atë për gjëra më specifike dhe interesante. Fillimisht, do ta mësojmë curl të përdorë eSNI për të punuar me TLS 1.3 dhe gjithashtu do të shohim se si funksionon domeni i frontimit bazuar në eSNI.
Domeni i frontimit me eSNI
Duke marrë parasysh se curl për lidhjen përmes protokollit https përdor bibliotekën standarde openssl, së pari duhet të sigurojmë mbështetje për eSNI pikërisht aty. Në degët master të openssl, mbështetje për eSNI nuk ekziston ende, kështu që duhet të shkarkojmë një degë speciale openssl, ta kompilojmë dhe ta instalojmë atë.
Klonojmë depozitat nga githubi dhe e kompilojmë si zakonisht:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Më pas — klonojmë depozitat nga curl dhe e konfiguroni kompilimnin e saj duke përdorur bibliotekën tonë të ndërtuar openssl:
$ 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
Këtu është e rëndësishme të specifikoni saktë të gjithë katalogët ku ndodhet openssl (në rastin tonë — kjo është /opt/openssl/) dhe të sigurohemi që procesi i konfigurimit kalon pa gabime.
Në rast të konfigurimit të suksesshëm — do të shohim rreshtin:
WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!
$ makePas ndërtimit të suksesshëm të paketës do të përdorim një skedar special bash nga përbërja e openssl për të konfiguruar dhe nisur curl. Do ta kopjojmë atë në katalogun me curl për lehtësi:
cp /opt/openssl/esnistuff/curl-esni dhe do të kryejmë një kërkesë testuese https në serverin cloudflare, duke regjistruar njëkohësisht paketat DNS dhe TLS në Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Në përgjigjen e serverit, përveç shumë informacionit të diagnostikimit nga openssl dhe curl, ne do të marrim një përgjigje HTTP me kodin 301 nga 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/
gjë që tregon se kërkesa jonë u dërgua me sukses në serverin e destinacionit, u dëgjua dhe u përpunua.
Tani le të shohim dump-in e trafikut në wireshark, pra çfarë pa në këtë rast DPI i ofruesit.
Është e qartë se fillimisht curl i është drejtuar serverit DNS për të marrë çelësin publik eSNI për serverin cloudflare - pyetja DNS TXT për _esni.cloudflare.com (paketa nr. 13). Më pas, duke përdorur bibliotekën openssl, curl dërgoi një kërkesë TLS 1.3 në serverin cloudflare në të cilën fusha SNI ishte e enkriptuar me çelësin publik të marrë në hapin e mëparshëm (paketa nr. 22). Por, përveç fushës eSNI, në paketën SSL-hello u përfshi edhe një fushë me SNI të zakonshëm - të hapur, të cilin ne mund ta tregojmë në një rend të rastësishëm (në këtë rast - www.hello-rkn.ru).
Kjo fushë e SNI-t të hapur nuk u mor parasysh gjatë përpunimit nga serverat cloudflare dhe thjesht shërbente si maskë për DPI-në e ofruesit. Serveri cloudflare pranoi paketën tonë ssl-hello, e dekriptoi eSNI, nxorri SNI origjinal dhe e përpunoi atë sikur të mos kishte ndodhur asgjë (e bëri gjithçka ashtu siç ishte planifikuar gjatë zhvillimit të eSNI).
E vetmja gjë për të cilën në këtë rast mund të kapesh nga pikëpamja e DPI-së është kërkesa fillestare DNS për _esni.cloudflare.com. Por ne e bëmë kërkesën DNS të hapur vetëm për të treguar se si funksionon ky mekanizëm nga brenda.
Për të hequr përfundimisht bazën nga nën këmbët e DPI-së, ne përdorim mekanizmin e përmendur DNS-over-HTTPS. Një shpjegim i vogël - DOH - protokoll që lejon mbrojtjen nga sulmi "njeri ndërmjetës" duke dërguar kërkesën DNS përmes protokollit HTTPS.
Le të realizojmë sërish kërkesën, por këtë herë çelësat publikë eSNI do i marrim përmes protokollit https, e jo DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Dumpi i trafikut të kërkesës është paraqitur në screenshot-in më poshtë:
Është e qartë se fillimisht curl i drejtohet serverit mozilla.cloudflare-dns.com përmes protokollit DoH (bashkimi https në serverin 104.16.249.249), për të marrë nga ata vlerat e çelësave publikë për enkriptimin e SNI-së, dhe pastaj drejt serverit të destinacionit, duke u mbuluar në këtë rast me domenin www.hello-rkn.ru.
Përveç rezolutorit DoH të përmendur më parë mozilla.cloudflare-dns.com, ne mund të përdorim edhe shërbime të tjera të njohura DoH, për shembull, nga korporata e njohur për të keq.
Le të realizojmë një kërkesë të tillë:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Dhe do të marrim përgjigje:
< 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
Në këtë rast ne i kishim bërë një kërkesë serverit të bllokuar rutracker.nl, duke përdorur një DoH-resolver dns.google (nuk ka gabim tipografik, tani kjo korporatë e shquar ka një domen të nivelit të parë) dhe u mbështetëm në një tjetër domen, bllokimi i të cilit është shprehur qartë se ndalohet nga të gjithë DPI nën kërcënimin e dënimit më të ashpër. Nga përgjigjja e marrë, mund të kuptojmë se kërkesa jonë është përpunuar me sukses.
Si një kontroll shtesë që DPI po reagon në SNI të hapur, të cilin ne e çojmë si mbrojtje — mund të bëjmë një kërkesë në rutracker.nl duke u mbrojtur prapa disa resurseve të tjera të ndaluara, për shembull një tjetër ‘torrent tracker’ të mirënjohur:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Nuk do të marrim asnjë përgjigje nga serveri, pasi kërkesa jonë do të bllokohet nga sistemi DPI.
Një përfundim i vogël për pjesën e parë
Pra, na arriti të demonstronim funksionalitetin e eSNI me ndihmën e openssl dhe curl dhe të verifikojmë funksionin e domain-fronting bazuar në eSNI. Po kështu, mund të adaptojmë mjetet tona të preferuara që përdorin bibliotekën openssl për të punuar ‘nën mbrojtje’ të domeneve të tjera. Më shumë për këtë — në artikujt tanë të ardhshëm.
Burimi: habr.com
