Sichere E-Mail

Übersicht

Verschiedene Mythen existieren über die Sicherheit/Vertraulichkeit von E-Mail. In diesem kurzen Paper möchte ich aufklären über das derzeit technisch Umsetzbare.

E-Mail-Übertragung

Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die Mail per SMTP zum ersten MTA (Submission-Server). Häufig ist dafür eine Anmeldung am Server notwendig. Dieser Server befindet sich entweder beim Internet-Provider oder, meistens bei größeren Firmen, in einer internen Infrastruktur. Die Adresse bzw. der Name des Submission-Servers sind im MUA per Konfiguration fest hinterlegt.

Vom Submission-Server geht die Mail dann über mehrere weitere MTAs bis zum letzten MTA, der dann die Nachricht über den MDA in die Mailbox des Nutzers legt. Die Adresse des jeweils nächsten MTA wird mit Hilfe des DNS ermittelt.

Diese Mailbox liegt meistens auf einem Server im Internet. Auf diesen greift dann der MUA des Empfängers per IMAP oder POP3 oder über einen Webmail-Client zu.

Angriffspunkte

Alle Übertragungskanäle sollten als unsicher betrachtet werden. Das gilt für die Anmeldung am Submission-Server, für den Transport der Mails, für die DNS-Information und auch für das Abrufen der Nachrichten.

Für Angriffe ist nicht zwingend ein krimineller Hintergrund notwendig, auch Überwachungsmaßnahmen werden schnell zu Angriffen.

Übertragung der Mails

Um an den Inhalt der übertragenen Nachrichten zu kommen, müsste der Angreifer auf die Verbindungen zwischen den einzelnen Servern zugreifen können.

Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das Mitschneiden auf den Verbindungen nicht mehr. Aber es ist möglich, die Verbindung zu entführen und sich für das Zielsystem auszugeben.

Namensauflösung

Die Entführung der Verbindung ist möglich durch einen Eingriff ins IP-Routing, oder durch die Manipulation der DNS-Daten, aus denen der Client die IP-Adresse des Zielsystems erfährt.

Stand der Technik

Aktuell werden etwa 80% der Mails auf dem Transportweg verschlüsselt übertragen.

Übertragung der Mails

TLS ist schon sehr lange Stand der Technik für verschlüsselte Datenübertragung. Die Authentizität der Kommunikationspartner wird über X509-Zertifikate (SSL-Zertifikate) festgestellt. Üblicherweise weist sich der Server in einer Verbindung mit seinem Zertifikat aus. Der Client prüft dises Zertifikat, um sicher zu sein, dass er mit dem richtigen Server verbunden ist.

Bei HTTPS geht der Browser davon aus, dass der Name des Zertifikats mit dem Hostnamen aus der URL übereinstimmt. Um die Echtheit des Zertifikats zu bestimmen, prüft der Browser, ob das Zertifikat von einer ihm bekannten und vertrauenswürdigen CA unterschrieben ist.

Auch die Mailprotokolle SMTP, IMAP, POP3 können eine Verschlüsselung des Übertragungsweges aushandeln. Jeoch werden hier sehr oft Server-Zertifikate verwendet, die sich nicht verifizieren lassen. Diese Zertifikate sind entweder selbst signiert oder von lokalen CAs bestätigt.

Dort wo ein Client immer mit dem selben Server kommuniziert (z.B. MUA mit Smarthost) ist es möglich, die Information über das Server-Zertifikat auf dem Client als vertrauenswürdig zu hinterlegen. Dieses Verfahren skaliert aber nicht, wenn die Menge der Zielhosts groß ist.

Namensauflösung

DNS verwendet für die meisten Anfragen das UDP-Prokoll. Diese Protokoll ist sehr anfällig für Angriffe.

Bei DNS-Informationen geht es immer um öffentlich verfügbare Information, hier geht es also nicht die Vertraulichkeit, sondern die Authentizität der Daten.

Wenn zwei DNS-Server miteinander kommunizieren (Abgleich der Domaindaten), können die Daten mit TSIG geschützt werden. Dieses Verfahren beruhg auf einem von beiden Seiten gemeinsam genutzten Schlüssel. Es skaliert nicht für eine große Zahl von DNS-Clients die eine große Zahl von DNS-Servern fragen.

Seit gut 15 Jahren gibt es DNSSec, eine Erweiterung des DNS-Protokolls und der DNS-Datensätze um die Möglichkeit, die Antworten zu signieren. Damit kann der Client die erhaltene Antwort validieren.

Das technisch Machbare - Absicherung

Der oben beschriebene Stand der Technik ist gut, aber nicht ausreichend. Verbindungen können entführt werden, DNS-Antworten sind nur selten mit DNSSec geschützt.

Übertragung der Mails

Jeder sendender MTA bzw. Client muss das Server-Zertifikat seines Kommunikationspartners prüfen! Jedoch ist die Konvention von HTTPS (Zertifikatsname == Hostname der URL) nicht auf die Mail-Kommunikation übertragbar.

Der Client benötigt also einen zweiten Kanal, über den er die Information erhält, die er zum Validieren des Server-Zertifikats benötigt. DNS bietet sich dafür an. Aber es muss gesichert sein, also DNSSec.

Namensauflösung

