Az Internet egyik alapvető fontosságú összetevője, a DNS (Domain Name System) rendszer komoly biztonsági hiányosságokkal küzd. Az évek során gyakran merült fel egy-egy új koncepció a problémák ─ például a titkosítás hiányának ─ megoldására, azonban mindeddig egyiket sem sikerült általánosan elfogadottá tenni.
Az alábbiakban röviden bemutatásra kerül egy régebbi (DNSSEC) és két aktuális kezdeményezés (DNS-over-HTTPS, DNS-over-TLS), főbb jellemzői, elsősorban biztonsági és adatvédelmi szempontból. Ezek előnyeinek és hátrányainak megismerése kiemelten fontos egyes technológiai nagyvállalatok törekvéseinek (lásd a Mozilla, valamint a Google ehhez kapcsolódó közleményeit) átfogó értelmezéséhez és a lehetséges kockázatok felméréséhez.
1) Standard DNS
Alapvetően UDP alapú működés, de támogatott a TCP szállítási protokoll is.
Kapcsolódó szabványok:
RFC 1034 – Domain names – concepts and facilities
RFC 1035 – Domain names – implementation and specification
Védelmi mechanizmusok
- DNSSEC: Adatforrás hitelesség és integritás ellenőrzés hozzáadása a DNS szabványhoz.
Kapcsolódó szabványok:
RFC 4033 – DNS Security Introduction and Requirements
RFC 4034 – Resource Records for the DNS Security Extensions
RFC 4035 – Protocol Modifications for the DNS Security Extensions
RFC 2535 – Domain Name System Security Extensions
Alapvető működés
A protokoll egy föntről (TLD) lefelé (subdomain) irányított megoldás, amely asszimetrikus titkosítás alapú digitális aláírás segítségével hivatott megerősíteni a DNS ökoszisztémát. A DNSSEC két fontos összetevővel egészíti ki a DNS protokollt:
- A DNS adat forrásának hitelesítése: a névfeloldók megbizonyosodhatnak arról, hogy a kapott adat valóban abból a zónából érkezett ahonnan kell.
- A DNS adat integritásának megőrzése: a névfeloldók biztosak lehetnek abban, hogy a kapott adat nem került módosításra, mivel az a zóna tulajdonosának privát kulcsával aláírásra került.
Fontos megjegyezni, hogy nem a DNS kérések és válaszok kerülnek aláírásra, hanem magát a DNS információt írja alá annak tulajdonosa.
Egy lekérdezés menete:
- A felhasználó névfeloldást kezdeményez.
- A felhasználók által használt rekurzív névfeloldók lekérdezik az adott DNS zónában lévő adatot.
- A zóna publikus kulcsát is megkapja a rekurzív névfeloldó.
- A rekurzív névfeloldó a publikus kulcs segítségével hitelesíti a DNS adatot.
- Amennyiben a DNS adat hitelesnek mondható, a rekurzív névfeloldó visszaadja az értékét a felhasználónak.
- Amennyiben a DNS adat nem hiteles, a névfeloldó eldobja azt, és hibakódot ad vissza a felhasználónak.
A kiegészítés használata nem elterjedt, a DNS kiszolgálók kis hányada ellenőrzi az aláírást.
Security és privacy szempont
Pozitívum:
- Az internetszolgáltatók (ISP-k) csak az előfizető publikus címéről érkező DNS lekérdezéseket látják, nincs lehetőség azokat felhasználói „profilhoz” kötni, illetve nyomon követni. (Pl. ha a publikus cím mögött egy nagy NAT-olt címtartomány van, akkor a lekérdezéseket ők csak egyként látják.)
Negatívumok:
- Nyílt szöveg, tehát aki a kliens és a kiszolgáló közötti forgalmat láthatja, az megismerheti az adott forrásból indított DNS lekérdezéseket.
- Eltérítés lehetősége.
- Sokszor az egyes hosztok, szolgáltatások már az IP címükből beazonosíthatóak.
2) DNS-over-HTTPS (DoH)
RFC 8484 – DNS Queries over HTTPS (DoH)
Alapvető működés
TCP szállítási réteg, HTTPS (HTTP+TLS) titkosítás alkalmazása.
1. Az ismert módon kiépített HTTPS kapcsolat (alapértelmezett port: 443).
2. DNS lekérdezés küldése az alábbi RFC-k alapján:
- RFC 1035 – Domain names – implementation and specification
- RFC 7766 – DNS Transport over TCP – Implementation Requirements
Bármely olyan alkalmazás képes használni, amely „érti” a HTTPS protokollt.
Security és privacy szempont
Pozitívumok:
- Titkosított csatornán történik a DNS lekérdezések és válaszok küldése.
- Emberi jogi megközelítésből járhatóbb út a technikai megoldása miatt: a kliens és szerver közötti kapcsolat „elrejtőzik” a webes forgalomban.
- „Proxy-barát”.
Negatívumok:
- HTTP fejlécekkel (User-Agent, nyelv beállítások), sütikkel, lehetőség van a felhasználó nyomon követésére.
- OCSP lekérdezések a tanúsítvány érvényességének ellenőrzésére azonosíthatja a lekérdezett oldalt
- SNI alapján lehet azonosítani a DoH szervert.
- A belső hosztnevek kiszivároghatnak az interneten lévő névfeloldók felé.
- Potenciálisan lehetőséget nyújt eszköz alapú nyomon követésre.
Monitoring, kontroll, szűrés szempont
- Nincs megkülönböztetve a normál HTTPS böngészési forgalomtól, így a felismerése, kontrollja HTTPS inspection nélkül szinte lehetetlen.
- Amennyiben külső, harmadik félnél található a DoH kiszolgáló, aki nem az ISP, akkor:
- A DoH-t alkalmazó kliensek közvetlenül a DoH kiszolgálóhoz kapcsolódnak, megkerülve az operációs rendszer beállításait, a hálózati infrastruktúra beállításait és ezek esetleges biztonsági beállításait, így értelmetlenné válhatnak egyes szűrők, szabályzók, biztonsági monitoring.
- Split horizon DNS konfigurációja értelmét veszítheti: egyes hosztnevek lekérdezésére a publikus címüket kapjuk válaszként.
- Ha egy támadó privát hosztnevek mellé képes DNS rekordokat felvenni, akkor a lekérdezés után a kliens alkalmazások akár más irányítása alatt lévő kiszolgálókhoz is csatlakozhatnak.
- Akár minden alkalmazás más és más névfeloldó szolgáltatást használhat (alapértelmezettként vagy fixen beállítva).
Egyszerűen fogalmazva: a névfeloldást az alkalmazásrétegbe helyezi.
Javaslat: Alkalmazása otthoni felhasználásra ajánlott, ott is leginkább a böngészőben és olyan kiszolgálóval, aki nem a felhasználói adatok eladásából profitál.
3) DNS-over-TLS (DoT)
RFC 7858 – Specification for DNS over Transport Layer Security (TLS)
RFC 8310 – Usage Profiles for DNS over TLS and DNS over DTLS
Egyéb: DNS Protocol Related Documents
Alapvető működés
TCP szállítási réteg TLS titkosítással és hitelesítéssel.
- A munkamenet kezdeményezése. A kliens a szerver egy ismert portján (alapértelmezett port: 853/tcp) kezdeményezi a kapcsolódást.
- Miután a kliens sikeresen csatlakozott a szerver adott TCP portjára, megkezdi a TLS kézfogást.
- A szerver prezentálja a TLS tanúsítványát.
- A kliens és a szerver megegyeztek a paraméterekben, és megkezdenek egy TLS munkamenetet. A kapcsolat titkosított.
RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3 - DNS lekérdezés küldése az alábbi RFC-k alapján:
RFC 1035 – Domain names – implementation and specification
RFC 7766 – DNS Transport over TCP – Implementation Requirements
Security és privacy szempont
Pozitívum:
- Titkosított csatornán továbbított DNS lekérdezés és válaszok
Negatívum:
- A munkamenet folytatásához szükséges ticketek (teljesítmény szempontjából fontos) a felhasználó eszközéhez köthetőek.
Monitoring, kontroll, szűrés szempont
A cél port alapján beazonosítható lehet a DoT forgalom.
Implementáció
DNS-over-TLS — dnsdist documentation
Javaslat:
Alkalmazása céges környezetben ajánlott, ahol szükséges a DNS lekérdezések titkosított továbbítása és a forgalom szűrésének lehetősége.
