STARTTLS ist nicht genug...

...aber besser als nicht. Sicherheit und Verschlüsselung bei Mails bedeutet für mich SMIME oder PGP. Sehr oft werde ich aber mit der Aussage konfrontiert, dass wir das doch alles nicht mehr brauchen, da SMTP auch per TLS verschlüsselt werden kann. Diese Seite beschreibt die Sicherheitsprobleme mit TLS bei SMTP.

TLS vs. PGP und SMIME

Zuerst muss ich sagen, das die Transportverschlüsselung TLS und die Mailverschlüsselung mit PGP/SMIME sich nicht ausschließen sondern sogar parallel verwendet werden können. SMIME/PGP bedeutet, dass die Endpunkte, d.h. der Anwender oder ein Gateway in der Nähe des Anwender verschlüsselt die Mail mit dem Public Key der Empfänger und signiert die Mail mit dem privaten Schlüssel des Absenders. Dieses gesicherte Datenpaket dann nun über beliebige System, Relay-Stationen, WAN-Links etc. übertragen werden. Das Element an sich ist so verschlüsselt, dass es nur vom Empfänger gelesen werden kann.

TLS hingegen ist eine Sicherung der Übertragungswege zwischen den Mailserver. Damit werden alle Mails über diesen Weg verschlüsselt und mit den richtigen Zertifikaten können sich die beiden Kommunikationspartner sogar identifizieren. Interessanterweise haben die meisten Mailserver mittlerweile per Default ein (selbsterstelltes) Zertifikat installiert, so dass viele Verbindungen mittlerweile sogar per TLS gesichert werden. Wer heute mit Wireshark mit schnüffelt, sieht erst mal nur TCP-Verbindungen über Port 25, die aber verschlüsselt sind. Ist damit aber schon alles im grünen Bereich ?.

Aus meiner Sicht ist es mitnichten so. TLS ist schön aber wir sind noch weit davon entfernt, TLS als Sicherheit für Mail zu propagieren.

Risiko: Relay-Station

Beim Homebanking per HTTPS bauen Sie mit ihrem Browser auf dem Client eine direkte Verbindung zum Service auf und können das Zertifikat sehen und Warnungen erkennen. SMTP funktioniert aber anders. Hier gibt es keine direkte Verbindung zwischen den beiden Endpunkten, sondern die Daten laufen über mehrere Zwischenstationen. Der Weg von Mailclient zum Postfachserver ist zwar meist intern aber beim Weg über das Internet ist es nicht immer eine direkte Verbindung zwischen Absender und Empfänger.

Verschiedene Firmen nutzen aber durchaus Relay-Stationen oder gehostete Spamfilter, Backup-MX-Server. Damit verliert der absendende Server aber die Kontrolle über die Verschlüsselung. Er kann maximal erzwingen, dass die Mail bis zum nächsten Hop verschlüsselt ist. Alles danach entzieht sich seiner Kontrolle und Kenntnis.

Weiterhin kann nicht sichergestellt werden, dass die Relay-Stationen die Mails ausreichend "sicher" behandelt. Mailserver arbeiten nach dem Prinzip "Store and Forward", d.h. die Mails werden beim Empfang irgendwo zwischengespeichert ehe Sie auf den nächsten Weg gehen.

Risiko: Firewall, SMTP-Proxy Optimierer

Nehme wir an, dass alle Stationen einer Mail auch TLS unterstützen und auch nutzen, dann ist ein Angriffsvektor immer noch der Handshake. Die initiale Verbindung per SMTP erfolgt über Port 25 und ist erst einmal unverschlüsselt. Kaum ein Server versucht direkt eine Verbindung per 465/TLS. Der angesprochene Server antwortet mit einem "220 OK" und sendende Server startet mit einem "EHLO". Wenn der Zielserver TLS unterstützt, dann enthält die Antwort auch den String "STARTTTLS". Der sendende Server kann dann von der unverschlüsselten Verbindung auf TLS umschalten.

Das Problem dabei ist aber, dass die Information "STARTTLS" über den unverschlüsselt aber vor allem ungesicherten Kanal erfolgt. Selbst ein einfacher Cisco Router (Stichwort SMTP-Screening) kann einzelne Verben in einem Paket streichen oder ersetzen. Wenn jemand als zwischen zwei Server eine SMTP-Verbindung ablauschen will, muss einfach alle Pakete mit Quellport 25 auf den String "STARTTLS" durchsuchen und entfernen oder verändern.

Diese Lücke kann ein Administrator natürlich so umgehen, dass er für ein gewisses Ziel die Nutzung von "TLS" erzwingt und ansonsten die Mail nicht weiter gesendet wird. Das kann ein Administrator für bestimmte Partner und Ziele durchaus machen. Wenn Sie aber TLS für alle möglichen Ziele im Internet erzwingen, dann werden Sie keine Mails mehr an Ziele senden können, die TLS noch nicht unterstützen. Es wird also sicher noch viele Jahre Teilstrecken oder Zielserver geben, die TLS nicht unterstützen.

Risiko: Zertifikat

Selbst wenn im Idealfall alle Mailserver TLS unterstützen sollten, so werden wir vermutlich nie den Stand erreichen, dass diese Server auch "vertrauenswürdige" Zertifikate nutzen. Viele nutzen Selbst-Zertifikate oder eine private PKI. Der absendende Mailserver hat nun die Wahl, ob er gänzlich unverschlüsselt sendet oder dem Zertifikat vertraut. Die meisten Mailserver vertrauen solchen Zertifikate, denn es ist wohl immer noch besser, die Mals so verschlüsselt zu senden. Das sperrt zumindest die Lauscher auf der Leitung aus.

