DANE – Ende der Man-in-the-Middle Attacken bei verschlüsselten Verbindungen?

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.

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.

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:

1. 1. 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.
   2. 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.

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.