Sicherer E-Mail Transport


Sicherer E-Mail Transport bedeutet sichere E-Mails. Für den Transport und zur Vermeidung von Spam-Mails gibt es mittlerweile einige Sicherheitsmechanismen und Standards. Zwar haben sich davon schon einige durchgesetzt wie z. B. die nahezu flächendeckende Einführung von TLS, aber es gibt noch Optimierungspotential. Und dies möchte ich im folgenden Artikel beschreiben.

Sicherer E-Mail Transport

Schwachstellen TLS im E-Mail Transport und Spam

Neben dem hohen Aufkommen von Spam- und Phishing-Mails hat das TLS im Bereich sicherer E-Mail Transport noch einige Schwächen, da die Authentizität der verwendeten Zertifikate und die Verschlüsselung zwischen den Absender- und Empfangsmailservern nicht immer gewährleistet ist.

Die erste Schwachstelle liegt bei den Zertifikatsausstellern (CAs), deren Sorgfalt bei der Zertifikatsausgabe oder deren Systemsicherheit nur schlecht nachvollziehbar ist. Daher könnte ein Angreifer ein gültiges Zertifikat für einen Host erstellen, dessen Besucher er ausnutzen möchte.

Der nächse wunde Punkt ist die Prüfung der Zertifikate im Mailserver. Der richtige Weg wäre, die Zertifikate aller Mailserver einzeln zu prüfen, die eine Verschlüsselung anbieten. Dies passiert aber in der Praxis häufig eben nicht. Mailserver nutzen TLS, wenn es möglich ist und machen sich nicht die Mühe der Identitätsprüfung dem s. g. opportunistisches TLS. Es geht nur um die verschlüsselte Übertragung, egal wie.

Eine weitere Schwachstelle ist die Möglichkeit für einen Man-in-the-Middle-Angriff. Jeder Verbindungsaufbau von Mailserver startet unverschlüsselt. Über die unsere Verbindung vereinbaren der Sende- und Empfangsserver per STARTTLS-Befehl die Verschlüsselung. Unterstützt einer der beiden Server kein TLS, so findet der Versand der E-Mails zwischen ihnen unverschlüsselt statt. An diesem wunden Punkt kann nun ein Man-in-the-Middle-Angriff stattfinden.

Es gibt also einige Schwachstellen beim E-Mail Transport. Abhilfe schaffen aber folgende Sicherheitsmechanismen.

SPF, DKIM und DMARC

SPF steht für Sender Policy Framework und dient dazu, die Mail anhand der IP Adresse des sendenden Mailservers zu validieren. Dazu wird ein DNS-Eintrag in der Zone der Email-Domäne erstellt, der die Systeme auflistet, welche berechtigt sind, in deren Namen Nachrichten zu versenden.

DKIM steht für Domain Keys Identified Mail und überprüft wie SPF die Email-Domäne der «mail from:» Adresse. Allerdings wird nicht die IP Adresse des sendenden Servers verglichen, sondern die Nachricht und der Mail-Header werden digital signiert. Dafür benutzt das sendende System den privaten Teil eines asymmetrischen Schlüsselpaares. Das öffentliche Gegenstück wird mit einem DNS-Record in der Email-Domäne zugänglich gemacht. Somit kann jede Gegenstelle die Signatur und damit die Herkunft der Nachrichten überprüfen.

SPF und auch DKIM prüfen die Domäne im «Mail From» und nicht die Domäne, die dem Benutzer angezeigt wird. DMARC steht für Domain-based Message Authentification, Reporting and Conformance und ist ein E-Mail Validierungssystem, das entwickelt wurde, um Domains vor der Verwendung für E-Mail Spoofing, Phishing-Betrug und anderer Cyberkriminalität zu schützen. Dies passiert über eine DNS-Richtlinie, die mehr oder weniger zwingend voraussetzt, dass einer der beiden Checks die gleiche Domäne betrifft, wie die der Empfänger im «From»-Feld sieht.

Die Kombination aus den Sicherheitsmechanismen SPF, DKIM und DMARC zählen zu den effektivsten Möglichkeiten, sich vor Spam- und Phishing-Mails zu schützen. Weiterhin wird die E-Mailzustellbarkeit optimiert, da restriktive Empfangsserver seltener E-Mails von sicheren Absenderserver bouncen.

MTA-STS

MTA-STS steht für Mail Transfer Agent-Strict Transport Security und ist, wie der Name schon sagt, ein Protokoll, das den verschlüsselten Transport von Nachrichten zwischen zwei SMTP-Mailservern ermöglicht. MTA-STS gibt den sendenden Servern vor, dass E-Mails nur über eine TLS-verschlüsselte Verbindung versendet werden sollen und keine Zustellung erfolgt, wenn keine gesicherte Verbindung aufgebaut werden kann.

Wenn nun bei der E-Mail-Zustellung durch den Einsatz von MTA-STS Probleme auftreten wie z. B. abgelaufene TLS-Zertifikate, Fehlkonfigurationen in E-Mail-Servern oder das Scheitern bei der Aushandlung einer sicheren Verbindung aufgrund mangelnder Unterstützung für TLS-Verschlüsselung, sichert das TLS-RPT (SMTP TLS-Reorting) die Berichterstattung und stellt für die Überwachung einen Diagnosebericht bereit.

