DNSSEC
Der Weg von der Internet Adresse zur IP-Adresse des Servers geht über DNS. Wenn es einem Angreifer gelingt, ihre Namensauflösung mit einer anderen IP-Adresse zu beantworten, dann übertragen Sie Daten zu einem "falschen "System. Wenn dieses die Daten dann 1:1 weiter reicht, können Zugangsdaten und Nutzdaten mitgelesen werden.
Ein Schutz dagegen ist der Einsatz von SSL, bei dem der Client ein Zertifikat der Gegenstelle erhält und die Daten nicht nur verschlüsselt, sondern auch den Namen im Zertifikat mit dem gewünschten Zielnamen vergleicht. So fallen solche Man in the Middle-Attacken auf und wenn der Anwender die Zertifikatwarnung nicht "wegklickt", könnte dieser Weg auch sicher sein.
Allerdings hat es sich in der Vergangenheit gezeigt, dass nicht jede auf den Computer als "Trusted" addierte CA auch 100% zuverlässig die Inhaber geprüft hat. Wenn Millionen von Zertifikaten ausgestellt werden, geht das nur automatisch und so kann es schon mal passieren, das eine CA irrtümlich ein Zertifikat auf einen falschen Namen ausstellt. Besonders ärgerlich ist dies, wenn es Google mit Mailservern betrifft und damit Zugangsdaten und Mails von Personen abgehört werden.
Eine Lösung könnte es sein, dass eine Firma in ihrer DNS-Zone zum Host auch den Public Key des verwendeten Zertifikats hinterlegt. Damit wäre sogar die PKI an sich überflüssig. Zudem enthalten auch die DNS-Zonen immer mehr Zusatzinformationen wie SPF, DKIM, etc., so das der Wunsch zu einer Sicherung dieser Daten erforderlich ist. Und genau hier kommt DNSSEC ins Spiel
DNSSEC Funktionsweise
Dabei bedient sich DNSSES durchaus ähnlichen Funktionen wie eine klassische PKI. Grundlage ist wieder einmal die digitale Signatur von Einträgen in der DNS-Zone mit privaten und öffentlichen Schlüsseln. Die folgende Beschreibung ist stark vereinfacht.
- Ich bin Domaininhaber von "msxfaq.de"
- Ich stelle mir einen privaten und öffentlichen Schlüssel aus.
- Einträge in meiner Zone kann ich mit meinem privaten Schlüssel signieren und im DNS mit veröffentlichen
- Meinen öffentlichen Schlüssel hinterlege ich auf der übergeordneten Zone.
Klingt so einfach, d.h. mein Public Key ist in der ".de"-Zone hinterlegt. Die ".de-Zone" wiederum hat ihren Public Key in den "Root-Servers" hinterlegt. Essentiell ist also ein sicheres Verfahren, wie der Zoneninhaber seinen Public-Key in die übergeordnete Zone ablegen kann.
DNS sicher abfragen
Das allein reicht aber noch nicht, denn damit diese Daten auch "zuverlässig", d.h. Unverändert gelesen werden können, muss auch die DNS-Anfrage selbst zumindest signiert erfolgen. Ein Client, der die Gültigkeit eines per TLS erhaltenen Zertifikats über DNSSEC prüfen möchte, muss also nicht nur eine DNS-Anfrage nach den entsprechenden Records absetzen, sondern auch sicherstellen, dass diese Antwort nicht verändert wurde. Damit kommt auch die Signatur der Antworten ins Spiel.
Leider können die wenigsten Clients schon DNSSEC selbst auflösen. In der Regel wird also die Verbindung von DNS-Client zum ersten DNS-Server ungesichert sein. Es handelt sich dabei aber meist um eine interne Verbindung von einem Client zum DNS-Server des unternehmens oder des Providers. Die DNS-Server selbst können dann aber DNSSEC nutzen und damit auf dieser Ebene eine Sicherung gewährleisten.
Dass die letzte Meile quasi nicht "gesichert" ist, wird man oft verschmerzen können, denn viele DNS-Clients (z.B. Smartphones) werden nicht den Aufwand für DNSSEC machen und ihrem vom Netzwerk Administrator bereitgestellten DNS-Server blind vertrauen.
DNSSEC für eigene Zone einrichten
Auch wenn heute leider immer noch zu wenige Dienste wirklich DNSSEC nutzen, so wollte ich doch einmal schauen, wie man DNSSEC im Internet aufsetzt.
Ich habe in dem Zuge natürlich auch nach Firmen gesucht, die DNSSEC unterstützen. Da reduziert sich das Angebot dann schon merklich, da die meisten Anbieter noch kein DNSSEC unterstützen. Einige Angebote wie z.B. von InterNetX (http://www.internetx.com/domains/) unterstützen DNSSEC in der Verwaltungssoftware (AutoDNS), aber erfordert eigene DNSSEC-taugliche DNS-Server.
- DNSSEC Dienst Schützen Sie
Ihre Domain vor Cache Poisoning
http://www.ovh.de/domains/dnssec_dienst.xml - DNSSEC - Sicherung für das
DNS
http://www.ovh.de/domains/a625.eine_sicherung_fuer_das_dns?id=625 - Registrars that support end User DNSSEC management,
including entry of DS records
https://www.icann.org/resources/pages/deployment-2012-02-25-en - DNSSEC Lab Debugger
http://dnssec-debugger.verisignlabs.com/ - DNS Wizard - Diagnose von
DNS Zonen
http://dnsviz.net/ - s.huque's blog :DNSSEC and
Certificates
http://blog.huque.com/2012/10/dnssec-and-certificates.html
DANE und TLSA
TLSA ist ein besonderer DNS-Eintrag, über den zu einem Host ein PublicKey eines Zertifikats hinterlegt wird. Ein entsprechender Client kann dann beim Aufbau einer TLS-Verbindung per DNS prüfen, ob das erhaltene Zertifikat mit dem im DNS hinterlegten Wert übereinstimmt. So kann z.B. verhindert werden, dass jemand in der Mitte sich ein Zertifikat für den Namen besorgt hat. Es ist in der Vergangenheit durchaus passiert, dass Zertifizierungsstellen oder auch stattliche Organisationen solche falschen Zertifikate ausgestellt haben um die Daten zu entschlüsseln. Auch in Firmen kommen gerne mal Proxy-Server zum Einsatz, die denn SSL-Verkehr aufbrechen, indem Sie on the Fly ein Zertifikat von einer CA ausstellen, der ihr "FirmenComputer" vertraut.
Siehe dazu auch die eigene Seite DANE/TLSA
Damit das aber sicher funktioniert muss die DNS-Anfrage auch kryptografisch gesichert sein. Ansonsten kann der Angreifer in der Mitte auch die DNS-Abfrage verändern. Die DNS Abfrage selbst muss auch verschlüsselt sein, sonst könnte ein Angreifer auch hier die Anfrage mit einem "nicht vorhanden" abwürgen.
Weitere Links
- DANE/TLSA
-
Free SMIME Zertifikat
Warum kostenfreie SMIME-Zertifikate nur vergiftete Angebote sind - Finger weg - DNSSEC – erhöhte Sicherheit
im Netz
http://www.denic.de/domains/dnssec.html - Nameserver Predelegation
Check Webinterface
http://www.denic.de/hintergrund/nast.html
http://nast.denic.de/ - List of DNS record types
http://en.wikipedia.org/wiki/List_of_DNS_record_types - DNSSEC Resolver Test
https://wander.science/projects/dns/dnssec-resolver-test/
Vormals https://dnssec.vs.uni-due.de/ (offline)
JavaScript um zu prüfen, ob der eigene DNS-Server "DNSSEC"-Einträge auflösen kann. - DNS Debugger
https://dnssec-debugger.verisignlabs.com - DNSSEC-Day
http://www.heise.de/newsticker/meldung/Am-30-Juni-ist-DNSSEC-Day-2723932.html - DNSSEC Deployment Report
http://dnssec-deployment.icann.org/dctld/ - DNSSEC Validation Rate by
country (%)
https://stats.labs.apnic.net/dnssec - Modern DNS Hosting for Everyone
https://desec.io/
deSEC is a free DNS hosting service, designed with security in mind. - DNSSEC-Day: Kleine Nachlese
http://www.heise.de/newsticker/meldung/DNSSEC-Day-Kleine-Nachlese-2733115.html - DNSSEC ist gescheitert
http://www.golem.de/news/imho-dnssec-ist-gescheitert-1506-114940.html
Ob es stimmt wird letztlich die Zukunft entscheiden - Changing the Keys to the
Domain Name System (DNS) Root
Zone
https://www.icann.org/news/blog/changing-the-keys-to-the-domain-name-system-dns-root-zone - Neuer Masterschlüssel für
das Herz des Netzes
http://www.heise.de/newsticker/meldung/Neuer-Masterschluessel-fuer-das-Herz-des-Netzes-2724261.html - DNSSEC: Verfahren für
Schlüsseltausch in der Rootzone
festgelegt
http://www.heise.de/newsticker/meldung/DNSSEC-Verfahren-fuer-Schluesseltausch-in-der-Rootzone-festgelegt-3208629.html - l+f: Wo ist der ver@!%&
Schlüssel?
https://www.heise.de/security/meldung/l-f-Wo-ist-der-ver-Schluessel-4659832.html - The DNSSEC Root Signing
Ceremony
https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/