Introduktion till DANE och TLSA
Public Key Infrastructure förlitar sig på certifikatutfärdare för att garantera legitimiteten hos ett TLS-certifikat . Problemet är att vilken som helst av de hundratals CA:er som webbläsare litar på kan utfärda ett certifikat för vilken domän som helst, oavsett om domänen har någon relation till den CA:n. Om även en av dessa CA:er komprometteras, är felkonfigurerad eller tvingas, kan en angripare få tag på ett bedrägligt certifikat för din domän som webbläsare kommer att lita på utan att ifrågasätta. Detta är den strukturella svagheten i centrum för CA-förtroendemodellen, och det är inte hypotetiskt. Felaktiga utfärdandeincidenter har inträffat tidigare, och de kommer att hända igen.
DANE, som står för DNS-Based Authentication of Named Entities, är ett säkerhetsprotokoll som hjälper till att åtgärda den svagheten. DANE, som definieras i RFC 6698, låter domänägare publicera sin TLS-certifikatinformation direkt i DNS, skyddad av DNSSEC-signaturer. Enkelt uttryckt, istället för att lita på att någon av hundratals certifikatutfärdare bekräftar att ett certifikat är giltigt, tillåter DANE en domänägare att säga: här är exakt det certifikat eller den nyckel du ska se från min server. Alla andra certifikat ska avvisas.
DANE delar denna information via en TLSA DNS-post. En TLSA-post finns i DNS-zonen för en domän och talar om för anslutande klienter vilket TLS-certifikat eller vilken publik nyckel de ska acceptera. Tillsammans ger DANE och TLSA domänägare mycket starkare kontroll över certifikatvalidering.
Varför traditionell PKI ensam inte räcker
För att förstå varför DANE är viktigt måste man först se var PKI brister. CA-modellen bygger på en enda idé: webbläsare och operativsystem inkluderar en lista över betrodda rot-CA:er, och alla certifikat som signeras av en av dessa CA:er behandlas som giltiga. Det låter bra, tills man inser att det finns fler än 100 betrodda rot-CA:er runt om i världen.
Här är problemet: vilken som helst av dessa CA:er kan utfärda ett certifikat för vilken domän som helst. Om en CA komprometteras eller utsätts för påtryckningar av en myndighet eller en olaglig aktör kan den skapa ett bedrägligt certifikat för din domän. De flesta kunder kommer att lita på den utan att ifrågasätta. Detta är inte bara en teori. År 2011 intrånget inträffade en CA som heter DigiNotar, och falska certifikat utfärdades för stora domäner, inklusive Google. Händelsen gjorde det tydligt hur bräcklig CA-modellen kan vara.
Verktyg som loggar för certifikattransparens (CT) och CAA-poster har gjort saker och ting bättre. Men de ger oftast information efter att ett felaktigt certifikat redan har utfärdats. DANE är annorlunda. Det är en förebyggande åtgärd. Den låser vilka certifikat som är acceptabla på DNS-nivå, innan någon TLS-handskakning kan manipuleras.
Hur DNSSEC möjliggör DANE
DANE fungerar inte på egen hand. Det är helt beroende av DNSSEC, Domain Name System Security Extensions. Utan DNSSEC skulle det inte hjälpa så mycket att lägga in certifikatinformation i DNS, eftersom DNS-poster kan manipuleras ganska lätt.
DNSSEC lägger till kryptografiska signaturer över hela DNS-hierarkin. Varje nivå i DNS-trädet, från rotzonen till toppdomänen (TLD) till din specifika domänzon, signerar posterna under den. När en resolver hämtar en TLSA-post låter DNSSEC den kontrollera att posten är äkta och oförändrad.
Tänk på DNS utan DNSSEC som ett brev utan manipuleringssäker försegling. Alla som hanterar det under processen kan ändra innehållet. DNSSEC lägger till den förseglingen i varje steg. DANE använder sedan den förseglade, betrodda kanalen för att leverera bindande instruktioner om vilka TLS-certifikat som är acceptabla.
För att DANE faktiskt ska skydda dig måste DNSSEC vara fullt driftsatt och validerat från början till slut, från den auktoritativa DNS-zonen hela vägen till den slutgiltiga klienten. DANE byggt på osignerad DNS ger ingen egentlig säkerhet.
Förstå TLSA-poster och deras fält
En TLSA-post publiceras vid ett specifikt DNS-namn som inkluderar tjänstens protokoll, port och domän. Till exempel skulle TLSA-posten för HTTPS på port 443 på example.com visas på:
_443._tcp.example.com. IN TLSA <Usage> <Selector> <MatchingType> <CertificateData>Var och en av de fyra områdena har ett specifikt jobb:
- Certifikatanvändning (0 till 3): Det här fältet anger vad posten fäster. Användning 3, känd som DANE-EE, är det striktaste alternativet. Den fäster direkt till serverns eget certifikat eller nyckel och hoppar helt över traditionell CA-validering.
- Väljare (0 eller 1): Detta talar om för klienten om matchningen ska ske mot hela certifikatet (0) eller bara SubjectPublicKeyInfo, det vill säga den publika nyckeln (1). Att fästa den publika nyckeln är generellt att föredra, eftersom den förblir giltig även när certifikatet förnyas så länge nyckelparet förblir detsamma.
- Matchningstyp (0, 1 eller 2): Detta definierar hur certifikatdata representeras. Värdet 1 betyder SHA-256 och värdet 2 betyder SHA-512. Det rekommenderas starkt att använda en hash för att hålla DNS-poststorlekarna praktiska.
- Certifikatassociationsdata: Detta är det faktiska värdet, antingen en hash eller det råa certifikatet eller den råa nyckeln, som klienten jämför med det certifikat som servern presenterar under TLS-handskakningen.
En server som använder ett CA-signerat certifikat kan använda Användning 1 (DANE-TA) för att fästa till den utfärdande CA:ns publika nyckel. En server som kör ett självsignerat certifikat skulle vanligtvis använda Användning 3 (DANE-EE) för att fästa direkt till sitt eget lövcertifikat.
Hur DANE skyddar mot MITM- och nedgraderingsattacker
DANE är mest användbart när man ser hur det blockerar två av de farligaste attacktyperna inom nätverkssäkerhet: Man-in-the-Middle (MITM) -attacker och TLS-nedgraderingsattacker.
I en MITM-attack positionerar sig en angripare mellan en klient och en server. De avlyssnar anslutningen och presenterar sitt eget certifikat för klienten samtidigt som de skickar trafik vidare till den riktiga servern. Om angriparen lyckas få tag på ett falskt men CA-betrott certifikat för måldomänen, har klienten inget sätt att upptäcka intrånget. DANE täcker detta gap. Även om det falska certifikatet verkar giltigt för webbläsaren, kommer det inte att matcha TLSA-posten i DNS, och en DANE-medveten klient kommer att vägra att slutföra anslutningen.
Nedgraderingsattacker fungerar annorlunda. Angriparen stör TLS-handskakningen för att tvinga båda sidor att använda en äldre, svagare protokollversion eller chiffersvit, en som är lättare att knäcka. Vissa nedgraderingsattacker går längre och rengör krypteringen helt genom SSL-stripping. DANE hjälper till att motverka detta när det kombineras med SMTP-säkerhetsverktyg som STARTTLS. När en e-postserver publicerar en TLSA-post för sin SMTP-port, vet en sändande e-postöverföringsagent (MTA) som validerar posten att TLS krävs och vet vilket certifikat man kan förvänta sig. Alla försök att nedgradera eller rensa TLS blir detekterbara.
Det är värt att vara ärlig om var DANE har begränsningar. Webbläsarstödet är inkonsekvent. De flesta webbläsare validerar inte TLSA-poster för HTTPS direkt, så vardaglig webbsurfning drar inte nytta av DANE utan extra plugins eller anpassade inställningar. DANE fungerar bäst i server-till-server-inställningar, särskilt e-postleverans, och i miljöer där hela teknikstacken är under din kontroll.
Hur krypteringskonsulting kan hjälpa
DANE ger ett betydande lager av kontroll över TLS-certifikatvalidering, men det introducerar också verklig operativ komplexitet. DNSSEC måste vara fullt implementerat och validerat. TLSA-poster måste uppdateras synkroniserat med varje certifikatförnyelse. Och den underliggande PKI-grunden måste vara solid innan något kan fästas till DNS. Detta är inte engångsuppgifter. Det är löpande operativa ansvarsområden som ökar i takt med att din certifikatmiljö växer.
Encryption Consultings PKI-tjänster och CertSecure Manager tar itu med båda sidor av den utmaningen – arkitekturen och den löpande hanteringen.
För organisationer som bygger eller stärker sin PKI-grund:
Våra PKI-tjänster hjälper dig att utforma och implementera en certifikatutfärdarhierarki som är byggd för miljöer som kräver strikt certifikatkontroll. Oavsett om du går mot DANE-EE för att fästa direkt till servercertifikat eller använder DANE-TA för att förankra förtroendet till en intern certifikatutfärdare, måste den underliggande PKI-arkitekturen stödja detta åtagande. Vi säkerställer att det gör det, med FIPS 140-3-kompatibel HSM-stöd, dokumenterade certifikatpolicyer och en implementering som håller måttet under granskning.
För den pågående operativa utmaningen att hålla TLSA-register samordnade:
En av de mest praktiska riskerna med en DANE-distribution är att en TLSA-post blir osynkroniserad när ett certifikat förnyas. Om det nya certifikatet inte matchar den publicerade TLSA-posten misslyckas anslutningarna. CertSecure Manager spårar alla certifikat i din miljö, flaggar certifikat som närmar sig förnyelse och ger ditt team den förhandsinsikt som behövs för att uppdatera TLSA-poster innan en avvikelse orsakar ett avbrott. Det spelar ingen roll vilken certifikatutfärdare som utfärdat certifikatet eller var det distribueras – den visar allt på ett ställe.
För organisationer som kör DANE för SMTP-säkerhet, där e-postleverans mellan servers är beroende av att TLSA-poster är korrekta och aktuella, är den typen av proaktiv certifikathantering inte valfri. Det är det operativa lagret som gör DANE hållbar snarare än ömtålig.
Slutsats
DANE- och TLSA-poster erbjuder ett betydelsefullt steg framåt i hur organisationer hanterar TLS-certifikatautentisering. Genom att förankra certifikatförväntningar i DNSSEC-signerade DNS-poster får ni möjlighet att tillämpa strikt certifikatfästning utan att helt förlita er på det globala CA-systemet. För säkerhetsteam som alltid har känt sig osäkra på att lita på hundratals CA:er som de inte kan kontrollera är DANE ett praktiskt och tekniskt sunt alternativ.
Med det sagt är DANE inte en komplett lösning i sig själv. Att implementera det korrekt innebär att ha en stabil DNSSEC på plats, hantera register noggrant, särskilt vid certifikatförnyelser, och förstå var klientsupport finns och var den inte finns. För organisationer som hanterar känslig kommunikation, särskilt e-post eller server-till-server-trafik, är DANE värt att seriöst överväga som en del av en säkerhetsstrategi på flera skikt.
