Păstrați-l criptat, păstrați-l în siguranță: Lucrul cu ESNI, DoH și DoT

Cele mai recente evoluții în protecția vieții private pe internet includ indicarea numelui serverului TLS criptat (ESNI) și DNS criptat sub formă de DNS peste HTTPS (DoH), ambele considerate extrem de controversate de colectorii de date.

Așadar, iată o privire rapidă asupra motivelor pentru care există, detaliile despre ceea ce sunt și tehnologia din spatele modului în care funcționează.

DNS trebuie să funcționeze corect

Conexiuni la rețea privată virtuală (VPN) cu tunel divizat, protocolul de descoperire automată a proxy-ului web (WPAD), DNS multicast cu configurație zero (mDNS), liste negre în timp real (RBL) și multe alte tehnologii implementate pe scară largă când DNS nu se întrerupe. t functioneaza corect.

Spargerea internetului pentru profit și faimă

Încă din 2003, utilizatorii de internet au aflat despre importanța DNS la scară globală, atunci când compania care conducea domeniul de nivel superior (TLD) .com a ales să nu mai emită răspunsuri NXDOMAIN . În schimb, au uzurpat identitatea oricărui domeniu inexistent în încercarea de a difuza mai multe anunțuri, de a vinde mai multe domenii și, în cele din urmă, de a genera mai multe venituri. Efectul secundar neașteptat a dus la o dezbatere publică și la un raport condamnător din partea Comitetului Consultativ pentru Securitate și Stabilitate (SSAC) al ICANN. Acest proiect a fost într-adevăr închis, dar din punct de vedere tehnic, vulnerabilitatea a persistat.

Mai târziu, în 2008, o altă încercare de manipulare a DNS-ului pentru profit a fost denunțată public, când unii dintre cei mai mari ISP-uri au ajuns să introducă diverse căi pentru atacuri de scripting între site-uri împotriva literalmente a oricărui site web. Datorită naturii vulnerabilităților, chiar și site-urile web găzduite într-o rețea privată și inaccesibile de pe internet pot fi exploatate.

Problema găsită nu este cu protocoalele de bază de internet, ci este o problemă exacerbată de monetizarea necorespunzătoare a anumitor funcții DNS.

Paul Vixie, Internet Systems Consortium (ISC)

Deși este adevărat că protocoalele în sine nu sunt cu adevărat cauza problemei, este și adevărat că aceste protocoale nu împiedică actorii răi să abuzeze de sistem. Deci, din punct de vedere tehnic, vulnerabilitatea a persistat.

Ruperea internetului pentru supraveghere și cenzură

În 2016, s-a observat că ISP-urile din Iran manipulau DNS. De data aceasta, în loc să injecteze reclame, blocau accesul la serverele de e-mail a 139 din primele 10.000 de domenii de pe internet. Nu este clar dacă aceasta este o politică intenționată de refuzare a serviciului împotriva acestor domenii specifice - asemănătoare cu cenzura renumită la nivel mondial din China - sau poate doar un exemplu de implementare tehnică proastă a oricărui sistem care interceptează interogările DNS.

A nu ști de ce este interceptat DNS-ul este important: chiar dacă lăsăm deoparte întrebările morale și legale despre supravegherea generală și cenzura, tehnologia folosită pentru a face acest lucru nu este, prin natura sa, conformă cu standardele și ar putea foarte bine să interfereze cu utilizarea normală, zilnică, rezonabilă și legală a internetului.

Cu toate acestea, din punct de vedere tehnic, vulnerabilitatea a persistat.

Ruperea Internetului în scopuri nefaste

Desigur, nu doar entitățile comerciale și guvernele încearcă să intercepteze traficul de internet pentru propriile lor mijloace. Există multe exemple de criminali care încearcă să deturneze conexiunile, de obicei în scopul de a fura datele utilizatorilor sau de a păcăli utilizatorii să dezvăluie acreditări importante de acces. Cel mai important, otrăvirea cache-ului DNS a fost folosită pentru a direcționa utilizatorii către site-uri de phishing, pentru a implementa ransomware, a implementa rețele bot, a refuza serviciul către anumite site-uri web și multe altele.

Scurgerile TLS cine se conectează la cine

