MTA-STS: Konkretisierung der Kritik
Gestern erreichten mich zum ersten Punkt (HTTP-Client) von Stefans Kritik zu MTA-STS folgende Frage(n):
Wo wird denn bei MTA-STS ein HTTP-Client benötigt und weshalb ist das dann ein Sicherheitsrisiko bzw. wie kann da konrekt eine Sicherheitslücke ausgenutzt werden?
Die Antwort auf diese Frage ist etwas länger. Zunächst einmal zur Frage:
Wo wird bei MTA-STS ein HTTP-Client benötigt?
Domain A möchte, dass MTA-STS von anderen E-Mail-Servern für die eigene Domain angewendet wird. Dazu genügt es einen txt-Record _txt.domainA.com der Form »v=STSv1\; id=9823774\;« anzulegen und die eigene Richtlinie als Datei mit bspw. folgendem Inhalt:
version: STSv1 mode: enforce mx: mx1.domainA.com max_age: 2419200
auf einem Webserver abzulegen.
Das ist allerdings nur die halbe Miete und das ist, was bisher der überwiegende Teil der Provider macht: Die MTA-STS »aktivieren«. Das bringt natürlich gar nichts, wenn keiner die Richtlinien anwendet. Was noch fehlt, ist ein HTTP-Client.
Domain A möchte jetzt auch die Richtlinien von anderen E-Mail-Servern bzw. Domains anwenden. Dazu muss für jede zu versendende E-Mail geprüft werden, ob für die angebotenen MX-Server der Zieldomain schon eine Richtlinie im Cache liegt und ob sie noch gültig ist, wenn nicht, muss geprüft werden, ob eine angeboten wird. Diese muss dann (ggf. asynchron) vom Policy-Webserver der Zieldomain »heruntergeladen« (HTTP-Client/Library), ausgewertet, gespeichert und angewendet werden.
Das bringt uns zur zweiten Frage:
Weshalb ist das dann ein Sicherheitsrisiko bzw. wie kann da konrekt eine Sicherheitslücke ausgenutzt werden?
Pauschal: Weil jede zusätzliche Software ein zusätzliches Sicherheitsrisiko mit sich bringt.
Etwas konkreter: Im einfachsten Fall kommt jemand auf die Idee und legt eine »große« Policy-Datei innerhalb seiner bösen Domain ab. Diese wird domainA herunterladen und mit dieser »großen« Datei muss der Policy-Server erst einmal umzugehen wissen.
Ja, im RFC steht, dass man Download-Zeit und Größe möglicherweise beschränken möchte, das muss der HTTP-Client allerdings auch hergeben und es zeigt, dass sich die Ersteller des RFCs dieser Problematik, die nur durch zusätzliche Maßnahmen eingeschränkt werden kann, bewusst sind. Das gefällt demjenigen vielleicht so gut, da macht er das doch glatt noch mit dutzenden anderen seiner bösen Domains…
Im schlimmsten Fall nutzt jemand eine Schwachstelle im HTTP-Client oder im Policy-Parser (der im einfachsten Fall eben auf dem E-Mail-Server läuft) mit einer entsprechend präparierten »Policy-Datei« aus. Dass die Firewall den (E-Mail-)Server jetzt auch per 443 nach außen lassen muss, macht es nicht besser.
Wietse Venema (postfix) bezeichnet diesen Ansatz als einen guten »Start« für einen Policy-Server. Dieser hat schon jetzt, obwohl er bei weitem nicht komplett ist, mehrere hundert Zeilen Code. Dazu kommen die benötigen Bibliotheken wie AIOHTTP (Asynchronous HTTP Client/Server) der allein schon mehren, tausend Zeilen Code hat. Das ist natürlich nicht automatisch unsicher, mehr Code macht mögliche Fehler aber wahrscheinlicher und es zeigt, wie aufwendig es ist, einen Policy-Server zu implementieren.
Fazit: MTA-STS ist, korrekt und vollständig umgesetzt, relativ komplex und erhöht nach unserer Auffassung die potenzielle Angriffsfläche auf einem E-Mail-Server.
Kritik an MTA-STS: Inkonsequent und zu komplex
MTA-STS: Prüfen ob dein E-Mail-Provider die Technik bereits unterstützt
Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten
mailbox.org: Verlässlich und vertrauenswürdig – E-Mails unter Kontrolle Teil2
