• Rss
  • LinkedIn
  • Youtube
  • Twitter
  • Instagram
  • English English Englisch en
  • Deutsch Deutsch Deutsch de
Sales: +49 5251 304-800 | Support: +49 5251 304-636
NoSpamProxy
  • HOME
  • PRODUKT
    • NoSpamProxy Cloud
    • NoSpamProxy Protection
    • NoSpamProxy Encryption
    • NoSpamProxy Large Files
    • NoSpamProxy Disclaimer
  • SUPPORT
    • Knowledge Base
    • Forum
    • Schulungen
    • Supportanfrage
    • Software-Download
    • Ressourcen
  • PARTNER
    • Partner finden
    • Partner werden
    • Partnerportal
  • UNTERNEHMEN
    • Team
    • Referenzen
    • Karriere
    • Kontakt
  • EVENTS
    • Events
    • Webcasts
  • BLOG
    • Blog
    • Newsletter
  • KOSTENFREI TESTEN
    • Preisanfrage stellen
    • Kostenfrei testen
  • Deutsch
    • English
  • Search
  • Menu Menu
  • DNS-based Authentication of Named Entities DANE

Absenderreputation und E-Mail-Sicherheit – Teil 5: DNS-based Authentication of Named Entities (DANE)

Stefan Feist | Technischer Redakteur
Autor: Stefan FeistTechnischer Redakteurhttps://www.linkedin.com/in/stefan-feist-23b257b0/–Auf LinkedIn vernetzen

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.

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:

  • Unrechtmäßige Zertifikate

    Jede Zertifizierungsstelle (Certificate Authority, CA) auf der Welt kann Zertifikate für jede beliebige Domain ausstellen. Dies bedeutet, dass auch unrechtmäßige Zertifikate unter Umständen von E-Mail-Servern als rechtmäßig angesehen werden, einfach nur, weil eine der zahllosen – eventuell nicht vertrauenswürdigen – CAs ein Zertifikat für eine Domain ausgestellt hat. Natürlich unterliegen kommerzielle CAs sehr strengen Richtlinien, die genau festlegen, unter welchen Bedingungen ein Zertifikat für eine Domain, einen Hostnamen oder eine E-Mail-Adresse ausgestellt werden darf. In der Vergangenheit hat es jedoch immer wieder Versuche von Kriminellen gegeben, Zertifikate für bekannte Domains wie google.com oder microsoft.com zu fälschen.

  • Überwachung durch Regierungen

    Auch Regierungen können CAs betreiben und TLS-Zertifikate ausstellen. Dies ermöglicht es diesen Regierungen, den E-Mail-Verkehr oder Websiteinhalte und -nutzung zu überwachen. Vor allem in Ländern, die es mit Menschen- oder Freiheitsrechten nicht genau nehmen, ist dies problematisch: So ist es nämlich möglich, dass Ermittlungsbehörden und Geheimdienste ein Zertifikat für einen bestimmten, besonders interessanten Namen erhalten können.

  • Fehlende Authentisierung

    Bei der Erstellung solcher Zertifikate findet keine wirksame Authentisierung statt. Es wird unter Umständen nicht einmal geprüft, ob die Domain wirklich dem Antragsteller gehört, sondern lediglich, ob die angegebene E-Mail-Adresse funktioniert.

  • Selbstsignierte Zertifikate

    Zertifikate von Zertifizierungsstellen kosten Geld. Dies schreckt viele davon ab, TLS einzusetzen. Selbstsignierte Zertifikate sind ebenfalls keine Alternative, da sie auf Grund fehlender Möglichkeiten zur Validierung kein Vertrauen besitzen. Auch Kriminelle können sich diese ausstellen.

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:

NummerWertBedeutung
1: Zertfikatsverwendung0PKIX-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.
1PKIX-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.
2DANE-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.
3DANE-EE: Domain Issued Certificate – Akzeptieren (vertrauen) des im TLSA-Record referenzierten Zertifikats; keine Prüfung der Vertrauenshierarchie.
2: Selektor0Das vollständige Zertifikat wird genutzt.
1Nur der öffentliche Schlüssel wird genutzt.
3: Zertfikatszuordnung0Vollständiges Zertifikat, kein Hash; erzeugt sehr lange DNS-Antworten.
1SHA-256 Hash-Wert
2SHA-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.

DNS TLSA

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.

NoSpamProxy kostenfrei testen

Verpassen Sie nicht die anderen Artikel unserer Serie zu 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)

  • teilen 
  • mitteilen 
  • twittern 
  • E-Mail 

SUCHE

PRODUKT

  • Alle Beiträge
  • NoSpamProxy Cloud
  • NoSpamProxy Protection
  • NoSpamProxy Encryption
  • NoSpamProxy Large Files

Knowledge Base

Knowledge Base

Hinweis: Die Informationen in dieser Knowledge Base gelten nur für NoSpamProxy bis Version 13.2. Sämtliche Informationen für NoSpamProxy 14 und höher finden Sie in der Online-Dokumentation.

KATEGORIE

  • Alle Beiträge
    • News
    • Produkt
    • Technik & Support
    • Termine
    • Updates
Net at Work GmbH
Am Hoppenhof 32 A
33104 Paderborn
Tel. +49 5251 304-800
Fax +49 5251 304-650
www.netatwork.de

NoSpamProxy-Newsletter

Jetzt abonnieren
Subscribeto RSS Feed

NoSpamProxy

  • NoSpamProxy Cloud
  • NoSpamProxy Protection
  • NoSpamProxy Encryption
  • NoSpamProxy Large Files
  • NoSpamProxy Disclaimer
  • Preisanfrage
  • Team
  • Karriere
  • AGB
  • Datenschutzinformation für Geschäftspartner und Bewerber
  • Cybersicherheit (PSIRT)

Partner

  • Vertriebspartner
  • Partner werden
  • Partner finden
  • Zertifikate kaufen
  • Newsletter abonnieren

Kategorien

  • Alle Themen
  • News
  • Technik & Support
  • Termine
  • Updates
  • Zertifikate bestellen

Letzte News

  • Info IconKritische Outlook-Schwachstelle: Keine Gefahr für NoSpamProxy-Kunden24.03.2023 - 15:08
  • Standardfiltereinstellungen in NoSpamProxy 1422.03.2023 - 10:00
  • NoSpamProxy Update BannerGlobal Rollout NoSpamProxy Version 14.0.515.03.2023 - 15:20
IMPRESSUM • EULA • Datenschutzerklärung • © 2023 Net at Work GmbH
  • Rss
  • LinkedIn
  • Youtube
  • Twitter
  • Instagram
Support Information – Probleme bei der Zustellung von E-Mails an 1&1...Info IconRich Text File Type Evasion Tricks erfolgreich abwehren PreviewRich Text File Type Evasion Tricks erfolgreich abwehren
Scroll to top