Kritik an MTA-STS: Inkonsequent und zu komplex
Der neue Standard MTA-STS soll dafür sorgen, dass die Transportverschlüsselung (TLS) zwischen den E-Mail-Servern durchgängig gewährleistet ist. Nach einer Rückfrage bei Stefan (Betreiber dismail.de), ob er MTA-STS schon anwende, schickte er mir seine persönliche Einschätzung zu MTA-STS:
- HTTP-Client: Es wird ein HTTP-Client benötigt, der ein Policy-File von beliebigen Webservern lädt und durch einen Parser schickt. Damit kann jeder (Angreifer) diejenigen E-Mail Provider, die MTA-STS umsetzen, dazu »zwingen« eine beliebige Datei von einem Webserver (des Angreifers) zu laden und zu verarbeiten. Bei kleinen / einfachen Installationen wird das auf dem E-Mail-Server selbst passieren, was je nach Konfiguration in einer Katastrophe enden kann. Das alleine sollte schon reichen, um MTA-STS nicht zu verwenden. Konrektisiert wird die Kritik am HTTP-Client in diesem Beitrag: MTA-STS: Konkretisierung der Kritik.
- Datenbank: Es wird eine Datenbank benötigt um die Policy, die Policy-ID und die Policy-Lifetime zu cachen.
- Fehlerbehandlung: MTA-STS im »enforce mode« darf keinen permanenten Fehler, sondern nur einen temporären Fehler auslösen -> E-Mail bleibt in der Queue. Der Anwender bekommt also erst spät die Information, dass etwas nicht stimmt.
- Policy-Updates: DNS-Einträge, Policy-File und Cache können »out of sync« sein, deshalb soll bei einem Update sichergestellt werden, dass zwei unterschiedliche Policies für einen gewissen Zeitraum (bis die TTL des DNS-Eintrages abgelaufen ist) angewendet werden. Die Kritik daran mag
kleinlich wirken, da es im RFC nur ein SHOULD ist. Auf mich wirkt das jedoch nicht zu Ende gedacht. - Verwirrend: Im RFC wird für den Parameter »max_age« empfohlen:
Well-behaved clients SHOULD cache a policy for up to this value from the last policy fetch time. To mitigate the risks of attacks at policy refresh time, it is expected that this value typically be in the range of weeks or greater.
Es wird also ein Wert von »weeks or greater« empfohlen. MTAs sollen ihren Cache allerdings »once per day« auffrischen – soll dabei auch »time-since-fetch« aktualisiert werden?
- Inkonsequent: Unter »5.1 Policy Application Control Flow« heißt es:
If none exists, attempt to fetch a new policy (perhaps asynchronously, so as not to block message delivery)
Heißt also, wenn keine Policy geladen werden kann ist auch PLAIN-Kommunikation erlaubt, bpsw. beim ersten Versenden oder bei einem Update.
Es gibt sicherlich noch mehr kritische Punkte. Insgesamt halte ich das Ganze für zu komplex. Da ist mir eine einfache Prefetch-Liste von einem vertrauenswürdigen Anbieter (STARTTLS Everywhere) wesentlich lieber.
Meine Einschätzung ist, dass der überwiegende Teil der E-Mail-Provider MTA-STS nicht vollständig einführen wird. Ein kleiner Teil wird ausschließlich eine »Testing-Policy« veröffentlichen, um Testergebnisse zu befriedigen, wie auch schon bei DMARC.
###
Danke Stefan für deine Eintschätzung zu MTA-STS. Nach meiner Auffassung hat Stefan diverse Schwächen von MTA-STS aufgezeigt, die einen sicheren und reibungslosen Betreib in der Praxis erschweren können. Letztendlich teile ich ebenfalls Stefans Einschätzung, dass die meisten E-Mail-Provider MTA-STS nicht vollständig einführen werden.
Mozilla Firefox: Datensendeverhalten Desktop-Version – Browser-Check Teil20
MTA-STS: Konkretisierung der Kritik
Google Chrome: Datensendeverhalten Desktop-Version – Browser-Check Teil21
Opera: Datensendeverhalten Desktop-Version – Browser-Check Teil13