Transport Layer Security (TLS) este tehnologia din spatele HTTPS, versiunea securizată a HTTP pe care ne bazăm cu toții în fiecare zi. Stabilirea unei conexiuni TLS necesită o serie de pași, timp în care serverul își dovedește identitatea prin prezentarea unui certificat, iar noi chei de criptare sunt schimbate.

Faptul ca serverul să folosească un certificat pentru a-și dovedi identitatea este un pas foarte important, deoarece o parte a certificatului este o cheie publică de criptare asimetrică.

Când clientul trimite un mesaj folosind această cheie, numai serverul care deține cheia privată asociată poate citi mesajul. Ca urmare, oricine interceptează sau ascultă conexiunea este blocat și nu poate citi conținutul.

Cu toate acestea, acel schimb inițial se face încă în mod clar, fără criptare, ceea ce înseamnă că un observator va ști întotdeauna identitatea serverului.

Fronting domeniu

Câteva instrumente de tip anti-cenzură au rezolvat această scurgere în TLS pentru o perioadă de timp, folosind o tehnică cunoscută sub numele de fronting de domeniu. Acest lucru exploatează faptul că, odată ce o conexiune HTTPS este stabilită, majoritatea furnizorilor mari de găzduire nu verifică dacă numele de gazdă prezentat în fiecare solicitare HTTP se potrivește cu cel utilizat în strângere de mână TLS. În ceea ce privește instrumentele de confidențialitate, aceasta a fost văzută ca o caracteristică utilă care permite comunicarea secretă cu un site ascuns. Pentru furnizorii de găzduire și colectorii de date, acest lucru a fost văzut ca un abuz al modului în care a fost implementată specificația.

Aceasta este în sine o vulnerabilitate și, ca atare, a fost remediată de câțiva furnizori importanți de găzduire, inclusiv AWS.

Rezolvarea problemei prin schimbarea standardului: SNI criptat (ESNI)

Ideea din spatele ESNI este de a împiedica TLS să scurgă orice date prin criptarea tuturor mesajelor, inclusiv a mesajului inițial Client Hello . Acest lucru lasă orice observator complet în întuneric despre ce certificat de server îl prezintă serverul.

Pentru a face acest lucru, clientul are nevoie de o cheie de criptare înainte de a realiza conexiunea. Prin urmare, ESNI necesită ca un set specific de chei de criptare ESNI să fie plasat într-o înregistrare SRV în DNS.

Cu toate acestea, detaliile exacte ale acestui lucru sunt încă în flux, deoarece specificațiile nu au fost încă finalizate. În ciuda acestui fapt, o implementare a ESNI a fost deja pusă în producție de Mozilla Firefox și Cloudflare.

Securizarea și criptarea DNS

Pentru ca cheile ESNI să fie livrate fără a fi interceptate, este important să vă protejați împotriva falsificării DNS.

Încă din 1993, comunitatea internetului a încercat să securizeze DNS. IETF observă că întâlnirile timpurii de rezolvare a problemelor au discutat:

1. Protejarea împotriva dezvăluirii datelor DNS către părți neautorizate
2. Asigurarea integritatii datelor
3. Autentificarea originii datelor

Aceste întâlniri au dus la standardul Domain Name System Security Extensions (DNSSEC) în 1997. Standardul a ales să abordeze două din trei dintre aceste preocupări, deoarece echipa de proiectare a luat o decizie explicită de a exclude în mod explicit toate amenințările de dezvăluire a datelor.

Ca atare, DNSSEC înseamnă că utilizatorii pot avea încredere că răspunsurile la interogările lor DNS sunt ceea ce intenționează proprietarii de domenii să fie. În contextul ESNI, asta înseamnă că știm că cheia pe care o primim nu a fost modificată și, din fericire, multe vulnerabilități menționate mai sus dispar atunci când DNSSEC este în uz. Cu toate acestea, nu asigură confidențialitatea și, prin urmare, este încă vulnerabilă la problemele introduse de sistemele de supraveghere și cenzură.

Din păcate, deoarece este complet compatibil cu „DNS nesigur” și destul de dificil de implementat corect, adoptarea DNSSEC este foarte scăzută. Mulți proprietari de domenii renunță parțial la încercarea de a-l configura, așa cum demonstrează numeroasele configurații invalide și pe jumătate configurate văzute în sălbăticie.

