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.

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.

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