DNS-based Authentication of Named Entities – oder kurz DANE – ist ein Netzwerkprotokoll, welches 2011 im RFC6394 definiert wurde. DANE wurde entwickelt, um jeglichen zertifikatbasierten Datenverkehr (SSL/TLS) besser abzusichern und soll so sicherstellen, dass das vorgesehene Zertifikat nicht unerlaubt ausgetauscht wird, wie es zum Beispiel bei einer «Man-in-the-Middle Attack» vorkommt. Richtig eingesetzt kann DANE so die Sicherheit massiv erhöhen, doch birgt es einige neue Herausforderungen.
DANE – nicht nur für Mail-Kommunikation
DANE ist vielen ein Begriff, speziell aus der Mail-Kommunikation. Prinzipiell können wir aber jegliche per SSL/TLS verschlüsselte Datenverbindung damit absichern. So gibt es zum Beispiel von der tschechischen DNSSec/TLSA Initiative ein Plug-In für Browser (z.B. für Chrome, Firefox), welches man installieren kann, um seinen Surf-Traffic besser abzusichern.
Man-in-the-Middle Attack – der böse Vermittler in den Datenverbindungen
Bei einer Man-in-the-Middle Attack steht zwischen dem Sender (z.B. einem Server) und dem Empfänger (z.B. einem Client) physisch oder logisch der Angreifer im Kommunikationspfad. So lange die Verbindung zwischen Sender und Empfänger verschlüsselt ist, kann der Angreifer mit den Daten, die so übermittelt werden, nichts anfangen. Bei einer Man-in-the-Middle Attack bricht der Angreifer jedoch die Kommunikation auf, kann den Datenverkehr abhören, manipulieren oder gar Schadcode einschleusen, verschlüsselt den Datenverkehr erneut und liefert ihn an den Empfänger aus.
Damit der Empfänger dieser Datenverbindung vertraut, muss das Zertifikat, welches vom Angreifer zur erneuten Verschlüsselung verwendet wird, dem Client als vertrauenswürdig hinterlegt sein. In den meisten Fällen kommt hierzu ein «Certificate Store» zum Einsatz, bei dem die Root-Zertifikate als vertrauenswürdig hinterlegt sind, anhand deren das Vertrauen des Zertifikats überprüft wird. Sollte das erhaltene Zertifikat nicht vertrauenswürdig sein, kommt es zu einer Zertifikatswarnung oder allenfalls bricht die Kommunikation im besten Falle sofort ab.
Entsprechend hat der Angreifer folgende Möglichkeiten:
- Der Empfänger überprüft nicht die Vertraulichkeit der Verbindung – was heute zunehmend weniger der Fall ist. Es gibt aber sicher viele Systeme, bei denen dies immer noch nicht der Fall ist – speziell sind dies sehr oft MTAs, welche so konfiguriert sind.
- Bei einer Zertifikatswarnung kann der User oft selbst entscheiden, ob er das Risiko eingeht und fortfahren will – der Angreifer vertraut also auf die Naivität oder die Unbeholfenheit des Users. Das Risiko wird heutzutage durch viele andere technische Verfahren (z.B. HSTS) zunehmend minimiert.
- Der Angreifer erlangt Zugriff auf den «Certificate Store» und hinterlegt sein eigenes Root-Zertifikat. Dies ist jedoch ein sehr aufwändiger und anspruchsvoller Angriffsvektor und bedarf auch Zugriff auf den Client selbst – und wenn das der Fall wäre, dann hätten wir wohl anderweitig ein Problem und müssten uns nicht über DANE unterhalten.
- Der Angreifer hat die Möglichkeit, ein valides Zertifikat auszustellen, das als vertrauenswürdig gilt. Dieser Angriffsvektor bietet gar das grösste Gefahrenpotenzial. Der Angreifer muss im simpelsten Falle bei diesem Angriffsvektor nur über eines die Hoheit erlangen – Ihren DNS. So kann er gleich zwei Fliegen mit einer Klappe schlagen, indem er a.) einerseits den Traffic logisch über sich routen kann und b.) andererseits das valide Zertifikat z.B. via Let’s Encrypt ausstellen kann.
Wohlgemerkt bei Option vier, bringt uns DANE leider auch nichts. Daher ist die Absicherung des (externen) Domain Name Servers immer sicherzustellen!
DANE – bei Datenverbindungen die Sicherheit erhöhen
Eine Grundvoraussetzung für DANE ist zum einen, dass wir einen sicheren DNS Server für unseren Server haben. Im DNS wird in einem TLSA Record der Hashwert des für die Verschlüsselte-Kommunikation verwendeten Zertifikats hinterlegt. Damit diese im DNS hinterlegte Information nicht manipuliert werden kann, muss sie per DNS Security Extensions (DNSSec) abgesichert sein.
Wenn wir diese Anforderung erfüllen, können wir DANE einsetzten und den Datenaustausch auf dem Kommunikationsweg besser absichern: Wie bisher übermittelt der Server – wie zum Beispiel der sendende MTA oder ein Webserver – dem Client sein Zertifikat. Dieser prüft es wie bisher auf Validität (stimmt der Name, ist der FQDN eingetragen, ist es zurzeit gültig, zweckmässiger Einsatz, nicht revoziert etc.). Zudem fragt der Empfänger bei DANE den DNS Server an, ob ein TLSA Record für die entsprechende Verbindung hinterlegt ist.
Ist dies der Fall, erhält er als Antwort den Hashwert des Zertifikates und kann anhand dessen prüfen, ob das empfangene Zertifikat entsprechend korrekt ist oder manipuliert bzw. ausgetauscht wurde.
Sollte also eine Man-in-the-Middle Attack stattgefunden haben, wird der Hashwert des Zertifikates unmöglich mit dem im Hashwert aus dem TLSA Record übereinstimmen, womit wir im besten Falle dann die Kommunikation abbrechen.
Besonderheit SMTP – alles über einen Port
Wenn wir uns mit DANE beschäftigen, gibt es noch eine Besonderheit beim Mail-Austausch zu beachten. In der Regel findet Mail-Austausch immer über den SMTP Port 25/tcp statt. Dabei wird der Port für verschlüsselten und unverschlüsselten Datenverkehr verwendet. Das führt dazu, dass in der Regel der MTA so konfiguriert ist, dass er im Optimalfall eine verschlüsselte Verbindung mit dem sendenden MTA aufbaut, aber als Fallback (sollte der Sender keine Verschlüsslung offerieren oder kann keine passende Verschlüsselungsmethode ausgehandelt werden) nimmt der MTA auch unverschlüsselten Datenverkehr an.
Wir können den MTA natürlich auch manuell konfigurieren, dass er nur verschlüsselte Verbindungen akzeptiert – mit dem Risiko, dass gewisse sendenden MTAs uns keine Mails schicken können. Ferner können wir manuell auch definieren, welche MTAs zwingend mit unseren MTA verschlüsselt kommunizieren müssen und können dort gar das Zertifikat hinterlegen – dies bedarf aber mitunter eines höheren administrativen Aufwands.
DANE bietet uns hier einen Vorteil: Da unser MTA prüft, ob der TLSA Record gesetzt ist, weiss er, dass der sendende Server eine verschlüsselte Verbindung offeriert. Nun können wir unseren MTA so konfigurieren, dass er immer nur verschlüsselte SMTP Verbindungen annimmt, sollte dieser Record gesetzt sein.
Herausforderung: Zertifikate erneuern und TLSA update – Let’s Encrypt
Let’s Encrypt ist heute wohl ein Standard, welcher mehr und mehr auf Beliebtheit stösst – denn teure Zertifikate sind damit zunehmend überflüssig. Jedoch muss berücksichtigt werden, dass bei Let’s Encrypt die Zertifikate alle drei Monate erneuert werden müssen – entsprechend wird sich der Hashwert auch ändern. Let’s Encrypt nutzt für diesen Renewal-Prozess einen Service (genannt Certbot), welcher auf dem Server läuft und das Zertifikat automatisch erneuert.
Damit DANE weiterhin funktioniert und wir nicht händisch alle drei Monate den TLSA Record im DNS erneuern müssen, haben wir zwei Möglichkeiten:
- Der Certbot Prozess bietet mittels API an, den TLSA Record zu setzten, sofern der jeweilige DNS-Provider diese API unterstützt – was leider bisher nur selten der Fall ist.
- Wir hinterlegen nicht den Hashwert des Zertifikates selbst, sondern den des Root- bzw. des Intermediate-Zertifikates. Da dieses eine längere Laufzeit hat, können wir so das händische Aktualisieren des TLSA Record sparen – unter der Berücksichtigung, dass so die Sicherheit bei DANE ein wenig herabgestuft wird, sollte ein Angreifer bei derselben Zertifizierungsinstanz ein valides Zertifikat ausstellen können.
Fazit
DANE bringt aus meiner Sicht einen immensen Gewinn an Security. Leider hat sich in den letzten Jahren nur nicht jeder Hersteller von Security-Lösungen tief damit auseinandergesetzt. Speziell bei der Mail-Kommunikation versucht man vieles auf SPF und DKIM zu schieben, was aber nicht sicherstellt, dass die Mail-Kommunikation abgehört werden kann. Bekannte Hersteller wie Cisco mit ihrer E-Mail Security Appliance (IronPort) unterstützen dieses Feature seit einiger Zeit, neue Lösungen wie xorlabs ActiveGuard sind dran, dies umzusetzen. OpenSource Lösungen, wie Postfix unterstützen dieses Feature bereits seit Jahren erfolgreich und der Aufwand dieses einzurichten und zu aktivieren ist minimal.
Auf Applikationsebene wie bei Web-Browsern ist dies leider noch nicht etabliert – was mit der Thematik der TLS-Interception bei Proxies eine andere Herausforderung darstellt. Bereits vor einiger Zeit hatte ich auch beim Nextcloud-Projekt einen Feature Request gestellt, da es ja ein idealer Ansatz wäre, seinen eigenen Cloud-Sync abzusichern. Wir sehen, die Anwendungszwecke können hier sehr vielfältig sein.
Sicherlich bringt DANE ein paar Herausforderungen mit sich, kann aber richtig eingesetzt einen massiven Gewinn an Security erzielen. Ich hoffe, dass sich diese Technologie mehr und mehr etablieren und durchsetzen wird und vielleicht habe ich Ihnen mit diesem kurzen Abriss ebenfalls das Interesse an dieser Thematik schmackhaft machen können.