OARC 45 Dëgjon Pse Enkriptimi i Hopit DNS nga Resolveri te Serveri Autoritativ Ka Ngecur

Sistemi i Emrave të Domenit (DNS), shpesh i përshkruar si librari telefonike e internetit, përkthen emrat e domenit të njohur për njerëzit në adresat numerike IP që përdorin kompjuterët. Pothuajse çdo aktivitet në internet fillon me një kërkesë DNS, dhe nëse dikush mund të vëzhgojë të gjitha kërkesat tuaja DNS, ata mund të ndërtojnë një pamje të detajuar të jetës suaj online. Për vite kjo dobësi e privatësisë tërhoqi pak vëmendje, por zbulimet e Snowden në 2013 e vunë privatësinë e DNS dhe mbikëqyrjen masive në rendin e ditës. Si parazgjedhje, kërkesat dhe përgjigjet DNS udhëtojnë në tekst të thjeshtë, gjë që i bën ato të prekshme nga përgjimi dhe manipulimi nga kushdo në rrugën e rrjetit.

Për ta adresuar këtë, Task Force e Inxhinierisë së Internetit (IETF) zhvilloi protokolle DNS të enkriptuar: DNS mbi TLS (DoT), DNS mbi QUIC (DoQ), dhe DNS mbi HTTPS (DoH), të njohur kolektivisht si DoX. Këto shtojnë enkriptimin dhe vërtetimin e serverit në lidhjen midis pajisjes së përdoruesit ("resolveri stub") dhe një resolveri rekursiv, serveri që bën punën aktuale për të gjetur përgjigjet DNS. Vendosja e një sesioni të enkriptuar shton kosto shtesë krahasuar me një kërkesë të thjeshtë UDP, por sepse pajisja mund të ripërdorë të njëjtin sesion të enkriptuar për shumë kërkesa, kostoja amortizohet. Geoff Huston vëren se në resolverin publik 1.1.1.1 të Cloudflare, DoH përbën rreth 15% të ngarkesës së kërkesave dhe DoT rreth 10%, megjithëse ai dyshon se shifrat janë shumë më të ulëta për resolverët e ISP-ve ku përdoruesi është tashmë në rrjetin e ISP-së.

Megjithatë, kjo mbulon vetëm hopin e parë. Hopi i dytë është midis resolverit rekursiv dhe serverëve autoritativë të emrave që mbajnë regjistrimet zyrtare për një domen. Kjo pjesë është më pak rrezik privatësie individuale sepse adresa IP e përdoruesit nuk përfshihet në kërkesë, por ka ende ekspozim: kërkesat zbulojnë se cili domen po kërkohet, dhe nëse një sulmues mund të ndryshojë një përgjigje, ata mund të helmojnë cache-in e resolverit rekursiv në mënyrë që ai të shërbejë përgjigje të rreme për shumë përdorues derisa cache-i të skadojë, një sulm i njohur si helmim i cache-it. Një zbutje është Minimizimi i Emrit të Kërkesës (RFC 9516), ku resolveri rekursiv dërgon vetëm etiketat minimale të nevojshme për secilin server autoritativ gjatë procesit të zbulimit dhe mund të fshehë llojin origjinal të kërkesës. Një studim matës i vitit 2020 zbuloi se rreth 18% e përdoruesve të internetit kalonin kërkesat e tyre përmes resolverëve rekursivë që kryenin Minimizimin e Emrit të Kërkesës.

Një qasje tjetër është enkriptimi oportunist i hopit rekursiv-te-autoritativ, i përshkruar në RFC 9539 'Vendosja Oportuniste e Njëanshme e DNS-së së Enkriptuar Rekursiv-te-Autoritativ'. Kjo përdor enkriptim pa vërtetim, duke ndjekur parimin e sigurisë oportune në RFC 7435. Një studim i fundit i paraqitur në OARC 46 mati mbështetjen për DNS Autoritativ Oportunist mbi transport të enkriptuar (ADoX). Ai zbuloi se serverët autoritativë për 3,074,281 domene të regjistruara (0.93%) mbështesin një formë të ADoX, dhe duke parë adresat IP të atyre serverëve të emrave, vetëm 2,585 serverë emrash unikë (0.32%) mbështesin ADoX. Një studim i krahasueshëm duke përdorur sondat RIPE Atlas gjeti asnjë resolver rekursiv që përdor ADoQ dhe vetëm 44 sonda pas resolverëve rekursivë që përdornin ADoT, kryesisht të operuara nga shërbimi i resolverit të hapur Quad9. Në praktikë, vendosja ka ngecur: operatorët e serverëve autoritativë shohin pak përfitim në mbështetjen e ADoX nëse asnjë resolver nuk e përdor atë, dhe kostot shtesë të serverit për sesione të enkriptuara janë shumë më të larta se UDP pa gjendje. Resolverët rekursivë nuk shohin asnjë arsye për të mbështetur ADoX nëse asnjë server autoritativ nuk e mbështet atë.

