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
