Im Jahr 2013 enthüllten von Edward Snowden geleakte Dokumente, dass Geheimdienste E-Mail-Verkehr zwischen den Rechenzentren großer Anbieter abfingen. Die Verbindungen waren nicht verschlüsselt – E-Mails flossen im Klartext über Glasfaserkabel und waren für jeden leicht lesbar, der sie anzapfen konnte.
Die Reaktion war schnell. Google, Microsoft, Yahoo und andere setzten zügig Verschlüsselung zwischen ihren Servern ein. Die Technologie, die sie nutzten, war STARTTLS – ein Mechanismus, der seit Jahren existierte, aber nicht flächendeckend implementiert war. Innerhalb weniger Monate war der Großteil des E-Mail-Verkehrs zwischen großen Anbietern verschlüsselt.
STARTTLS ist nicht perfekt, aber es ist das Fundament der E-Mail-Verschlüsselung auf dem Transportweg. Zu verstehen, wie es funktioniert, hilft, sowohl seinen Schutz als auch seine Grenzen zu verstehen.
Wie STARTTLS funktioniert
STARTTLS ist eine SMTP-Erweiterung, die eine Klartextverbindung auf eine verschlüsselte Verbindung hochstuft. Der Name beschreibt buchstäblich, was passiert: Man startet TLS.
Hier ist die Abfolge: Ein Client verbindet sich mit einem Server auf einem Standard-SMTP-Port. Die Verbindung beginnt unverschlüsselt – beide Seiten sehen alles im Klartext. Der Client sendet einen EHLO-Befehl, und der Server antwortet mit seinen Fähigkeiten, einschließlich "250-STARTTLS", wenn er Verschlüsselung unterstützt.
Wenn der Client Verschlüsselung möchte (und das sollte er), sendet er den STARTTLS-Befehl. Der Server antwortet mit "220 Ready to start TLS." An diesem Punkt führen beide Seiten einen TLS-Handshake durch – derselbe Prozess, der HTTPS-Verbindungen absichert. Sobald der Handshake abgeschlossen ist, ist alles Weitere verschlüsselt.
Der Client beginnt die SMTP-Unterhaltung dann von vorn, jetzt jedoch verschlüsselt. Er sendet ein weiteres EHLO, authentifiziert sich bei Bedarf und fährt mit dem Versand von E-Mails fort. Wer den Netzwerkverkehr beobachtet, sieht nur verschlüsselten Kauderwelsch.
Dieser "Upgrade"-Ansatz heißt opportunistische Verschlüsselung. Die Verbindung beginnt unverschlüsselt, und Verschlüsselung wird hinzugefügt, wenn beide Seiten sie unterstützen. Dies unterscheidet sich von implizitem TLS (verwendet auf Port 465), bei dem die Verbindung vom ersten Byte an verschlüsselt ist.
Warum der Upgrade-Ansatz
Man könnte sich fragen, warum E-Mail nicht einfach verschlüsselt startet, so wie HTTPS. Die Antwort lautet: historische Kompatibilität.
SMTP wurde 1982 entworfen, lange bevor Verschlüsselung ein Thema war. Millionen Mailserver waren im Einsatz, die unverschlüsseltes SMTP sprachen. Als Verschlüsselung wichtig wurde, musste sich das Protokoll weiterentwickeln, ohne die bestehende Infrastruktur zu zerstören.
STARTTLS löste dies, indem es Verschlüsselung optional und aushandelbar machte. Alte Server, die es nicht unterstützen, werben die Fähigkeit einfach nicht aus; Verbindungen laufen dann unverschlüsselt. Neue Server können bei der Kommunikation mit anderen neuen Servern auf Verschlüsselung hochstufen. Das Ökosystem konnte schrittweise migrieren.
Diese Rückwärtskompatibilität hatte ihren Preis. Der Upgrade-Mechanismus schafft ein Fenster der Verwundbarkeit, und die optionale Natur bedeutet, dass Verschlüsselung nicht garantiert ist. Doch so konnte sich Verschlüsselung im E-Mail-Ökosystem verbreiten, ohne einen Stichtag zu erfordern, an dem sich alles auf einmal ändern musste.
Die Sicherheitsgrenzen
STARTTLS bietet echten Schutz, hat aber bekannte Schwächen.
Das größte Problem ist der Downgrade-Angriff. Da die STARTTLS-Aushandlung im Klartext stattfindet, kann ein Angreifer, der den Verkehr abfangen kann, die STARTTLS-Fähigkeit aus der Antwort entfernen. Der Client glaubt, der Server unterstütze keine Verschlüsselung, und macht unverschlüsselt weiter. Keine der beiden Seiten merkt, dass der Angriff stattgefunden hat.
Das ist nicht nur theoretisch. Forschende haben dokumentiert, dass Internetanbieter und Nationalstaaten STARTTLS-Stripping-Angriffe durchführen. Ihre E-Mail kann beim Verlassen Ihres Servers und beim Eintreffen am Ziel verschlüsselt sein, doch irgendwo dazwischen hat jemand die Verschlüsselung entfernt und alles gelesen.
Die Zertifikatsvalidierung ist eine weitere Schwachstelle. Viele Mailserver validieren Zertifikate während STARTTLS nicht strikt. Sie akzeptieren selbstsignierte Zertifikate, abgelaufene Zertifikate oder Zertifikate für den falschen Hostnamen. Das erleichtert die Bereitstellung, bedeutet aber, dass ein Man-in-the-Middle-Angreifer ein gefälschtes Zertifikat vorlegen und den Verkehr abfangen könnte.
Diese Einschränkungen sind der Grund, warum MTA-STS und DANE existieren – sie bieten Mechanismen, um Verschlüsselung zu erzwingen und Zertifikate zu validieren und schließen die Lücken, die STARTTLS offen lässt.
STARTTLS vs. implizites TLS
E-Mail unterstützt zwei Ansätze für Verschlüsselung: STARTTLS (explizites TLS) und implizites TLS.
Bei STARTTLS beginnt die Verbindung unverschlüsselt und wird hochgestuft. Dies wird auf Port 587 für die Einreichung verwendet und kann auf Port 25 für Server-zu-Server-Übertragung eingesetzt werden.
Bei implizitem TLS ist die Verbindung vom ersten Byte an verschlüsselt. Es gibt keine Klartextphase, keine Upgrade-Aushandlung. Dies wird auf Port 465 für die Einreichung verwendet.
Implizites TLS ist wohl sicherer, da es beim Verbindungsaufbau keine Möglichkeit für Downgrade-Angriffe gibt. Der TLS-Handshake passiert sofort; schlägt er fehl, schlägt die Verbindung fehl. Es gibt kein Fallback auf Klartext.
STARTTLS ist jedoch breiter verbreitet, insbesondere für die Server-zu-Server-Kommunikation. Port 25 mit STARTTLS ist der Weg, wie die meisten E-Mails zwischen Servern fließen. Implizites TLS auf Port 465 wird hauptsächlich für die Client-Einreichung verwendet.
Für Ihre eigene E-Mail-Einreichung ist beides in Ordnung, wenn es korrekt implementiert ist. Für Server-zu-Server-E-Mails ist STARTTLS auf Port 25 der Standard, ergänzt durch MTA-STS oder DANE für stärkere Zusicherungen.
STARTTLS-Unterstützung prüfen
Sie können prüfen, ob ein Server STARTTLS unterstützt, mithilfe von Kommandozeilenwerkzeugen.
Verbinden Sie sich mit telnet oder netcat zum SMTP-Port und senden Sie einen EHLO-Befehl. Die Antwort des Servers listet seine Fähigkeiten auf. Wenn "250-STARTTLS" in der Liste erscheint, unterstützt der Server Verschlüsselungs-Upgrades.
Zum Testen der tatsächlichen TLS-Verbindung verwenden Sie OpenSSL: "openssl s_client -starttls smtp -connect mail.example.com:25". Dies stellt die Verbindung her, führt STARTTLS aus, führt den TLS-Handshake durch und zeigt Ihnen das Zertifikat und Verbindungsdetails.
Online-Werkzeuge wie CheckTLS und MXToolbox können die STARTTLS-Unterstützung für die Mailserver jeder Domain testen. Sie berichten, ob Verschlüsselung verfügbar ist, und liefern Details zu den verwendeten Zertifikaten.
Das Überwachen von STARTTLS über Ihren gesamten E-Mail-Verkehr hilft dabei, Server zu identifizieren, die keine Verschlüsselung unterstützen. Wenn Sie sensible E-Mails an eine Domain senden, die STARTTLS nicht unterstützt, reist diese E-Mail im Klartext.
STARTTLS in der Praxis
Die meisten modernen E-Mail-Infrastrukturen unterstützen STARTTLS, aber die Implementierungsqualität variiert.
Große E-Mail-Anbieter (Gmail, Microsoft, Yahoo) unterstützen STARTTLS und nutzen es für den Großteil ihres E-Mail-Verkehrs. Google veröffentlicht Transparenzberichte, die zeigen, welcher Prozentsatz der E-Mails von und zu Gmail Verschlüsselung nutzt – meist über 90 % des Verkehrs.
Unternehmens-Mailserver unterscheiden sich stark. Gut gepflegte Exchange- und Google-Workspace-Installationen unterstützen STARTTLS. Ältere oder schlecht gewartete Server möglicherweise nicht. Beim Versand an Unternehmensdomänen ist Verschlüsselung nicht garantiert.
Selbstgehostete Mailserver sollten stets STARTTLS aktivieren. Die Konfiguration ist in moderner MTA-Software unkompliziert. Es gibt keinen guten Grund, 2024 einen unverschlüsselten Mailserver zu betreiben.
E-Mail-Dienste (SendGrid, Mailgun usw.) unterstützen STARTTLS sowohl für eingehende als auch ausgehende Verbindungen. Wenn Sie über diese Dienste senden, verwenden sie Verschlüsselung, sofern das Ziel sie unterstützt.
Über STARTTLS hinaus
STARTTLS bietet eine Transportverschlüsselung, ist jedoch keine Ende-zu-Ende-Verschlüsselung. Die E-Mail wird auf jedem Server entlang des Pfads entschlüsselt. Wenn Sie echte Ende-zu-Ende-Verschlüsselung benötigen – bei der nur Absender und Empfänger die Nachricht lesen können –, brauchen Sie S/MIME oder PGP.
Für stärkere Transportsicherheit adressieren MTA-STS und DANE die Schwächen von STARTTLS. MTA-STS veröffentlicht eine Richtlinie, die Verschlüsselung verlangt und gültige Zertifikate festlegt. DANE verwendet DNSSEC zur Authentifizierung von Zertifikaten. Beide verhindern die Downgrade-Angriffe, die STARTTLS allein nicht stoppen kann.
Das E-Mail-Ökosystem bewegt sich schrittweise in Richtung verpflichtender Verschlüsselung. Google und Microsoft bestrafen unverschlüsselte Verbindungen zunehmend in ihrer Spam-Bewertung. Zukünftige Standards könnten Verschlüsselung verlangen, statt sie optional zu machen.
Frequently asked questions
Verschlüsselt STARTTLS meine E-Mail Ende-zu-Ende?
Nein. STARTTLS verschlüsselt E-Mails auf dem Transportweg zwischen Servern, aber die E-Mail wird auf jedem Server entschlüsselt. Serveradministratoren und alle mit Serverzugriff können den Inhalt lesen. Für Ende-zu-Ende-Verschlüsselung verwenden Sie S/MIME oder PGP.
Ist STARTTLS dasselbe wie TLS?
STARTTLS ist ein Befehl, der auf einer bestehenden Verbindung TLS-Verschlüsselung initiiert. TLS ist das Verschlüsselungsprotokoll selbst. STARTTLS ist der Mechanismus; TLS ist das, was er aktiviert.
Warum werden einige E-Mails trotzdem unverschlüsselt übertragen?
STARTTLS ist optional. Wenn der empfangende Server es nicht unterstützt oder wenn ein Man-in-the-Middle die Fähigkeit herausfiltert, fällt die E-Mail auf Klartext zurück. MTA-STS und DANE helfen, dies zu verhindern, doch die Verbreitung ist nicht universell.
Sollte ich für alle E-Mails STARTTLS verlangen?
Beim Senden können Sie Verschlüsselung bevorzugen, müssen aber eventuell einen Fallback zulassen für Server, die sie nicht unterstützen. Beim Empfangen kann das Erzwingen von STARTTLS legitime E-Mails von schlecht konfigurierten Absendern ablehnen. MTA-STS ermöglicht es, Verschlüsselung mit mehr Nuancen zu verlangen.