DNS prin HTTPS (DoH)

Pentru ca cheile ESNI să fie livrate fără ca observatorii să știe ce site încearcă utilizatorii să viziteze, este important să se protejeze împotriva interceptării DNS. Ca atare, este destul de logic și de înțeles să spunem că DNS criptat (cum ar fi cu DoH) este un lucru bun. Cu toate acestea, așa cum este astăzi, DNS nu este criptat.

Există mișcări ale Mozilla, Google, APNIC, Cloudflare, Microsoft și alții pentru a schimba acest lucru.

Experiența ideală pentru utilizator criptată

Un utilizator care dorește să folosească tehnologiile de mai sus ar putea avea o listă destul de lungă de cerințe când vine vorba de detaliile practice UX ale lucrului cu criptarea. Probabil, ar dori să evite astfel de:

• A fi forțat să folosești un anumit furnizor de servicii DNS (indiferent cât de bun este acesta) sau ca alegerea să fie invizibilă sau dificil de găsit
• Fiecare aplicație de pe un dispozitiv gestionează DNS în mod diferit (de exemplu, Firefox poate găsi lucruri pe care Safari nu le poate găsi)
• Toate aplicațiile de pe un dispozitiv trebuie să își creeze propria implementare DNS securizată în sine
• Trebuie să configurați manual DNS de mai multe ori
• Trebuie să optați pentru confidențialitate și securitate
• Aplicațiile revin la funcționarea nesigură fără consimțământul utilizatorului

Utilizatorii conștienți de confidențialitate ar dori în schimb:

• Confidențialitate față de supravegherea nejustificată de către oricine
• Protecție împotriva publicității direcționate la care nu și-au dat consimțământul
• Protecția propriului conținut publicat (de exemplu, pe un site web personal) împotriva modificării sau manipulării în drum către alți spectatori
• Asigurarea că spectatorii propriului conținut publicat nu vor avea probleme doar pentru accesarea acestuia
• Pentru a continua să aibă opțiunea de a controla DNS-ul pe propriile rețele (deoarece uneori, DNS-ul cu orizont divizat este bun pentru a menține resursele interne la nivelul utilizatorilor interni)
• Posibilitatea de a opta pentru, sau cel puțin de a renunța la filtrare la nivel de DNS (de exemplu, Quad9, CleanBrowsing și OpenDNS Family Shield)
• Configurare ușoară, fără probleme (adică, DHCP)
• Să vi se ceară acordul pentru utilizarea DNS fără criptare
• Protecție nu doar pentru traficul din browser, ci și pentru toate tipurile de trafic, de exemplu, e-mail, Slack, VoIP, SSH, VPN etc.

Eforturile curente de criptare

Ce opțiuni există pentru utilizatorii cu obiectivele de mai sus?

Soluția Mozilla este un început, dar departe de a fi ideală. Ei doar securizează Firefox; implicit este să suprascrieți setările sistemului de operare în favoarea alegerii furnizorului lor (Cloudflare) fără să spuneți acest lucru și revine în tăcere la nesiguranță (în cazurile în care DNS-ul criptat este blocat etc.)

Soluția Google este o abordare mai bună. Securizează Android 9+, care se aplică tuturor aplicațiilor. (Nu sunt sigur de planurile lor pentru sistemul de operare Chrome, dar bănuiesc că este în lucru.) De asemenea, securizează Chrome pe toate platformele, dar declanșează securitatea doar atunci când platforma gazdă este configurată să folosească un furnizor care acceptă securitate. Acest lucru este bun în ceea ce privește alegerea utilizatorului, dar nu ideal, deoarece cade din nou la nesiguranță.

Toate celelalte browsere majore implementează, de asemenea, suport.

În situația ideală pentru utilizatori, comunitatea mai largă de dezvoltatori de software și sisteme de operare ar:

1. Nu mai implementați noi caracteristici de securitate DNS la nivel de aplicație
2. Începeți să le implementați la nivel de sistem de operare
3. Respectați configurația la nivel de sistem de operare sau obțineți consimțământul utilizatorului

