Krypterad DNS: DoH och DoT

Föregående lektion beskrev en vanlig DNS-uppslagning som ett vykort: läsbart för vem som helst som hanterar det på vägen. Två IETF-standarder finns för att stoppa in det vykortet i ett kuvert: DNS over TLS (DoT, RFC 7858) och DNS over HTTPS (DoH, RFC 8484). Båda krypterar samma uppslagning; de skiljer sig huvudsakligen i hur de bär den.

DNS over TLS

RFC 7858 anger sitt mål direkt: "kryptering som tillhandahålls av TLS eliminerar möjligheter för avlyssning och manipulation på vägen av DNS-frågor", vilket adresserar faktumet att "nästan alla DNS-frågor skickas okrypterade, vilket gör dem sårbara för avlyssning av en angripare". DoT använder sin egen dedikerade port, 853, snarare än den vanliga port 53. RFC:n förklarar varför: "denna rekommendation mot användning av port 53 för DNS over TLS är för att undvika komplikationer vid val av användning eller icke-användning av TLS och för att minska risken för nedgraderingsattacker".

DNS over HTTPS

RFC 8484 tar en annan väg: "varje DNS-fråga-svar-par mappas till ett HTTP-utbyte", buret över samma port 443 som vanlig HTTPS-trafik använder. RFC:n noterar att detta har en sidofördel: "HTTPS standardport 443 och möjligheten att blanda DoH-trafik med annan HTTPS-trafik på samma anslutning kan avskräcka obehöriga enheter på vägen från att störa DNS-verksamheten", eftersom en uppslagning är svårare att peka ut och blockera när den ser ut som vilken annan webbförfrågan som helst.

Vad kryptering döljer, och vad den fortfarande inte gör

Båda standarderna hindrar en nätverksoperatör eller Wi-Fi-avlyssnare från att läsa dina uppslagningar under transport. Ingen av dem döljer dem för resolvern du skickade dem till. RFC 8484 är tydlig med att DoH inte förändrar vad servern själv kan se: den noterar att "olika transporter av DNS-frågor och svar tillhandahåller faktiskt data som kan användas för att korrelera förfrågningar", och att vanlig webbmekanik som klient-IP-adresser, kakor och TLS-sessionsinformation innebär att "DoH är inte känt för att introducera nya problem utöver de som förknippas med HTTPS" på serversidan. RFC 7858 noterar på liknande sätt att DoT "inte adresserar andra säkerhetsproblem i DNS" och att "även med krypterade meddelanden kan en välplacerad part kunna utvinna vissa detaljer från en analys av meddelandetider och storlekar". Kort sagt: krypterad DNS flyttar tillbaka vem som ser dina uppslagningar till resolveroperatören du valde, den tar inte bort synligheten helt.

Det finns ett andra gap värt att känna till. Att kryptera DNS-uppslagningen döljer inte i sig vilken sida du sedan ansluter till: TLS-handskakningen som följer inkluderar normalt värdnamnet i klartext. Som Cloudflares förklaring av Server Name Indication (SNI) uttrycker det, "SNI inkluderar värdnamnet i Client Hello-meddelandet, eller det allra första steget i en TLS-handskakning" — skickat innan kryptering upprättas. En utökning kallad Encrypted SNI (ESNI), enligt samma källa, "bygger vidare på SNI-utökningen genom att kryptera SNI-delen av Client Hello", vilket "förhindrar att någon som snokar mellan klienten och servern kan se vilket certifikat klienten begär". Stöd för att dölja SNI beror fortfarande på att både webbläsaren och webbplatsen går med på det, och är ännu inte hur varje anslutning fungerar.

Hur macOS stöder det

Apple dokumenterar en DNS-inställningskonfiguration för Mac, iPhone och iPad som gör exakt detta: den låter en enhet "dirigera en enhets DNS-frågor genom en krypterad DNS-server med DNS over HTTPS eller DNS over TLS". Den levereras som en konfigurationsprofil, som kan begränsa den krypterade resolvern till specifika domäner genom "kompletterande matchningsdomäner", eller tillämpas endast på vissa nätverk med hjälp av "on-demand-regler" som kan matcha saker som nätverkets SSID.