Bei der E-Mail-Verschl\u00fcsselung bewegt sich etwas: Die IETF hat mit MTA-STS einen Standard zum Absichern von Verbindungen zwischen Mailservern per TLS und Zertifikaten geschaffen. Damit wird ein aktiver Schutz vor „Man-in-the-Middle-Angriffen“ gew\u00e4hrleistet.<\/p>\n
Schon heute lassen sich Verbindungen zwischen Mailservern mit STARTTLS verschl\u00fcsseln. Jedoch hat dieses Verfahren diverse Probleme. STARTTLS ist optional. Mittels Man-in-the-Middle-Attacke l\u00e4sst sich recht leicht verhindern, dass die verschl\u00fcsselte Verbindung aufgebaut wird. Es muss daf\u00fcr lediglich der STARTTLS-Befehl aus der Verbindung gefiltert werden.<\/p>\n
Hinzu kommt, dass Zertifikate bei Verbindungen via E-Mail nicht \u00fcberpr\u00fcft werden. Oftmals verwenden Mailhoster eigens signierte, abgelaufene oder sonstig ung\u00fcltige Zertifikate. Es w\u00fcrde nicht viel bewirken, die Zertifikate zu \u00fcberpr\u00fcfen. Mailserver laufen h\u00e4ufig auf einem anderen Host. Dieser wird per DS und einem MX-Record signalisiert. Angreifer k\u00f6nnen die E-Mails einfach auf einen eigenen Server umleiten, um dort ein g\u00fcltiges Zertifikat vorzuzeigen.<\/p>\n
STARTTLS verhindert also das Mitlauschen von Nachrichten, jedoch keine Man-in-the-Middle-Angriffe. In aller Regel finden Verbindungen zwischen Usern und Servern mittlerweile verschl\u00fcsselt statt. Oft \u00fcber TLS-gesicherte Varianten von POP3, IMAP sowie SMTP oder aber \u00fcber HTTPS-Interfaces. Nach wie vor sind jedoch die Verbindungen zwischen den Servern weitgehend ungesch\u00fctzt. Genau das soll sich mit MTA-STS \u00e4ndern.<\/p>\n
Mailserver-Betreiber definieren eine Policy, die per HTTPS publiziert wird. MTA-STS bringt HSTS und HTTPS auf die Mail-Server.<\/p>\n
Zum Auslesen von E-Mails haben sich f\u00fcr Cyberkriminelle drei sehr h\u00e4ufige Man-in-the-Middle-Angriffe bew\u00e4hrt:
\n\u2022 DNS-Spoofing: Angreifer k\u00f6nnen die DNS-Antworten des Absender-Servers derart ver\u00e4ndern, dass Nutzer nicht ans richtige Ziel gelangen. Sie sprechen mit einem anderen Server und die E-Mails werden dort abgelegt. Sogar STARTTLS k\u00f6nnte der Server anbieten. Auf dem Server l\u00e4ge die unverschl\u00fcsselte E-Mail, sie kann mitgelesen und weitergeleitet werden.
\n\u2022 STARTTLS unterdr\u00fccken: Kann ein System auf die Verbindung zugreifen, kann die Antwort auf eine EHLO-Anfrage derart ver\u00e4ndert werden, dass der Absender gar nicht erf\u00e4hrt, dass die Gegenseite STARTTLS unterst\u00fctzt. Die E-Mail wird dann unverschl\u00fcsselt gesendet.
\n\u2022 Falsches Zertifikat: Mailserver nutzen in aller Regel STARTTLS, vers\u00e4umen es jedoch, das Zertifikat zu verifizieren. Oftmals besitzen Server nicht mal ein „\u00f6ffentliches“ Zertifikat, und wenn doch, so muss es nicht mit dem Mailserver-Namen \u00fcbereinstimmen.<\/p>\n
Die E-Mail hinkt \u2013 verglichen mit anderen Kommunikationskan\u00e4len \u2013 schon lang in Sachen Verschl\u00fcsselung hinterher. Zwar ist eine Ende-zu-Ende-Verschl\u00fcsselung m\u00f6glich, wird jedoch leider kaum genutzt. MTA-STS soll eine praktikable M\u00f6glichkeit bieten, den Transportweg zwischen Mailservern zu sichern.<\/p>\n
Standardisiert wurde der RFC 8461 zu SMTP Mail Transfer Agent Strict Transport Security \u2013 kurz MTA-STS \u2013 von der IETF. Beteiligt an der Entwicklung waren jedoch auch die gro\u00dfen Mailserver-Betreiber, unter anderem Google, Microsoft oder Oath. Ein Mailserver signalisiert mit MTA-STS, dass TLS-gesicherte Verbindungen unterst\u00fctzt werden. Der anfragende Mailserver wird angewiesen, k\u00fcnftig ausschlie\u00dflich verschl\u00fcsselte Verbindungen zu akzeptieren. \u00dcber DNS und HTTPS werden die STS-Informationen bereitgestellt.<\/p>\n
Mailserver-Betreiber definieren eine Policy, die via HTTPS publiziert wird. Der Betreiber legt zun\u00e4chst im DNS-Server einen TXT-Record an. Dieser signalisiert, dass eine Policy vorhanden ist. Unter der Subdomain „mta-sts“ wird die eigentliche Policy dann \u00fcber HTTPS publiziert. So ist gew\u00e4hrleistet, dass diese Policy ausschlie\u00dflich von einem Inhaber eines g\u00fcltigen Zertifikats publiziert wurde. Analog zum DNS-Record gibt man eine Version an. Au\u00dferdem einen „mode“, in dem „enforce“, „testing“ oder „none“ angegeben werden kann.<\/p>\n
Um vor Angriffen und unberechtigten Verbindungen gesch\u00fctzt zu sein, muss der „enforce“-Modus aktiviert werden. Im „testing“-Modus soll ein Fehlerreporting realisiert werden, jedoch ist diese Funktion optional und es bleibt noch abzuwarten, ob dieser Modus in der Praxis \u00fcberhaupt implementiert wird.<\/p>\n
Die Angabe „mx“ erlaubt das Eintragen aller g\u00fcltigen Mailserver. Die Angaben stimmen idealerweise mit den MX-Records im DNS-Server \u00fcberein. Mit „max_age“ wird zu guter Letzt angegeben, wie lange die Policy gilt. Man gibt diese G\u00fcltigkeit in Sekunden an; 1209600 w\u00e4ren etwa zwei Wochen. Je l\u00e4nger die G\u00fcltigkeit, umso sicherer ist das Verfahren. So kann die Policy f\u00fcr example.org unter https:\/\/mta-sts.example.org\/.well-known\/mta-sts.txt beispielsweise aussehen:<\/p>\n
version: STSv1
\nmode: enforce
\nmx: mail1.example.org
\nmx: mail2.example.org
\nmax_age: 1209600<\/p>\n