Qasja oportune ka të meta të qarta. Duhen disa shkëmbime rrethore për të provuar një lidhje TLS/TCP ose QUIC me një server autoritativ; për një kërkesë të vetme, kjo kosto shtesë është më e lartë se një transaksion i thjeshtë UDP. Ndryshe nga rasti stub-te-resolver, nuk ka siguri për ripërdorimin e sesionit: resolveri mund të mos e kërkojë kurrë atë server autoritativ përsëri. Gjithashtu, sepse serveri nuk është i vërtetuar në enkriptimin oportunist, një sulmues mund të veprojë ende si njeri në mes; vërtetimi DNSSEC i domeneve të nënshkruara është i nevojshëm për të konfirmuar autenticitetin e përgjigjeve. Në anën pozitive, transporti i enkriptuar mund të trajtojë më mirë përgjigjet e mëdha dhe mundëson qasje eksperimentale si Kërkesat e Zinxhirit CHAIN (RFC 7901).

Një qasje tjetër përdor rekordin e propozuar DELEG për të sinjalizuar aftësitë e transportit të enkriptuar të një serveri. DELEG bazohet në formatin Service Binding (SVCB) dhe nuk është një ndryshim i vogël; ai përfaqëson një ndryshim të madh arkitekturor. Në një rekord DELEG, zona prind përfshin informacion që një etiketë është një pikë delegimi, së bashku me serverët e emrave të zonës së deleguar, çelësat e tyre kriptografikë, adresat IP dhe aftësitë e protokollit, të gjitha në një rekord të vetëm të nënshkruar me DNSSEC. Për një resolver, DELEG mund të komunikojë në mënyrë strikte se cilin transport të enkriptuar mbështesin serverët autoritativë, kështu që resolveri mund të anashkalojë provat oportune dhe thjesht të përdorë protokollin e reklamuar. Megjithatë, Huston vë në dukje se vërtetimi DNSSEC garanton vetëm autenticitetin e përgjigjes përfundimtare DNS; ai nuk garanton që resolveri në fakt ka kaluar nga prindi te fëmija ose që çdo delegim DELEG është vërtetuar në mënyrë të pavarur. Kishte paralajmërime në workshop-in e OARC se zhvendosja e të gjithë DNS-së nga UDP i lehtë në sesione të enkriptuara mund të ketë 'pasoja katastrofike' nëse bëhet me nxitim.

Pra, a është kjo punë më shumë se një ushtrim akademik? Tani për tani, specifikimet për ADoX oportunist dhe DELEG janë kryesisht ushtrime në letër. Korniza aktuale e internetit për vërtetimin e transaksioneve online mbështetet në certifikatat X.509 të emrave të domenit dhe TLS, jo në sigurinë e rezultateve të zgjidhjes DNS. Një sulmues mund të injektojë ende informacion të rremë DNS, por kur një shërbim aplikacioni përdor TLS (për shembull HTTPS), serveri duhet të provojë se zotëron çelësin privat për emrin e domenit; nëse nuk mundet, lidhja braktiset. ADoX ose DELEG nuk e ndryshon atë pamje. Ato gjithashtu nuk mund të zëvendësojnë DNSSEC; të dyja zgjidhin probleme të ndryshme: ADoX ka të bëjë me mënyrën se si një resolver zgjidh një emër, ndërsa DNSSEC ka të bëjë me nëse një përdorues mund t'i besojë rezultatit. Ato janë plotësuese.

Një purist i sigurisë do të donte kontrolle strikte në çdo hap: vërtetimin e rekordeve DELEG të nënshkruara, hapjen e sesioneve të enkriptuara dhe të vërtetuara nga pika fundore me çdo server autoritativ, dhe vërtetimin DNSSEC të përgjigjes përfundimtare. Por realiteti pragmatik është se përdoruesit dhe ofruesit e shërbimeve favorizojnë DNS të shpejtë dhe të lirë. Funksioni i vërtetimit shtyhet në shtresën e aplikacionit përmes shtrëngimit të duarve TLS, dhe operatorët e infrastrukturës DNS nuk mbajnë asnjë nga kostot shtesë. Përpjekja për të shtyrë kostot e sigurisë përsëri në infrastrukturën e zgjidhjes së emrave has në rezistencë të konsiderueshme. Me fjalë të tjera, agjenda DPRIVE u ndal në hopin rekursiv-te-autoritativ sepse nuk kishte interes të mjaftueshëm për të drejtuar atë model infrastrukture.

Cili është e ardhmja për enkriptimin e hopit rekursiv-te-autoritativ? Huston nuk është i sigurt se mund të tregojë ndonjë të ardhme të sigurt. Ekonomia punon kundër operatorëve të infrastrukturës DNS; thithja e kostove shtesë për sesione të enkriptuara pa të ardhura shtesë nuk është një vendim i zgjuar biznesi. Për përdoruesit, DNS mbetet kryesisht falas sepse vërtetimi sigurohet nga TLS në shtresën e aplikacionit. Ajo pamje nuk ka gjasa të ndryshojë së shpejti. Për lexuesit që duan mbrojtje praktike sot, zgjedhja e një resolveri DNS të enkriptuar që i jep përparësi privatësisë, si AEU DNS, mund të ndihmojë në enkriptimin e hopit të parë midis pajisjeve tuaja dhe resolverit, edhe pse enkriptimi më i thellë resolver-te-autoritativ i përshkruar këtu mbetet i pazgjidhur.