Ein Plus an Sicherheit bieten DNSSEC und TLSA die sich leider nur schwer durchsetzen.

Dabei ist die Technik verschiedene Serverdienste zusätzlich abzusichern eine interessante Lösungsmöglichkeit.

Bei der Suche nach TLSA und DNSSEC findet man häufig zwei Kernaussagen:

1. Einsatz mit SMTP Diensten

2. mangelnde Unterstützung

Um so mehr ein Grund den Nutzen dieser Protokolle bzw. den Nutzen des DANE Protokolls einmal genauer zu beschreiben und auch die damit verbundenen Probleme zu beleuchten.

1. DNSSEC (Domain Name System Security Extension)

DNSSEC ist eine Erweiterung zum DNS Protokoll mit dem Ziel die Umleitung und Manipulation von DNS Informationen zu erschweren. Es hat nichts mit Verschlüsselung zu tun sondern ausschließlich mit der Signatur.

Es soll hier nur gewährleistet werden, dass der übermittelte DNS Eintrag auch tatsächllich den echten Einträgen entspricht und nicht auf dem Weg manipuliert und verändert wurde.

Auch das andere Protokolle wie IP bereits angegriffen wurden, wird dadurch nicht ausgeschlossen. Denn die Daten werden unverschlüsselt von DNS zu Resolver oder Client übertragen.

Probleme:

a) Obwohl das Protokoll aus den 90er Jahren stammt, wird es bisher kaum unterstützt und genutzt.

b) Um das Protokoll zu nutzen müssen viele Stellen mitspielen. Dazu gehört als Erstes der Top-Level wie ".de" und viele weitere. Zahlreiche Top-Level Domains unterstützen DNSSEC aber längst nicht alle.

c) Der Top-Level-Domain Verwalter muss DNSSEc ebenso unterstützen, wie der Domain-Handler und Provider selber, was insbesondere in Deutschland ein Problem ist.

d) Nameserver müssen das Protokoll ebenfalls unterstützen.

Warum so komplex?

Von SSL-Zertifikaten kennt nahezu jeder das System. Es gibt eine Zertifizierungsstelle, der das CSR (Certificate Request) eingereicht und an dessen Ende das Zertifikat ausgestellt wird. Es gibt hier also eine Hirarchie.

Im Fall von DNSSEC ist es ganz ähnlich. Die eigene Domain wird auf den Nameservern signiert. Die oberste "Ebene" des DNS-Baums wird ebenfalls signiert. Die jeweiligen öffentlichen Schlüssel werden im DNS veröffentlicht. Anschließend wird der eigene, oberste Schlüssel in der Zone eingetragen und von dort signiert.

Es entsteht dadurch ein sogenannter "Chain of Trust" bei dem im Idealfall von oben (z.B. .de) bis zu letzten Subdomain jede Signatur durch die nächste bestätigt wird.

So muss die auswertende Anwendung nur der "obersten Zone" vertrauen und dessen öffentlicher Schlüssel bekannt sein.

Ein Resolver ist dabei für die Auswertung der Informationen zuständig und verweigert die Verbindung, wenn der "Chain of Trust" zum Beispiel durch einen Angriff unterbrochen wurde.

Das bedeutet, dass bei Attacken wie DNS-Spoofing die Verbindung verweigert werden würde, weil die Signatur ganz fehlt oder falsch ist.

Wer kann Resolver sein?

Der Resolver könnte beim Provider stehen, was allerdings nicht unbedingt sehr sinnvoll ist. Bei einem Angriff über Ihr WLAN Netz ist der Resolver beim Provider nutzlos. Doch kann ein Resolver durchaus auch auf dem Client (z.B. Webbrowser) sein.

2. TLSA

Durch die Verwendung von TLSA soll die Veränderung und die Manipulation von SSL/TLS Zertifikaten erschwert werden. Man in the Middle Attacken können dadurch maßgeblich erschwert werden.

Möglich wird dies dadurch, dass ein BASE64 encode des öffentlichen Schlüssels des Zertifikats in DNS Einträgen hinterlegt wird. Für jeden Port und damit jeden Dienst kann ein eigener Eintrag in der Domain vorgenommen werden. Das Zertifikat wird damit durch einen entsprechenden DNS Eintrag bestätigt.

Will ein Angreifer nun die verschlüsselte Kommunikation mitlesen müsste er also ein Zertifikat erzeugen, dessen öffentlicher Schlüssel zum DNS-Eintrag passt.

Probleme:

a) Dies System kann nur funktionieren, wenn die DNS Antworten gegen Manipulation gesichert sind.

b) DNS-Einträge bei den Providern oder deren Oberflächen müssen den TLSA Record als DNS-Eintrag unterstützen.

3. DANE (DNS-based Authentification of Name Entries)

DANE ist nun die Verbindung beider Technologien. Der Dienst, z.B. Website oder SMTP Server, wird über TLSA zusätzlich gesichert. Damit diese Informationen nicht durch Angreifer verfälscht werden können, werden die TLSA-Einträge zusätzlich mit DNSSEC gesichert.

Kann es bei der mangelnden Verbreitung trotzdem nützlich sein?

Ja, denn DANE ist weltweit, wenn auch nicht überall, im Einsatz. Insbesondere bei Mailservern ist damit zumindest ein Vorteil gegenüber Diensten wie "E-Mail Made in Germany" gegeben.

Selbst in den Mailprotokollen werden Vertrauensverbindungen sichtbar die durch DANE bestätigt wurden. Es ist auch möglich Verbindungen ohne DANE zu verbieten. So kann eine Sicherheitsstruktur zumindest teilweise erzwungen werden.

Der vermehrte Einsatz und auch Hinweise an die Benutzer von Websiten kann hier durchaus zur Verbreitung beitragen. Add-Ons sind für verschiedene Webbrowser inzwischen auch erhältlich. Diese zeigen den Benutzern schnell und bequem an ob die Seite DANE unterstützt und bestätigt werden konnte.

Ob und wann Anwendungen wie Webbrowser "serienmäßig" DANE und DNSSEC unterstützen kann ich nicht sagen.

Wie können Sie DANE als Anwender nutzen?

Wollen Sie DANE als privater Anwender im Webbrowser nutzen können Sie das Add-On DNSSEC-Validator für Webbrowser für Ihren Webbrowser installieren. Sie werden dann direkt in der Adressleiste des Webbrowsers darauf hingewiesen ob die aufgerufene Website DANE unterstützt oder gar unregelmäßigkeiten aufweist.

Das Tool kann zudem so konfiguriert werden, dass Websites mit ungültigen DANE Prüfungen nicht aufgerufen werden können. So haben Sie Ihren eigenen Resolver direkt auf Ihren Geräten.

Wie können Sie als Websitenbetreiber/Webmaster usw. DANE nutzen?

Als Provider kann ich Ihnen die Wege ebnen.

Für viele Top-Level-Domains wie .eu, .bayern, .dental, .cool, .energy, .nrw usw. kann ich bereits heute DNSSEC ohne Zusatzkosten bereitstellen. Wollen Sie für eine Domain DNSSEC Unterstützung, fragen Sie am besten direkt unter Angabe des betroffenen Top-Level an.

Die von mir betriebenen Nameserver unterstützen ebenfalls DNSSEC.

Für die Verwaltungsoberfläche ODIN-PLESK habe ich eine eigene Lösung um die erforderlichen TLSA Records setzen zu können.

Setzen Sie bereits selber ODIN-Plesk ein, können Sie zur Signatur Ihrer Zone auf Admin-Ahead zurückgreifen.