We praten over wat DANE-technologie is voor het authenticeren van domeinnamen met behulp van DNS en waarom deze niet veel wordt gebruikt in browsers.
/Unsplash/
Wat is DAN
Certificeringsautoriteiten (CA's) zijn organisaties die cryptografisch certificaat . Ze plaatsten er een elektronische handtekening op, waarmee de authenticiteit ervan werd bevestigd. Soms doen zich echter situaties voor waarin certificaten worden uitgegeven met overtredingen. Vorig jaar startte Google bijvoorbeeld een “detrust-procedure” voor Symantec-certificaten vanwege hun compromittering (we hebben dit verhaal in detail besproken in onze blog - и ).
Om dergelijke situaties te voorkomen, heeft de IETF DANE-technologie (maar wordt niet veel gebruikt in browsers - we zullen later bespreken waarom dit gebeurde).
DANE (DNS-based Authentication of Named Entities) is een set specificaties waarmee u DNSSEC (Name System Security Extensions) kunt gebruiken om de geldigheid van SSL-certificaten te controleren. DNSSEC is een uitbreiding op het Domain Name System dat adresspoofing-aanvallen minimaliseert. Met behulp van deze twee technologieën kan een webmaster of klant contact opnemen met een van de DNS-zone-operators en de geldigheid van het gebruikte certificaat bevestigen.
In wezen fungeert DANE als een zelfondertekend certificaat (de garantie voor de betrouwbaarheid ervan is DNSSEC) en vormt een aanvulling op de functies van een CA.
Hoe werkt dit
De DANE-specificatie wordt beschreven in . Volgens het document is in er is een nieuw type toegevoegd: TLSA. Het bevat informatie over het certificaat dat wordt overgedragen, de grootte en het type gegevens dat wordt overgedragen, evenals de gegevens zelf. De webmaster maakt een digitale vingerafdruk van het certificaat, ondertekent deze met DNSSEC en plaatst deze in de TLSA.
De client maakt verbinding met een site op internet en vergelijkt het certificaat met de “kopie” die is ontvangen van de DNS-operator. Als ze overeenkomen, wordt de bron als vertrouwd beschouwd.
De DANE-wikipagina geeft het volgende voorbeeld van een DNS-verzoek aan example.org op TCP-poort 443:
IN TLSA _443._tcp.example.orgHet antwoord ziet er als volgt uit:
_443._tcp.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... )
DANE heeft verschillende extensies die werken met andere DNS-records dan TLSA. De eerste is het SSHFP DNS-record voor het valideren van sleutels op SSH-verbindingen. Het wordt beschreven in , и . De tweede is de OPENPGPKEY-invoer voor sleuteluitwisseling met behulp van PGP (). Ten slotte is het derde het SMIMEA-record (de standaard is niet geformaliseerd in de RFC, dat is wel zo). ) voor cryptografische sleuteluitwisseling via S/MIME.
Wat is het probleem met DANE?
Half mei vond de DNS-OARC conferentie plaats (dit is een non-profit organisatie die zich bezighoudt met de beveiliging, stabiliteit en ontwikkeling van het domeinnaamsysteem). Experts op een van de panelen dat DANE-technologie in browsers heeft gefaald (althans in de huidige implementatie). Aanwezig op de conferentie Geoff Huston, Leading Research Scientist , een van de vijf regionale internetregistrars, over DANE als een “dode technologie”.
Populaire browsers ondersteunen geen certificaatverificatie met DANE. Op de markt , die de functionaliteit van TLSA-records onthullen, maar ook hun ondersteuning .
Problemen met DANE-distributie in browsers houden verband met de lengte van het DNSSEC-validatieproces. Het systeem wordt gedwongen cryptografische berekeningen uit te voeren om de authenticiteit van het SSL-certificaat te bevestigen en de hele keten van DNS-servers te doorlopen (van de rootzone tot het hostdomein) wanneer het voor het eerst verbinding maakt met een bron.
/Unsplash/
Mozilla probeerde dit nadeel te elimineren met behulp van het mechanisme voor TLS. Het moest het aantal DNS-records verminderen dat de klant tijdens authenticatie moest opzoeken. Er ontstonden echter meningsverschillen binnen de ontwikkelingsgroep die niet konden worden opgelost. Als gevolg hiervan werd het project verlaten, hoewel het in maart 2018 door de IETF werd goedgekeurd.
Een andere reden voor de lage populariteit van DANE is de lage prevalentie van DNSSEC in de wereld. . Deskundigen waren van mening dat dit niet genoeg was om DANE actief te promoten.
Hoogstwaarschijnlijk zal de industrie zich in een andere richting ontwikkelen. In plaats van DNS te gebruiken om SSL/TLS-certificaten te verifiëren, zullen marktspelers in plaats daarvan DNS-over-TLS (DoT) en DNS-over-HTTPS (DoH)-protocollen promoten. Dat laatste noemden we in een van onze op Habré. Ze coderen en verifiëren gebruikersverzoeken aan de DNS-server, waardoor aanvallers geen gegevens kunnen vervalsen. Begin dit jaar was DoT dat al aan Google vanwege zijn openbare DNS. Wat DANE betreft, het valt nog te bezien of de technologie in staat zal zijn “weer in het zadel te komen” en toch wijdverspreid te worden.
Wat we nog meer hebben om verder te lezen:
Bron: www.habr.com