DNSSEC

DNSSEC steht für Domain Name System Security Extensions. Es handelt sich um einen in mehreren RFCs (Requests for Comments) spezifizierten Internetstandard zur Sicherstellung der Integrität und Authentizität der im Domain Name System übertragenen Informationen. Die Standards erweitern das DNS-Protokoll um sicherheitsbezogene Verfahren und ermöglichen es, DNS-Informationen digital zu signieren. Zum Einsatz kommen öffentliche und private Schlüssel und Mechanismen der Public Key Infrastructure (PKI). Für DNSSEC muss es mindestens einen externen Zertifikatsaussteller (Trust Anchor) geben, damit sich nachvollziehen lässt, dass die DNS-Antworten unverfälscht sind.

Durch DNSSEC ist sichergestellt, dass die DNS-Daten weder manipuliert wurden noch von einer anderen Quelle stammen. Private Schlüssel werden verwendet, um die Resource Records digital zu signieren. Mit dem öffentlichen Schlüssel lässt sich die Signatur von den Empfängern der Daten prüfen. Damit die Sicherheitsmechanismen der Domain Name System Security Extensions funktionieren, muss DNSSEC auf Seiten des Anbieters der DNS-Informationen und beim anfragenden Clientsystem unterstützt werden. Die im Jahr 1999 im RFC 2535 veröffentlichte erste Version von DNSSEC war aufgrund einiger Mängel nicht großflächig einsetzbar. Erst die im Jahr 2005 veröffentlichten RFCs beseitigten diese Mängel. Auf Root-Ebene des Internets startete DNSSEC im Jahr 2010. Mittlerweile sind circa 90 Prozent der Top-Level-Domains signiert.

DANE

TLS ist das Standardverfahren zum Verschlüsseln von E-Mails. Leider hat TLS Schwächen, weil die Authentizität der verwendeten Zertifikate nicht immer gewährleistet ist. Das DANE (steht für DNS-based Authentication of Named Entities) ist ein Netzwerkprotokoll, das dazu dient, den Datenverkehr abzusichern. Das Protokoll erweitert die verbreitete Transportwegverschlüsselung SSL/TLS in der Weise, dass die verwendeten Zertifikate nicht unbemerkt ausgewechselt werden können, und erhöht so die Sicherheit beim verschlüsselten Transport von E-Mails und beim Zugriff auf Webseiten. 

DANE setzt auf DNSSEC auf, das im Prinzip eine eigene PKI (Public Key Infrastructure) ist, deren Hauptschlüssel (Root DNSSEC Key) die Non-Profit-Organisation ICANN verwaltet (Internet Corporation for Assigned Names and Numbers). Dank der Trusted Community Representatives, die die ICANN in Sachen DNSSEC beaufsichtigen, kann man den Hauptschlüssel und damit die DNSSEC-PKI als vertrauenswürdig ansehen. Das erlaubt, Zusatzinformationen in die DNS-Zone-Files zu packen, die der DNS-Server als zusätzliche Records ausliefert wie z. B. für das TLS/SSL-Protokoll. DANE definiert dazu einen neuen DNS-Record namens „TLSA“. Dieser enthält ein Zertifikat im PKIX-Format mit dem öffentlichen Schlüssel. 

Praktisch funktioniert DANE wie folgt:

  • Eine Mail an benutzer@example.de wird dem lokalen Mailserver übergeben.
  • Dieser erfragt per DNS die Mailserver der Empfängerdomäne (MX-Records) und löst die Hostnamen aus den MX-Records in IPv4-/IPv6-Adressen auf.
  • Der lokale Mailserver wählt einen der entfernten Server aus und erfragt per DNSSEC dessen TLSA-Record.
  • Nun fragt der Sender beim Ziel eine TLS-Verbindung an.
  • Lehnt das Ziel TLS ab, bricht der Sender je nach vorgegebener Policy den Übermittlungsversuch ab oder fällt auf unverschlüsselten Transport zurück, was aber niemand will.
  • Der Sender prüft das vorgelegte TLS-Zertifikat gegen den Hash aus dem TLSA-Record.
  • Stimmt alles, liefert der Sender die Mail aus, sonst bricht er die Übertragung ab.

Zusammenfassung

Ein sicherer E-Mail Transport wird mit all diesen Sicherheitsmechanismen gewährleistet und kann so sensible Daten schützen. Was diese Sicherheitsmechanismen allerdings nicht leisten, ist eine Ende-zu-Ende-Verschlüsselung. Ihre E-Mails lagern teilweise unverschlüsselt auf den Servern der Provider. Und auf die Provider-Server haben nicht nur deren Administratoren Zugriff, sondern ggf. auch Ermittlungsbehörden. Dementsprechend ist für eine Ende-zu-Ende-Verschlüsselung noch ein gesonderter Eingriff notwendig. Dazu habe ich in meinem Blog an anderer Stelle einen interessanten Artikel verfasst.

[Ende Artikel sicherer E-Mail Transport]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.