Implementând DNS criptat la nivelul sistemului de operare, am putea continua să urmăm același model distribuit pe care îl avem în prezent pentru rezolutorii DNS. Rularea propriului server DNS pe propria rețea și posibilitatea de a face soluția securizată, are sens să fie în continuare o opțiune, așa cum ar trebui să folosești un furnizor centralizat.

Linux și BSD au deja această funcționalitate cu o varietate de opțiuni disponibile. Din păcate, nicio distribuție nu le activează în mod implicit, din câte știu eu. Verificați nss-tls dacă doriți ceva care să se conecteze doar la glibc.

Implementarea DNS-over-TLS de la Google în Android 9+ face deja acest lucru. Funcționează prin testarea serverului DNS pentru suport de criptare. Dacă o are, atunci o va folosi. Dacă nu, atunci - ca și în Chrome - continuă într-o manieră nesigură, fără a cere consimțământul.

Este de remarcat faptul că majoritatea rețelelor sunt configurate să utilizeze servere DNS care nu acceptă criptare, astfel încât soluția încorporată în Android nu schimbă încă nimic pentru majoritatea utilizatorilor. Poate că ar fi mai bine să oferiți să reveniți la un DNS criptat centralizat în cazurile în care descentralizat nu acceptă criptarea.

Pentru dispozitivele Apple și Microsoft, suportul pentru DNS criptat urmează să sosească oficial încă de la data scrierii acestui articol. Întrucât Microsoft și-a anunțat în noiembrie 2019 intențiile de a accepta DNS criptat, sperăm că Apple va urma în curând.

Soluții alternative pentru DNS criptat

Există câteva soluții de soluționare sub formă de proxy care pot fi executate local. Cu acestea, computerul unui utilizator își vorbește DNS necriptat, care apoi vorbește DNS criptat la orice furnizor pentru care este configurat. Aceasta nu este o soluție ideală, dar pe măsură ce soluțiile de soluționare merg, este decentă.

Inspirația pentru scrierea acestui articol este proxy-ul DNSCrypt, care este foarte stabil, are o mulțime de clopote și fluiere și este multiplatformă. Acceptă protocolul DNSCrypt mai vechi, precum și protocoalele mai noi DNS over TLS (DoT) și DNS over HTTPS (DoH).

Pentru utilizatorii de Windows, există un program de instalare și un GUI numit Simple DNSCrypt, care are caracteristici complete și foarte ușor de utilizat.

Îl recomand, dar fiți conștient de faptul că probabil că lumea nu este încă pregătită pentru dvs. și poate fi necesar să o dezactivați din când în când (de exemplu, atunci când trebuie să utilizați un portal captiv la cafeneaua preferată sau la o rețea LAN). parte).

Alte optiuni

În plus, există serverul Technitium DNS, care acceptă DNS criptat, este multiplatformă (Windows, MacOS, Linux pe ARM/Raspberry Pi) și are o interfață web elegantă. Este sub „altul” pentru că este mai mult un instrument complet decât o soluție specifică acestei probleme. (Ar fi probabil o alegere bună dacă doriți să vă rulați serverul DNS Raspberry Pi acasă. Aș fi interesat să aud feedback de la oamenii care îl încearcă în comentariile de mai jos.)

Pentru dispozitivele dvs. Android sau iOS (iPhone, iPad etc.), există și aplicația 1.1.1.1, care vă va forța toate interogările DNS prin serviciul DNS criptat Cloudflare. Am auzit că există și aplicații mai flexibile, cum ar fi Intra, dar încă nu am petrecut timp să le testez.

Desigur, puteți activa și DNS-ul criptat atât în ​​Firefox, cât și în Chrome - țineți cont de toate avertismentele discutate mai sus.

Fiabilitate DNS: Job numărul unu

Există multe controverse cu tehnologia de confidențialitate pe internet. Cu toate acestea, atunci când vine vorba de implementarea măsurilor de securitate și confidențialitate, tehnologia în cauză nu se referă în primul rând la păstrarea secretelor. Este vorba despre asigurarea fiabilității și garantarea faptului că tehnologia continuă să funcționeze corect în ciuda comportamentului celorlalți. Cu toate acestea, trebuie să fim conștienți de faptul că, așa cum tehnologia fără garanții de confidențialitate este proastă, măsurile de protecție care sunt implementate prost nu pot decât să înrăutățească situația.