Inleiding tot DANE en TLSA
Public Key Infrastructure ( PKI) vertrouwt op certificeringsinstanties (CA's) om de legitimiteit van een TLS-certificaat te garanderen . Het probleem is dat elk van de honderden CA's die door browsers worden vertrouwd, een certificaat kan uitgeven voor elk domein, ongeacht of dat domein een relatie heeft met die CA. Als zelfs maar één van die CA's wordt gecompromitteerd, verkeerd geconfigureerd of onder druk gezet, kan een aanvaller een frauduleus certificaat voor uw domein verkrijgen dat browsers zonder meer zullen vertrouwen. Dit is de structurele zwakte in het CA-vertrouwensmodel en het is geen hypothetisch probleem. Incidenten met onjuiste certificaatuitgifte hebben zich in het verleden voorgedaan en zullen zich in de toekomst opnieuw voordoen.
DANE, wat staat voor DNS-Based Authentication of Named Entities, is een beveiligingsprotocol dat deze zwakte verhelpt. DANE, gedefinieerd in RFC 6698, stelt domeineigenaren in staat hun TLS-certificaatinformatie rechtstreeks in de DNS te publiceren, beschermd door DNSSEC-handtekeningen. Simpel gezegd: in plaats van te vertrouwen op een van de honderden certificeringsinstanties om te bevestigen dat een certificaat geldig is, stelt DANE een domeineigenaar in staat te zeggen: dit is het exacte certificaat of de sleutel die u van mijn server zou moeten zien. Elk ander certificaat moet worden geweigerd.
DANE deelt deze informatie via een TLSA DNS-record. Een TLSA-record bevindt zich in de DNS-zone van een domein en vertelt verbindende clients welk TLS-certificaat of welke publieke sleutel ze moeten accepteren. Samen geven DANE en TLSA domeineigenaren veel meer controle over certificaatvalidatie.
Waarom traditionele PKI alleen niet voldoende is
Om te begrijpen waarom DANE belangrijk is, moet je eerst zien waar PKI tekortschiet. Het CA-model is gebaseerd op één idee: browsers en besturingssystemen bevatten een lijst met vertrouwde root-CA's, en elk certificaat dat door een van die CA's is ondertekend, wordt als geldig beschouwd. Dat klinkt prima, totdat je beseft dat er wereldwijd meer dan 100 vertrouwde root-CA's zijn.
Het probleem is als volgt: elk van die certificeringsinstanties (CA's) kan een certificaat uitgeven voor elk domein. Als een CA gehackt wordt of onder druk gezet wordt door een overheid of een kwaadwillende partij, kan deze een frauduleus certificaat voor uw domein aanmaken. De meeste klanten zullen dit certificaat zonder meer vertrouwen. Dit is geen theorie. In 2011 werd een CA genaamd DigiNotar gehackt en werden er valse certificaten uitgegeven voor grote domeinen, waaronder Google. Dit incident maakte duidelijk hoe kwetsbaar het CA-model kan zijn.
Tools zoals Certificate Transparency (CT) -logs en CAA-records hebben de situatie verbeterd. Maar ze waarschuwen je meestal pas nadat een ongeldig certificaat al is uitgegeven. DANE is anders. Het is een preventieve maatregel. Het vergrendelt welke certificaten acceptabel zijn op DNS-niveau, voordat er ook maar enige manipulatie van de TLS-handshake mogelijk is.
Hoe DNSSEC DANE mogelijk maakt
DANE werkt niet zelfstandig. Het is volledig afhankelijk van DNSSEC, de Domain Name System Security Extensions. Zonder DNSSEC zou het toevoegen van certificaatinformatie aan DNS weinig zin hebben, omdat DNS-records vrij gemakkelijk gemanipuleerd kunnen worden.
DNSSEC voegt cryptografische handtekeningen toe aan de gehele DNS-hiërarchie. Elk niveau van de DNS-boom, van de rootzone tot het top-leveldomein (TLD) en uw specifieke domeinzone, ondertekent de records daaronder. Wanneer een resolver een TLSA-record ophaalt, laat DNSSEC deze controleren of het record authentiek en ongewijzigd is.
Beschouw DNS zonder DNSSEC als een brief zonder verzegeling. Iedereen die de brief onderweg aanraakt, kan de inhoud wijzigen. DNSSEC voegt die verzegeling bij elke stap toe. DANE gebruikt vervolgens dat verzegelde, vertrouwde kanaal om bindende instructies te geven over welke TLS-certificaten acceptabel zijn.
Om DANE daadwerkelijke bescherming te bieden, moet DNSSEC volledig worden geïmplementeerd en gevalideerd van begin tot eind, van de gezaghebbende DNS-zone tot aan de client die de DNS oplost. DANE dat is gebaseerd op niet-ondertekende DNS biedt geen echte beveiliging.
Inzicht in TLSA-records en hun velden
Een TLSA-record wordt gepubliceerd onder een specifieke DNS-naam en bevat het protocol, de poort en het domein van de service. Het TLSA-record voor HTTPS op poort 443 bij example.com zou er bijvoorbeeld als volgt uitzien:
_443._tcp.example.com. IN TLSA <Usage> <Selector> <MatchingType> <CertificateData>Elk van de vier vakgebieden heeft een specifieke taak:
- Certificaatgebruik (0 tot 3): Dit veld bepaalt waaraan het record wordt gekoppeld. Gebruikswijze 3, ook wel bekend als DANE-EE, is de strengste optie. Deze koppelt direct aan het eigen certificaat of de eigen sleutel van de server, waardoor de traditionele CA-validatie volledig wordt overgeslagen.
- Keuzeknop (0 of 1): Dit geeft de client aan of er een vergelijking moet worden gemaakt met het volledige certificaat (0) of alleen met de SubjectPublicKeyInfo, oftewel de publieke sleutel (1). Het vastzetten van de publieke sleutel heeft over het algemeen de voorkeur, omdat deze geldig blijft, zelfs wanneer het certificaat wordt vernieuwd, zolang het sleutelpaar maar hetzelfde blijft.
- Overeenkomsttype (0, 1 of 2): Dit definieert hoe de certificaatgegevens worden weergegeven. Een waarde van 1 betekent SHA-256 en een waarde van 2 betekent SHA-512. Het gebruik van een hash wordt sterk aanbevolen om de DNS-recordgrootte beheersbaar te houden.
- Gegevens van certificeringsinstanties: Dit is de werkelijke waarde, ofwel een hash ofwel het onbewerkte certificaat of de sleutel, die de client vergelijkt met het certificaat dat de server presenteert tijdens de TLS-handshake.
Een server die een door een certificeringsinstantie (CA) ondertekend certificaat gebruikt, kan gebruik 1 (DANE-TA) gebruiken om te pinnen naar de publieke sleutel van de uitgevende CA. Een server die een zelfondertekend certificaat gebruikt, gebruikt doorgaans gebruik 3 (DANE-EE) om direct te pinnen naar zijn eigen bladcertificaat.
Hoe DANE bescherming biedt tegen MITM- en downgrade-aanvallen
DANE is het meest nuttig wanneer je ziet hoe het twee van de gevaarlijkste aanvalstypes in netwerkbeveiliging blokkeert: Man-in-the-Middle (MITM) -aanvallen en TLS-downgrade-aanvallen.
Bij een MITM-aanval positioneert een aanvaller zich tussen een client en een server. Hij onderschept de verbinding en presenteert zijn eigen certificaat aan de client, terwijl hij het verkeer doorstuurt naar de echte server. Als de aanvaller erin slaagt een frauduleus, maar door een certificeringsinstantie (CA) vertrouwd certificaat voor het doeldomein te bemachtigen, kan de client de inbraak niet detecteren. DANE dicht dit gat. Zelfs als het valse certificaat geldig lijkt voor de browser, komt het niet overeen met het TLSA-record in DNS, en een DANE-compatibele client zal de verbinding weigeren.
Downgrade-aanvallen werken anders. De aanvaller verstoort de TLS-handshake om beide partijen te dwingen een oudere, zwakkere protocolversie of cipher suite te gebruiken, die gemakkelijker te kraken is. Sommige downgrade-aanvallen gaan nog verder en ontmantelen de encryptie volledig door middel van SSL-stripping. DANE helpt dit tegen te gaan in combinatie met SMTP-beveiligingstools zoals STARTTLS. Wanneer een mailserver een TLSA-record publiceert voor zijn SMTP-poort, weet een verzendende mailtransferagent (MTA) die dat record valideert dat TLS vereist is en welk certificaat er verwacht kan worden. Elke poging om TLS te downgraden of te strippen wordt dan detecteerbaar.
Het is belangrijk om eerlijk te zijn over de beperkingen van DANE. De browserondersteuning is inconsistent. De belangrijkste browsers valideren TLSA-records voor HTTPS niet standaard, waardoor dagelijks internetgebruik zonder extra plug-ins of aangepaste configuraties niet echt profiteert van DANE. DANE werkt het best in server-naar-server-omgevingen, met name voor e-mailbezorging, en in omgevingen waar de volledige technologiestack onder uw controle staat.
Hoe encryptieconsultancy kan helpen
DANE voegt een belangrijke laag controle toe aan de validatie van TLS-certificaten, maar introduceert tegelijkertijd aanzienlijke operationele complexiteit. DNSSEC moet volledig geïmplementeerd en gevalideerd zijn. TLSA-records moeten synchroon met elke certificaatvernieuwing worden bijgewerkt. En de onderliggende PKI-basis moet solide zijn voordat er iets aan DNS kan worden gekoppeld. Dit zijn geen eenmalige taken. Het zijn doorlopende operationele verantwoordelijkheden die toenemen naarmate uw certificaatomgeving groeit.
De PKI-services en CertSecure Manager van Encryption Consulting pakken beide kanten van die uitdaging aan: de architectuur en het doorlopende beheer.
Voor organisaties die hun PKI-basis opbouwen of versterken:
Onze PKI-services helpen u bij het ontwerpen en implementeren van een certificaatautoriteithiërarchie die is afgestemd op omgevingen die strikte certificaatcontrole vereisen. Of u nu overstapt op DANE-EE om rechtstreeks aan servercertificaten te koppelen of DANE-TA gebruikt om vertrouwen te verankeren in een interne CA, de onderliggende PKI-architectuur moet deze commitment ondersteunen. Wij zorgen hiervoor met FIPS 140-3-compatibele HSM-ondersteuning, gedocumenteerde certificaatbeleidsregels en een implementatie die bestand is tegen kritische analyse.
Voor de voortdurende operationele uitdaging om de TLSA-gegevens op één lijn te houden:
Een van de meest praktische risico's bij een DANE-implementatie is dat een TLSA-record niet meer synchroon loopt wanneer een certificaat wordt vernieuwd. Als het nieuwe certificaat niet overeenkomt met het gepubliceerde TLSA-record, mislukken de verbindingen. CertSecure Manager houdt elk certificaat in uw omgeving bij, markeert certificaten die bijna aan vernieuwing toe zijn en biedt uw team het inzicht dat nodig is om TLSA-records bij te werken voordat een mismatch een storing veroorzaakt. Het maakt niet uit welke CA het certificaat heeft uitgegeven of waar het is geïmplementeerd — alles wordt op één plek weergegeven.
Voor organisaties die DANE gebruiken voor SMTP-beveiliging, waarbij de levering van e-mail tussen servers afhankelijk is van de nauwkeurigheid en actualiteit van TLSA-records, is dit soort proactief certificaatbeheer niet optioneel. Het is de operationele laag die DANE duurzaam maakt in plaats van kwetsbaar.
Conclusie
DANE- en TLSA-records bieden een belangrijke stap voorwaarts in de manier waarop organisaties TLS-certificaatverificatie afhandelen. Door certificaatverwachtingen vast te leggen in DNSSEC-ondertekende DNS-records, krijgt u de mogelijkheid om strikte certificaatpinning af te dwingen zonder volledig afhankelijk te zijn van het wereldwijde CA-systeem. Voor beveiligingsteams die zich altijd ongemakkelijk hebben gevoeld bij het vertrouwen op honderden CA's waarover ze geen controle hebben, is DANE een praktisch en technisch verantwoord alternatief.
Desondanks is DANE op zichzelf geen complete oplossing. Een correcte implementatie vereist een solide DNSSEC-beveiliging, zorgvuldig beheer van records, met name tijdens certificaatvernieuwingen, en inzicht in waar clientondersteuning beschikbaar is en waar niet. Voor organisaties die gevoelige communicatie verwerken, met name e-mail of server-naar-serververkeer, is DANE zeker het overwegen waard als onderdeel van een gelaagde beveiligingsaanpak.