Seit ca. 2010 können die größen DNS-Domains über DNSSec gesichert werden. Das bedeutet, dass die Nameserver die Antworten signieren. Das gibt dem DNS-Client die Möglichkeit, die Antwort auf seine Frage zu validieren. Wenn die DNS-Antworten validierbar sind, dann ist damit auch die Informationen über die Adresse des nächsten Mailhosts validierbar und auch die Information zum Überprüfen des Server-Zertifikats des nächsten Mailhosts.

Umsetzung

Die beschriebenen Maßnahmen zum Schutz der Mailübertragung müssen kombiniert werden - TLS, Zertifikate und Überprüfung von DNS-Informationen.

Mit DANE ist ein Standard entwickelt worden, der beschreibt, wie Zertifikatsinformation unabhängig von einer vertrauenswürdigen Instanz (CA) geprüft werden kann: die notwendige Information wird im DNS (gesichert über DNSSec) abgelegt.

Die Initiative liegt in erster Linie beim Empfänger der Mail, er muss Zertifikate bereitstellen, DNSSec für seind Domain implementieren. Erst dann kann der Client die beschriebenen Mechanismen nutzen.

Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu unterstützen, sowohl auf der Server- als auch auf der Clientseite.

Übertragung

Client

Mailclients müssen versuchen, verschlüsselte Verbindungen aufzubauen. Mailclients müssen Zertifate der Server prüfen. MTA können das am einfachsten mit DANE.

Server

Für alle Serverdienste, die mit Mail im Zusammenhang stehen, müssen Zertifikate erzeugt werden, dabei spielt es keine Rolle, ob diese Zertifikate von einer zentralen CA unterzeichnet werden, oder ob sie selbstsigniert sind. Die Serverdienste müssen den Clients die Möglichkeit der Verschlüsselung anzeigen.

Namensauflösung

Client

Auf der Clientseite müssen validierende Resolver verwendet werden, als Software, die in der Lage ist, neben der eigentlichen Namensauflösung auch die Gültigkeit der Antwort zu überprüfen.

Server

Der Nameserver für die Zieldomain muss DNSSec unterstützen, die DNS-Zone muss signiert sein und die Schlüssel müssen an die Elternzone weitergegeben werden. Normalerweise ist dafür der Registrar der Domain verantwortlich. Nur eine kleine Zahl der Domain-Registrare verfügt bisher über die erforderlichen Schnittstellen.

Im DNS muss für die Zielserver ein Datensatz eingetragen sein, dieser enthält die Information über das Server-Zertifikat.

Schlussfolgerung

Eine sichere Mailübertragung wird es nur geben, wenn beide Maßnamen (TLS und DNSSec) gemeinsam verwendet werden. Zum aktuellen Zeitpunkt ist bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind und Fachwissen über diese Bereiche vorhanden.

Wirklich sichere Mailübertragung ist nur mit End-To-End-Verschlüsselung (S/MIME, GPG, PGP) möglich. TLS und DANE können nur die Sicherheit zwischen den einzelnen Mailhosts gewährleisten.

Glossary

CA: Certificate Authority - eine vertrauenswürdige Organisation, die sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden. Dazu überprüft sie die Identität des Antragsstellers.
DNS: Domain Name System - eine verteilte Datenbank, die Informationen über Domains, IP-Adressen, verantwortliche Mailserver bereitstellt.
IMAP: Internet Message Access Protocol - mit diesem Protokoll können MUAs auf Mails zugreifen. Die Mails bleiben dabei auf dem Server. (RFC 3501 u.a.)
MDA: Mail Delivery Agent heisst die Software, die die Mail vom letzten MTA übernimmt und in die Mailbox des Nutzers legt. (Protokolle: LMTP, Pipeline)
MTA: Der Mail Transfer Agent ist das, was wir normalerweise „Mailserver“ nennen, also Exim, Postfix, Qmail, Sendmail, …. (Protokolle: SMTP)
MUA: Der Mail User Agent ist das, was wir normalerweise „Mailprogramm“ nennen, das ist also für viele das Outlook, der Thunderbird, Mutt, Evolution,… Es ist im strengen Sinne nicht der Webbrowser, auch wenn wir Webmail damit machen können. (Protokolle: SMTP, IMAP, POP3)
POP3: Post Office Protocol - mit diesem Protokoll können MUAs auf Mails zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC 1939)
SMTP: Simple Mail Transfer Protocol - mit diesem Protokoll werden Mails übertragen, vom MUA zum Submission Server und von MTA zu MTA. (RFC 5321)
TLS/SSL: Transport Layer Security, Secure Socket Layer - ein Protokoll, mit dessen Hilfe es möglich ist, den Übetragungskanal zwischen zwei Endpunkten gegen Dritte zu schützen. Neuere Versionen heissen TLS, ältere Versionen heißen SSL. (SSLv3.1 entpricht TLSv1.0)
TSIG: Transaction Signature - bei der Übertragung von DNS-Information ein Verfahren zur Authentifizierung und Integritätsprüfung
Zertifikat | X509-Zertifikat: Ein elektronisches Dokument, das den Besitz z.B. eines bestimmten Domainnamens bestätigt. Dieses Dokument ist in der Regel von einer CA unterzeichnet, die damit bestätigt, die im Zertifikat festgehaltenen Eigenschaften überprüft zu haben.

Disclaimer

Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht, nur unwesentliche Details zu übergehen, bin mir jedoch im Klaran darüber, dass jeder eine andere Sichtweise auf unwichtig hat.