Egyes népszerű DNS biztonsági és adatvédelmi technológiák főbb jellemzőinek összehasonlítása

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

RFC 1034 – Domain names – concepts and facilities

RFC 1035 – Domain names – implementation and specification

Alapvetően UDP alapú működés, de támogatott a TCP szállítási protokoll is.

Védelmi mechanizmus

 

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:

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.

  1. A munkamenet kezdeményezése. A kliens a szerver egy ismert portján (alapértelmezett port: 853/tcp) kezdeményezi a kapcsolódást.
  2. Miután a kliens sikeresen csatlakozott a szerver adott TCP portjára, megkezdi a TLS kézfogást.
  3. A szerver prezentálja a TLS tanúsítványát.
  4. 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
  5. 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.