Kryptert DNS: DoH og DoT

Forrige leksjon beskrev et vanlig DNS-oppslag som et postkort: lesbart for alle som håndterer det underveis. To IETF-standarder finnes for å legge det postkortet i en konvolutt: DNS over TLS (DoT, RFC 7858) og DNS over HTTPS (DoH, RFC 8484). Begge krypterer det samme oppslaget; de skiller seg hovedsakelig i hvordan de fører det.

DNS over TLS

RFC 7858 fastslår målet direkte: «kryptering levert av TLS eliminerer muligheter for avlytting og manipulering underveis av DNS-spørringer», og adresserer det faktum at «nesten alle DNS-spørringer sendes ukryptert, noe som gjør dem sårbare for avlytting av en angriper.» DoT bruker sin egen dedikerte port, 853, i stedet for den vanlige port 53. RFC-en forklarer hvorfor: «denne anbefalingen mot bruk av port 53 for DNS over TLS er for å unngå komplikasjon i valget av å bruke eller ikke bruke TLS og for å redusere risikoen for nedgraderingsangrep.»

DNS over HTTPS

RFC 8484 tar en annen vei: «hvert DNS-spørring/svar-par kartlegges til en HTTP-utveksling», ført over den samme port 443 som vanlig HTTPS-trafikk bruker. RFC-en bemerker at dette har en sidefordel: «HTTPS-standardporten 443 og muligheten til å blande DoH-trafikk med annen HTTPS-trafikk på samme tilkobling kan avskrekke uprivilegerte enheter underveis fra å forstyrre DNS-operasjoner», fordi et oppslag er vanskeligere å plukke ut og blokkere når det ser ut som enhver annen nettforespørsel.

Hva kryptering skjuler, og hva den fortsatt ikke gjør

Begge standardene stopper en nettverksoperatør eller Wi-Fi-avlytter fra å lese oppslagene dine underveis. Ingen av dem skjuler dem fra resolveren du sendte dem til. RFC 8484 er eksplisitt på at DoH ikke endrer hva selve serveren kan se: den bemerker at «ulike transporter for DNS-spørringer og -svar faktisk gir data som kan brukes til å korrelere forespørsler», og at vanlige nettmekanismer som klient-IP-adresser, informasjonskapsler og TLS-øktinformasjon betyr at «DoH er ikke kjent for å introdusere nye bekymringer utover de assosiert med HTTPS» på serversiden. RFC 7858 bemerker på lignende vis at DoT «ikke adresserer andre sikkerhetsproblemer i DNS» og at «selv med krypterte meldinger kan en godt posisjonert part være i stand til å hente ut enkelte detaljer fra en analyse av meldingstidspunkt og -størrelser.» Kort sagt: kryptert DNS flytter hvem som ser oppslagene dine tilbake til resolveroperatøren du valgte, det fjerner ikke synligheten fullstendig.

Det finnes et andre gap verdt å kjenne til. Å kryptere DNS-oppslaget skjuler ikke i seg selv hvilket nettsted du deretter kobler til: TLS-håndtrykket som følger, inkluderer normalt vertsnavnet i klartekst. Som Cloudflares forklaring av Server Name Indication (SNI) sier det, «SNI inkluderer vertsnavnet i Client Hello-meldingen, eller det aller første steget i et TLS-håndtrykk» — sendt før kryptering er etablert. En utvidelse kalt Encrypted SNI (ESNI), forklarer samme kilde, «bygger videre på SNI-utvidelsen ved å kryptere SNI-delen av Client Hello», noe som «hindrer alle som snoker mellom klienten og serveren fra å se hvilket sertifikat klienten ber om.» Støtte for å skjule SNI avhenger fortsatt av at både nettleseren og nettstedet blir enige om det, og er ennå ikke slik hver tilkobling fungerer.

Hvordan macOS støtter det

Apple dokumenterer en DNS-innstillingskonfigurasjon for Mac, iPhone og iPad som gjør nettopp dette: den lar en enhet «rute en enhets DNS-spørringer gjennom en kryptert DNS-server ved bruk av DNS over HTTPS eller DNS over TLS.» Den leveres som en konfigurasjonsprofil, som kan begrense den krypterte resolveren til spesifikke domener gjennom «supplerende matchdomener», eller bare gjelde på bestemte nettverk ved bruk av «on-demand-regler» som kan matche ting som nettverkets SSID.