DANE maakt het PKI-systeem weer veilig en betaalbaar
Gepubliceerd op 23-02-2013
Deze zomer is de specificatie voor DANE als officiële RFC gepubliceerd. DANE, kort voor DNS-based Authentication of Named Entities, bouwt voort op DNSSEC. Daarmee kunnen nu ook sleutels en certificaten voor beveiligde websites in het DNS-systeem worden opgenomen.
Vervanger CA-certificaten
DANE maakt het PKI-systeem weer veilig en betaalbaar,
vertelt Marco Davids, Technisch Adviseur bij SIDN, de beheerder van het .nl top-level domein. De certificaten waarmee websites, en in mindere mate ook e-mail, op dit moment worden beveiligd, zijn vrij prijzig. Bovendien kent het PKI-systeem enkele ernstige tekortkomingen. DANE voegt een extra check toe. De browser controleert dan niet alleen of er sprake is van een geldig certificaat; er wordt ook geverifieerd of het bewuste certificaat daadwerkelijk bij de betreffende Domeinnaam /website hoort. Deze laatste controle is gebaseerd op DNS en DNSSEC .
Deze methode werkt zo goed, dat je zelfs zou kunnen overwegen om DANE te gebruiken als vervanger van de CA-certificaten. Dan koop je niet langer een certificaat bij een root-CA, maar genereer je een 'self-signed certificaat', dat tot nu toe een waarschuwing in de browser oplevert. Op die manier kan fiks op kosten worden bespaard. Niet voor niets zijn de root-CA's nogal huiverig voor deze ontwikkeling.
Transport Layer Security
Zoek je contact met een beveiligde web-server (via HTTPS, HTTP Secure), dan wordt TLS (Transport Layer Security) gebruikt om de onderlinge versleuteling op te zetten. In de handshake tussen client en server worden de security parameters uitgewisseld waarmee deze twee partijen uiteindelijk tot een veilige verbinding voor de bovenliggende applicatie moeten komen.
Onderdeel daarvan is een zogenaamde key exchange: de server maakt zijn publieke sleutel bekend aan de client. Die sleutel wordt op zijn beurt door de client gebruikt om een (symmetrische) sessie-sleutel naar de server terug te sturen (authenticate-then-encrypt). Daarmee wordt vervolgens de applicatie-data versleuteld (vertrouwelijkheid). Bovendien wordt in de data-stroom een integrity check value meegegeven zodat je zeker weet dat je niet meer of minder data hebt ontvangen dan door de verzender verstuurd (data integrity).
De authenticiteit van het server-certificaat wordt gecontroleerd aan de hand van de trust anchors bij de client. Voor het web worden de daarvoor benodigde CA-certificaten meegeleverd met alle browser software. Gaat daarbij iets mis, dan kan bij een niet-fatale fout de sessie in principe gewoon doorgaan. In het ergste geval is dan geen cryptografische beveiliging beschikbaar. Maar een gebruiker kan er bijvoorbeeld ook voor kiezen om een self-signed certificate (waarvoor dus geen trust anchor beschikbaar is) toch te gebruiken. Is de beveiliging wel noodzakelijk, bijvoorbeeld bij het uitvoeren van een online betaling of bij internet-bankieren, dan kan de client of zijn gebruiker besluiten de verbinding af te breken.
Certificaatketen
De TLS-server geeft een hele keten van certificaten mee,
legt Matthijs Mekking, software developer bij NLnet Labs, uit. De eerste in de keten is het certificaat van de server. Het volgende certificaat certificeert de vorige in de keten. Enzovoort. Het laatste (self-signed) certificaat in de keten komt overeen met een van de trust anchors.
Al deze certificaten worden door de client gebruikt om een volledige vertrouwensketen van server-certificaat naar trust anchor op te bouwen en te valideren.
DANE biedt extra informatie over het certificaat — of de keten — die de gebruiker kan controleren. Zo kun je aangeven dat het certificaat door een bepaalde CA moet zijn uitgegeven. Of: het eerste certificaat in de keten moet mijn service-certificaat zijn. DANE gebruikt daarvoor de TLSA records in het DNS-systeem, en DNSSEC voor de validatie van die records.
Afhankelijk van het 'Matching Type' kunnen TLSA records het volledige certificaat bevatten, alleen de public key, of een hash van die data. Maar het server-certificaat zelf wordt altijd opgehaald via de TLS handshake. De gegevens in het DNS-systeem worden alleen gebruikt om een extra controle uit te voeren.
Met de TLSA records kun je dus een alternatieve vertrouwensketen naar de gebruiker toe adviseren. Je kunt bijvoorbeeld een onbekende CA als trust anchor publiceren. Of aangeven dat je je eigen certificaten uitgeeft.
Extra queries
Volgens Mekking hoeft de implementatie van DANE niet tot extra vertragingen te leiden. Bij het gebruik van DANE moet een TLS-client extra DNS records ophalen. De daarvoor benodigde extra tijd is echter verwaarloosbaar, aangezien de data over het snelle UDP-protocol wordt getransporteerd en de DNS-informatie wordt gecached. Daarnaast kan de extra query al voor de TLS handshake, parallel aan de eerste query voor het IP-adres van de server, worden verstuurd. Hostname, protocol en port nummer zijn immers al bekend.
Bovendien is er een techniek beschikbaar (DNSSEC stapled certificates) waarmee de DANE-informatie helemaal niet meer via DNS hoeft te worden opgevraagd. De complete DNSSEC-keten kan ook worden opgenomen in het server-certificaat. Dat betekent dat DANE helemaal geen invloed meer heeft op het DNS-verkeer.
Toepassingen
Hoewel TLSA records ook complete certificaten kunnen bevatten, worden ze niet gebruikt voor het daadwerkelijke certificaten-transport. DANE stelt alleen maar extra eisen aan de vertrouwensketen.
aldus Mekking. Alle certificaten worden nog steeds door de TLS-server geleverd. Wel kan een self-signed certificaat door middel van een TLSA record van een trust anchor worden voorzien.
RFC 6394 geeft enkele use cases voor DANE. De twee die ik het meest ben tegengekomen zijn de koppeling van je server-certificaat aan een specifieke CA, en het faciliteren van self-signed certificaten. In het eerste geval geeft het TLSA record aan dat een certificaat is uitgegeven door een bepaalde CA. Je wilt immers niet dat een andere CA certificaten voor je uitgeeft die gebruikers ook kunnen accepteren. Zo wordt voorkomen dat als een van de andere CA's gekraakt is daarmee ook jouw authenticatie is aangetast.
De authenticatie op basis van self-signed certificaten maakt geen gebruik van CA's. In feite wordt een certificaat ingezet waarvoor helemaal geen trust anchor beschikbaar is. Met behulp van een TLSA record kan een dergelijk certificaat toch gevalideerd worden.
Uitrol
Tenslotte benadrukt Mekking dat de veiligheid van DANE mede is gebaseerd op de veiligheid van DNSSEC. Dat betekent dat DANE onder andere niet is beveiligd tegen denial-of-service aanvallen. En zolang er een lage deployment van DNSSEC is, geeft DANE ook weinig toegevoegde waarde. Andere problemen moeten wellicht nog aan het licht komen. Nu de standaard klaar is, volgt de uitrol van DANE. Uit dat proces zal blijken welke deployment-problemen er met dit nieuwe beveiligingsprotocol zijn.
