Problema cheilor DNS: de ce protocoalele criptate au nevoie de o distribuție mai bună

Ai avut vreodată un lacăt scump și n-ai putut găsi cheia? Exact așa se simte pentru milioane de utilizatori internet în momentul de față.

Protocoalele DNS criptate, precum DNS-over-HTTPS (DoH) și DNS-over-TLS (DoT), au fost create ca răspuns la una din cele mai vechi vulnerabilități ale internetului: otrăvirea DNS. Aceste protocoale criptează căutările de domenii, astfel încât cenzorii, ISP-urile sau alți actori nu pot vedea ce site-uri vrei să vizitezi.

Doar că există o problemă pe care cercetătorii de securitate o analizează de ceva timp: criptarea e la fel de bună ca accesul la ea.

Când cenzorii nu mai sparg criptarea, ci blochează cheile

Metoda clasică de cenzură online înseamnă blocarea directă a conținutului. Dar adversarii inteligenți au găsit o soluție mai simplă: de ce să încerce să spargă criptarea când pot opri pur și simplu utilizatorii să obțină cheile criptografice necesare?

Lucrul a devenit vizibil în 2021, când utilizatori GitHub din China au observat un comportament ciudat la cererile DNS criptate. Serverele funcționau. Conexiunile nu erau întrerupte definitiv. Dar cererile reușeau, apoi eșuau câteva minute, apoi funcționau din nou. Era ca și cum cineva limita strategic accesul la infrastructura menită să protejeze confidențialitatea.

Analizele ulterioare au arătat că firewall-ul chinez evoluase. Nu mai bloca pur și simplu. Dezvoltase o strategie în straturi:

• DNS necriptat: în continuare otrăvit cu adrese IP false.
• DNS-over-TLS (port 853): blocat complet la nivel de conexiune.
• DNS-over-HTTPS (port 443): aici apare subtilitatea. Cenzorii detectează cererile DoH către furnizori cunoscuți. O singură cerere declanșează o blocare temporară a IP-ului, suficient de lungă ca serviciul să devină inutilizabil, apoi blocarea se ridică. Repetat de mai multe ori, rezultatul practic este același cu o blocare totală.

Problema fundamentală de arhitectură

Acest tip de atac scoate la iveală o slăbiciune în modul în care am construit infrastructura de confidențialitate: am creat sisteme care depind de distribuirea cheilor criptografice prin internet, dar n-am rezolvat cum să facem asta în siguranță atunci când cineva controlează legăturile fizice.

Un exemplu clar este Encrypted Client Hello (ECH). Protocolul ascunde numele site-ului vizitat prin criptarea câmpului SNI din handshake-ul TLS. Sună bine. Doar că, înainte ca browserul să poată încerca un handshake ECH, trebuie să preia cheile publice din DNS. Așa ajungi într-un cerc vicios: ca să folosești DNS criptat, ai nevoie de o cerere DNS – care poate fi interceptată înainte de a fi criptată.

Ce înseamnă asta pentru dezvoltatori și administratori de infrastructură

Dacă lucrezi cu NameOcean sau gestionezi infrastructură la nivel global, problema te privește direct. Ea arată că presupunerile pe care ne bazăm nu mai sunt valabile peste tot:

• Presupunem că înregistrările DNS sunt accesibile oriunde. În realitate, unele regiuni nu pot ajunge deloc la infrastructura ta DNS.
• Credem că protocoalele criptate rezolvă problema vizibilității. Ele rezolvă doar stratul de criptare, nu și distribuirea cheilor. Un actor cu control asupra rețelei poate crea fricțiune exact la schimbul de chei.
• Credem că cenzura înseamnă blocare totală. În realitate, cenzura modernă funcționează adesea prin throttling strategic și prin crearea de dificultăți. Nu trebuie să fie absolută ca să fie eficientă.

Ce soluții se conturează

De aceea apar din ce în ce mai multe inițiative care explorează:

• Distribuție descentralizată a cheilor, prin DNSSEC sau soluții bazate pe blockchain.
• Obfuscarea traficului DNS criptat, astfel încât să semene cu HTTPS obișnuit.
• Rețele Anycast și distribuție geografică, care fac mai dificilă blocarea anumitor endpoint-uri.
• Soluții la nivel de aplicație, unde cheile sunt distribuite direct din aplicație, nu prin DNS.

Niciuna din aceste abordări nu este perfectă. Toate implică compromisuri între performanță, ușurință în utilizare și complexitate.

Concluzie

Infrastructura de confidențialitate nu există în vid. Ea depinde de arhitectura rețelei, de geopolitică și de modul în care gândesc adversarii.

Când proiectezi sisteme cu accent pe confidențialitate – fie că e vorba de domenii, API-uri sau servicii pentru utilizatori – trebuie să anticipezi: ce ar face un actor cu control la nivel de rețea ca să împiedice accesul? Și care e planul tău de răspuns?

Problema distribuirii cheilor DNS nu e rezolvată. Soluțiile care vor apărea vor fi probabil mai fragmentate, mai distribuite și vor necesita mai multă conștientizare din partea utilizatorilor decât protocoalele inițiale au prevăzut. Nu e o eroare de design – e realitatea construirii de sisteme într-o lume în care confidențialitatea rămâne un subiect politic.