Wir sprechen darüber, was die DANE-Technologie für die Authentifizierung von DNS-Domänennamen ist und warum sie in Browsern nicht weit verbreitet ist.
/ Unsplash / Paulius DragunasWas ist DANE?
Zertifizierungsstellen (Certificate Authorities, CAs) sind Organisationen, die kryptografische
SSL-Zertifikate zertifizieren. Sie setzen ihre elektronische Signatur auf sie und bestätigen die Echtheit. Manchmal treten jedoch Situationen auf, in denen Zertifikate mit Verstößen ausgestellt werden. Im vergangenen Jahr hat Google beispielsweise ein Verfahren zur Beendigung des Vertrauens für Symantec-Zertifikate aufgrund ihres Kompromisses eingeleitet (wir haben diese Geschichte in unserem Blog ausführlich behandelt -
ein- oder
zweimal ).
Um solche Situationen zu vermeiden, begann die IETF vor einigen Jahren
mit der Entwicklung der DANE-Technologie (die in Browsern jedoch nicht weit verbreitet war - warum dies passiert, werden wir später besprechen).
DANE (DNS-basierte Authentifizierung benannter Entitäten) ist eine Reihe von Spezifikationen, mit denen Sie DNSSEC (Name System Security Extensions) verwenden können, um die Gültigkeit von SSL-Zertifikaten zu steuern. DNSSEC ist eine Erweiterung für das Domain Name System, die die mit Spoofing verbundenen Angriffe minimiert. Mit diesen beiden Technologien kann der Webmaster oder Client einen der DNS-Zonenbetreiber kontaktieren und die Gültigkeit des verwendeten Zertifikats bestätigen.
Tatsächlich fungiert DANE als selbstsigniertes Zertifikat (DNSSEC ist der Garant für seine Zuverlässigkeit) und ergänzt die Funktionen von CA.
Wie funktioniert es?
Die DANE-Spezifikation ist in
RFC6698 beschrieben . Dem Dokument zufolge wurde den
DNS-Ressourceneinträgen ein neuer Typ hinzugefügt - TLSA. Es enthält Informationen über das übertragene Zertifikat, die Größe und den Typ der übertragenen Daten sowie die Daten selbst. Der Webmaster erstellt einen digitalen Fingerabdruck des Zertifikats, signiert es mit DNSSEC und legt es in TLSA ab.
Der Client stellt eine Verbindung zur Site im Internet her und vergleicht sein Zertifikat mit einer vom DNS-Betreiber erhaltenen „Kopie“. Wenn sie übereinstimmen, gilt die Ressource als vertrauenswürdig.
Die DANE-Wiki-Seite enthält die folgende Beispiel-DNS-Abfrage für den Server example.org über den TCP-Port 443:
IN TLSA _443._tcp.example.org
Die Antwort darauf sieht so aus:
_443._tcp.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020... )
DANE verfügt über mehrere Erweiterungen, die neben TLSA auch mit anderen DNS-Einträgen funktionieren. Der erste ist der SSHFP-DNS-Eintrag zur Schlüsselüberprüfung für SSH-Verbindungen. Es ist in
RFC4255 ,
RFC6594 und
RFC7479 beschrieben . Der zweite ist der Eintrag OPENPGPKEY für den Schlüsselaustausch mit PGP (
RFC7929 ). Der dritte ist der SMIMEA-Datensatz (der Standard wird nicht im RFC erstellt, es gibt
nur seinen Entwurf ) für den Austausch kryptografischer Schlüssel über S / MIME.
Was ist das Problem mit DANE
Mitte Mai fand die DNS-OARC-Konferenz statt (dies ist eine gemeinnützige Organisation, die sich mit Sicherheit, Stabilität und Entwicklung des Domainnamensystems befasst). In einem der Panels kamen die Experten zu dem
Schluss, dass die DANE-Technologie in Browsern fehlgeschlagen ist (zumindest in der aktuellen Implementierung). Bei der Konferenz
sprach Geoff Huston, Senior Fellow bei
APNIC , einem der fünf regionalen Internet-Registrare, von DANE als "toter Technologie".
Beliebte Browser unterstützen die Zertifikatauthentifizierung mit DANE nicht. Es gibt spezielle Plugins auf dem Markt, die die Funktionalität von TLSA-Datensätzen offenbaren, deren Unterstützung jedoch schrittweise eingestellt wird .
Probleme mit der Verbreitung von DANE in Browsern hängen mit der Dauer des DNSSEC-Validierungsprozesses zusammen. Das System ist gezwungen, kryptografische Berechnungen durchzuführen, um die Authentizität des SSL-Zertifikats zu bestätigen und die gesamte Kette von DNS-Servern (von der Stammzone zur Hostdomäne) zu durchlaufen, wenn zum ersten Mal eine Verbindung zur Ressource hergestellt wird.
/ Unsplash / Kaley DykstraDieser Fehler wurde in Mozilla mithilfe der
DNSSEC-Kettenerweiterung für TLS versucht. Es sollte die Anzahl der DNS-Einträge reduzieren, die der Client während der Authentifizierung durchsuchen musste. Innerhalb des Entwicklungsteams kam es jedoch zu Meinungsverschiedenheiten, die nicht gelöst werden konnten. Infolgedessen wurde das Projekt aufgegeben, obwohl es im März 2018 von der IETF genehmigt wurde.
Ein weiterer Grund für die geringe Beliebtheit von DANE ist die geringe Verbreitung von DNSSEC in der Welt -
nur 19% der Ressourcen arbeiten damit . Experten waren der Meinung, dass dies nicht ausreicht, um DANE aktiv zu fördern.
Höchstwahrscheinlich wird sich die Branche in eine andere Richtung entwickeln. Anstatt DNS zur Überprüfung von SSL / TLS-Zertifikaten zu verwenden, fördern Marktteilnehmer im Gegenteil die Protokolle DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH). Wir haben das letzte in einem unserer
vorherigen Materialien über Habré erwähnt. Sie verschlüsseln und überprüfen Benutzeranforderungen an den DNS-Server und verhindern so, dass Angreifer Daten fälschen. Zu Beginn des Jahres wurde DoT bereits bei Google für sein öffentliches DNS
implementiert . Was DANE betrifft, bleibt in Zukunft abzuwarten, ob die Technologie in der Lage sein wird, „zum Sattel zurückzukehren“ und dennoch zur Masse zu werden.
Was haben wir noch für zusätzliche Lektüre:
So automatisieren Sie das IT-Infrastrukturmanagement - diskutieren Sie drei Trends
JMAP - Ein offenes Protokoll ersetzt IMAP beim Austausch von E-Mails
So sparen Sie Geld mit der Anwendungsprogrammierschnittstelle
DevOps in einem Cloud-Dienst am Beispiel von 1cloud.ru
1cloud Cloud Architecture Evolution
Wie funktioniert der technische Support von 1cloud?
Wolkenmythen