Die Schwäche ist aber auch hier, dass mit wenig Aufwand es möglich ist, diese Verbindung durch einen Proxy zu leiten und das Zertifikat durch ein anderes Zertifikat zu ersetzen. Ein "Man in the Middle" könnte also die Verbindungen auf seinen Server umleiten und ein eigenes Zertifikat präsentieren. Der absendende Server akzeptiert auch dieses Zertifikat und sendet die Daten an den "Mittelsmann", der unverschlüsselt an die Daten kommt.

  • Zwang zum Public Zertifikat
    Würde man beim Versand auf öffentliche Zertifikate bestehen, wäre ein Man in the Middle natürlich erschwert aber heute kann man nicht sicher sein, das Geheimdienste nicht auch ein Zertifikat für beliebige Namen erstellen können.
  • Zertifikatname überprüfen
    Natürlich könnte man auch sicherstellen, dass der Name im Zertifikat mit dem erwarteten Namen übereinstimmt. Der erwartete Name wäre aber aus dem MX-Record zu übernehmen und der kann sich durchaus auch verändern (Providerwechsel etc.) Insofern würde auch nicht auffallen, wenn jemand per DNS-Manipulationen die Verbindung umleiten
  • Certificate Pinning
    Um Man-in-the-Middle zu erschweren, könnte ein Server sich die früher genutzten Zertifikate für eine gewisse Zeit merken und bei Änderungen den Versand unterbinden. Allerdings ist auch hier die erste Kommunikation ungesichert und Änderungen können auch regulär erfolgen.

Solange nicht alle Mailserver der Welt öffentliche vertrauenswürdige Zertifikate nutzen und die DNS-Abfragen per DNSSEC "gesichert" sind, ist eine "verpflichtend sichere" Verbindung per TLS nicht aktivierbar. Und damit ist der gesamte Weg nicht als sicher zu bezeichnen.

DNSSEC und DANE/TLSA

Zukünftig könnte sich dieses Problem der Zertifikate der Gegenseite durch DANE (DNS-Based Authentication of Named Entities) bessern. Ein Betreiber eines Servers veröffentlicht wie bisher seinen MX-Eintrag im DNS aber diesmal ist dieser Eintrag per DNSSEC gegen Veränderungen geschützt. Das ist natürlich noch kein 100% Schutz, weil ein Angreifer die DNS-Auflösung des Absenders manipulieren könnte, so dass dieser gar keine DNSSEC-Anfragen beantwortet bekommt. Wenn dies aber möglich ist, dann kann der Absender sicher sein, dass der MX-Eintrag nicht gefälscht ist.

Im zweiten Schritt kann der Betreiber des Zielservers auch den Fingerprint oder Public-Key des verwendeten Zertifikats per DNS, abgesichert durch DNSSEC, veröffentlichen. Wenn der Absender dies unterstützt, kann er so einfach sicherstellen, die richtige Gegenstelle zu finden. Ein "Man in the Middle"-Angriff mit einem falschen Zertifikat wäre so schon mal ausgeschaltet.

STARTTLS erzwingen

Wenn Sie nun aber die Technik zur Mailverschlüsselung per SMIME/PPG verzichten wollen und stattdessen die Nutzung von TLS vorschreiben, dann bewegen Sie sich auf dünnem Eis. In der RFC 3207 steht dazu klar:

If the client receives the 454 response, the client must decide whether or not to continue the SMTP session.  Such a decision isbased on local policy.  For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication.  However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.  This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure.  A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.
Quelle: RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security https://www.ietf.org/rfc/rfc3207.txt

Allerdings ist ein RFC genau genommen nur eine Beschreibung, wie man es hinsichtlich der Koexistenz machen sollte. Ich für mich würde mir als Firma sehr wohl die Freiheit rausnehmen, unverschlüsselte Mails z.B. gar nicht anzunehmen. Da man aber erst beim Empfang der Mail erkennen kann, ob diese per SMIME/PGP verschlüsselt ist und da die Mail schon teilweise unterschlüsselt übertragen wurde, ist ein TLS-Zwang auf dem Transport der sichere Weg. Auch wenn man damit genau genommen die RFC verletzt.

Zusammenfassung

Die Nutzung von TLS für SMTP-Verbindungen ist eine zusätzliche Sicherheit, die in den meisten Fällen sogar per Default schon mit Selbst-Zertifikaten genutzt wird. Ein echter Zwang zur sicheren Übertragung ist heute und wohl auch in weiter Zukunft nicht möglich. Wer also wirklich auf der sicheren Seite sein will, muss SMIME/PGP nutzen. Nur so ist die Ende zu Ende-Verschlüsselung sichergestellt und der Empfänger kann über die digitale Signatur auch noch sicher sein, dass der Absender nicht gefälscht und der Inhalt nicht verändert wurde.

Wer den Anwendern und sich die Mühe einer lokalen Lösung und Zertifikatverwaltung ersparen will, sollte sich entsprechende Gateways anschauen

Ich nutze dazu natürlich meine eigenes Gateway "NoSpamProxy Encryption"
https://www.nospamproxy.de/de/produkt/nospamproxy-encryption/

Weitere Links