Absenderreputation und E-Mail-Sicherheit – Teil 5: DNS-based Authentication of Named Entities (DANE)
Die Absicherung des Internets im Allgemeinen und elektronischer Kommunikation im Speziellen basiert immer noch zu einem großen Teil auf der Verwendung sogenannter Zertifikate. Ein Beispiel dafür ist die Transportverschlüsselung durch Transport Layer Security (TLS): Mit Hilfe entsprechender TLS-Zertifikate können Web- oder E-Mail-Server authentisiert sowie der Datenaustausch zwischen diesen verschlüsselt werden. Diese Verschlüsselung sorgt dafür, dass Daten abhörsicher übertragen werden – wenn die genutzten Zertifikate zweifelsfrei authentisiert werden.
Im fünften Teil unserer Serie zur Absenderreputation erläutern wir, wie Sie mit DNS-based Authentication of Named Entities (DANE) die Authentizität von Zertifikaten sicherstellen und Ihren E-Mail-Verkehr vor dem Zugriff Krimineller schützen können.
Artikelserie: Absenderreputation und E-Mail-Sicherheit
Teil 1: Authenticated Received Chain (ARC)
Teil 2: Sender Policy Framework (SPF)
Teil 3: DomainKeys Identified Mail (DKIM)
Teil 4: Domain-based Message Authentication, Reporting and Conformance (DMARC)
Teil 5: DNS-based Authentication of Named Entities (DANE)
Missbrauchspotenzial trotz TLS-Verschlüsselung
Greifen Sie beispielsweise auf den Server www.nospamproxy.de zu, muss dieser Name auch im TLS-Zertifikat auftauchen. Wenn das Zertifikat darüber hinaus von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, können Sie sicher sein, dass Sie mit dem richtigen Server “verbunden” sind. Leider besteht genau an dieser Stelle ein gewisses Missbrauchspotenzial.
Konkret könnte ein Angreifer den Web- oder E-Mail-Verkehr auf ein von ihm kontrolliertes System umleiten und ebenfalls ein Zertifikat mit dem entsprechenden Namen verwenden. Für Webserver ist diese Gefahr nicht mehr sehr groß, da zum einen die Browser einen guten Schutz gegen nicht vertrauenswürdige oder gar falsche Zertifikate bieten und zum anderen die vertrauenswürdigen Zertifizierungsstellen gute Arbeit leisten.
Für die Server-zu-Server-Kommunikation im E-Mail-Bereich gilt dies jedoch nicht. Zertifikate werden so gut wie nie geprüft. Nicht selten sieht man sogar seit Jahren abgelaufene Zertifikate im produktiven Einsatz. So könnten E-Mails über einen verschlüsselten Kanal auf ein kompromittiertes System umgeleitet werden.
Was ist DNS-based Authentication of Named Entities (DANE)?
DANE ist ein DNS-basiertes Netzwerkprotokoll, das die kryptografische Verknüpfung von Zertifikaten mit DNS-Namen bei der Nutzung von TLS ermöglicht. Beim Einsatz von TLS werden Verbindungen zu einem Server zwar mit Hilfe von TLS-Zertifikaten verschlüsselt, die Zertifikate selbst werden allerdings nicht (sicher) verifiziert.
Ein Browser oder E-Mail-Programm kann nämlich nicht erkennen, ob
- das abgerufene Zertifikat für die Domain tatsächlich für den Domaininhaber erstellt wurde oder
- sich ein Krimineller per DNS Spoofing als der Empfänger ausgegeben hat und die E-Mail umgeleitet wird.
Warum TLS ohne DANE nicht sicher ist
Wenn Sie mit Ihrem E-Mail-Programm eine E-Mail versenden, wird diese beim sendenden E-Mail-Server eingeliefert und an den empfangenden Server gesendet. Damit die Kommunikation zwischen diesen beiden Servern geschützt ist, nutzen Sie TLS – also eine Transportverschlüsselung.
Um herauszufinden, ob der empfangende Server die Verschlüsselung mittels TLS unterstützt und somit Verschlüsselung anbietet, sendet der sendende Server als Klartext den STARTTLS-Befehl. Dieser leitet die Verschlüsselung ein. An dieser Stelle bieten sich Kriminellen verschiedene Möglichkeiten, an die in der E-Mail enthaltenen Daten zu kommen:
DNS Spoofing
Beim sogenannten DNS Spoofing erzeugen die Angreifer eine falsche IP-Adresse, an die die E-Mail gesendet wird. Genauer gesagt werden gefälschte DNS-Einträge im Zwischenspeicher des DNS-Resolvers abgelegt, so dass der Nameserver eine falsche IP-Adresse zurückgibt. Als Ergebnis wird der Datenverkehr auf den Computer der Angreifer umgeleitet und nach dem Auslesen der Daten an den eigentlichen Empfänger weitergeleitet, damit der Angriff unentdeckt bleibt.
Mit Hilfe von gefälschten TLS-Zertifikaten wird diese Verbindung verschlüsselt – was in diesem Fall allerdings keinen Unterschied macht. Die E-Mail landet in den Händen der Angreifer und kann von diesen entschlüsselt werden.
Man-in-the-Middle-Angriff
Bei einem solchen Angriff werden alle Verbindungen von einem bestimmten E-Mail-Server abgefangen, indem beispielweise ein Internetknotenpunkt angezapft wird. Auch hier wird die Verbindung mit Hilfe eines gefälschten Zertifikats verschlüsselt und die jeweilige E-Mail im Anschluss an den eigentlichen Empfänger weitergeleitet.
Downgrade Attack
Diese Form des Angriffs funktioniert ähnlich wie ein Man-in-the-Middle-Angriff, allerdings gibt der Angreifer an, keine Verschlüsselung zu unterstützen. Da die allermeisten E-Mail-Server die E-Mail trotzdem senden, ist hier nicht einmal ein Zertifikat erforderlich. Die E-Mail wird unverschlüsselt übertragen und später vom Kriminellen an den eigentlichen Empfänger weitergeleitet.
E-Mails werden bei fehlender TLS-Unterstützung auf Seiten des Empfängers trotzdem versendet, weil man sich für SMTP sozusagen auf den kleinsten gemeinsamen Nenner geeinigt hat und nach der Devise “Hauptsache irgendwie verschlüsselt” handelt. Bei STARTTLS ist es sogar noch kritischer, da es auch die Option “gar nicht verschlüsseln” zulässt.
Dies ist bei der TLS-basierten Verschlüsselung von Webseiten (HTTPS) anders; im Zweifelsfall öffnet sich dann ein Fenster, das der Anwender wegklicken muss. E-Mail-Administratoren haben allerdings kaum Kapazitäten, diese Entscheidung für hunderte oder tausende von E-Mails täglich zu treffen.
Probleme bei der Nutzung von TLS-Zertifikaten
Wie kann es sein, dass Kriminelle an gefälschte Zertifikate gelangen und diese nutzen können? Die Antwort auf diese Frage liegt in der Art und Weise begründet, wie TLS-Zertifikate erstellt und authentisiert werden:
Es wird deutlich, dass die Bewertung der Validität von TLS-Zertifikaten von der Vertrauenswürdigkeit der ausstellenden Stelle abhängt. Hier kommt DANE ins Spiel, das eine einfache und sichere Möglichkeit zur Validierung der Zertifikate und somit der Authentisierung von Kommunikationspartnern bietet.
Mit DANE TLS-Zertifikate authentisieren
Mit DANE lassen sich nun Zertifikate mit Einträgen im Domain Name System (DNS) des Domaininhabers verknüpfen. Die jeweilige DNS-Kommunikation wird dann per DNSSEC gesichert, so dass sichergestellt ist, dass die übermittelten DNS-Antworten verifizierbar sind. Ohne eine solche Absicherung könnten Kriminelle auch diese Antworten fälschen.
Für die Nutzung von DANE wird ein TLSA-Eintrag (TLSA Record) in der DNS-Zone der jeweiligen Domain abgelegt. Dieser Eintrag enthält einen Hash-Wert, der aus dem genutzten Zertifikat gebildet wurde, sowie weitere Informationen zur Interpretation des TLSA-Eintrags:
| Nummer | Wert | Bedeutung |
|---|---|---|
| 1: Zertfikatsverwendung | 0 | PKIX-TA: Certificate Authority Constraint – Validierung des Zertifikats durch einen definierten Trust Anchor (vertrauenswürdige PKIX-Zertifizierungsstelle). Die Vertrauenskette des Server-Zertifikats muss bis zu diesem Trust Anchor zurückgeführt werden und die Zertifikatsprüfung bestehen. |
| 1 | PKIX-EE: Service Certificate Constraint – Akzeptieren (vertrauen) des im TLSA-Record referenzierten Server-Zertifikats, wenn es von einer vertrauenswürdigen PKIX-Zertifizierungsstelle ausgestellt wurde. Das Zertifikat und die Vertrauenskette müssen die Prüfung auf Vertrauenswürdigkeit bestehen. | |
| 2 | DANE-TA: Trust Anchor Assertion – Nutzen eines definierten Trust Anchors für die Validierung des Zertifikats. Es muss sich nicht um eine für den Client vertrauenswürdige PKIX-Zertifizierungsstelle handeln. Zurückführen der Vertrauenskette des Server-Zertifikats bis zu diesem Trust Anchor. | |
| 3 | DANE-EE: Domain Issued Certificate – Akzeptieren (vertrauen) des im TLSA-Record referenzierten Zertifikats; keine Prüfung der Vertrauenshierarchie. | |
| 2: Selektor | 0 | Das vollständige Zertifikat wird genutzt. |
| 1 | Nur der öffentliche Schlüssel wird genutzt. | |
| 3: Zertfikatszuordnung | 0 | Vollständiges Zertifikat, kein Hash; erzeugt sehr lange DNS-Antworten. |
| 1 | SHA-256 Hash-Wert | |
| 2 | SHA-512 Hash-Wert | |
| 4: Zertifikatsdaten | – | Der Hash-Wert des Zertifikats. |
Warum DANE die TLS-Verschlüsselung besser macht
Allein die Tatsache, dass ein TLSA-Eintrag im DNS des Empfängers vorhanden ist, hat hohen Informationswert: Es zeigt, dass der empfangende Server verschlüsseln kann und will. Angriffe wie die oben erwähnte Downgrade Attack sind so ausgeschlossen, denn der sendende Server greift vor dem Versenden der E-Mail auf das DNS zu und liest den TLSA-Eintrag aus.
Noch entscheidender ist, dass der im DNS publizierte Hash-Wert das jeweilige Zertifikat authentisiert. Versucht ein Angreifer, die E-Mail mit Hilfe eines gefälschten Zertifikats umzuleiten, so kann dies nicht gelingen: Der sendende Server erkennt, dass der Hash-Wert nicht zum Zertifikat passt und verweigert die Auslieferung der E-Mail.
Da die Authentisierung der Zertifikate vollständig über den TLSA-Eintrag realisiert wird, können für eine sichere TLS-basierte Verschlüsselung auch selbstsignierte Zertifikate eingesetzt werden – signierte Zertifikate von offiziellen Zertifizierungsstellen sind nicht zwingend erforderlich. Mit Let’s Encrypt existieren mittlerweile auch kostenlose Alternativen zu kostenpflichtigen Angeboten.
DANE einfach prüfen, einrichten und nutzen
Wie bereits erwähnt müssen Sie für die Nutzung von DANE Ihren DNS-Einträgen einen TLSA-Eintrag hinzufügen. Mit Hilfe von kostenfreien Generatoren können Sie ganz einfach einen passenden TLSA-Eintrag erzeugen oder vorher prüfen, ob bereits ein TLSA-Eintrag existiert.
Der Einsatz von DNSSEC ist zwingende Voraussetzung für die Absicherung des Web- und E-Mail-Verkehrs mittels DANE. Nicht selten scheuen Administratoren jedoch diesen Aufwand. In den letzten Jahren hat die Anzahl der DNS-Provider mit DNSSEC-Support jedoch zugenommen, so dass auch dies kein echtes Hindernis mehr darstellt. So hilft DANE nicht nur bei der Verbesserung der E-Mail- und Webserversicherheit, sondern erhöht zusätzlich die Sicherheit für den gesamten DNS-Verkehr.
