IETF-Tagung: Neue Vorschläge zum Sichern des Mailtransports
Mailserver hinken sicherheitsmäßig immer noch hinter Webservern her, wie ein TLS-Check der IHK Stuttgart jüngst verdeutlichte. Mailprovider haben sich nun zusammengetan, um bei der IETF mit "Strict Transport Security" voranzukommen.
Viele große Mailprovider nutzen Transport Layer Security (TLS), um die Postwege im Netz abzusichern. Zu oft aber bleibt die Verschlüsselung per STARTTLS auf der Strecke: Mit einer Downgrade-Attacke kann ein Bösewicht die Server dazu bringen, auf die TLS-Sicherung zu verzichten. Ein diese Woche auf dem 95. Treffen der Internet Engineering Task Force (IETF) in Buenos Aires vorgestellter Vorschlag soll Abhilfe schaffen – zumindest teilweise.
Google, Yahoo, Comcast, Microsoft, LinkedIn und 1&1 haben sich zusammengetan, um die Absicherung per TLS ein bisschen weniger "opportunistisch" zu machen. Opportunistic Encryption, der einseitig gestartete Einsatz von Transportverschlüsselung, war eine der unmittelbaren Reaktionen auf die Enthüllungen Edward Snowdens. Die großen Mailprovider wollen mit einer Ergänzung für SMTP namens Strict Transport Security (STS) nun einen Schritt weitergehen.
Indem Mailserver ihre Policies veröffentlichen, kann der ausliefernde Server prüfen, ob der Empfänger TLS unterstützt. Damit ließen sich auf dem Weg eingeschleuste Fehlinformationen über den Status verhindern. Downgrade-Attacken ließen sich wenn schon nicht verhindern, dann zumindest aufdecken. Für manche Provider sei bereits das schlichte Reporting ein erster Schritt zu mehr Transparenz, sagte Mark Risher von Google. Die Mailserver-Policy könnte als neuer Resource Record oder schlichtes Textfile im DNS hinterlegt werden.
Konkurrenz zu DANE
Das neue Konzept steht im Wettbewerb zu mittels DANE abgesichertem Mailtransport. Risher unterstrich, der direkte Einsatz von DANE scheitere eben an der fehlenden Verbreitung von DNSSEC. Warten, bis DNSSEC sich weiter durchgesetzt hat, wollen die Provider aber nicht. Auch die für SMTP STS geplante Reporting-Funktion sei den Mailprovidern sehr willkommen, meinte Risher: "Manchen reicht allein das als erster Schritt aus."
Doch SMTP STS hat auch einen Haken: Um die im DNS hinterlegte Mailserver-Policy abzusichern, schlagen die Mailprovider nämlich doch wieder DNSSEC als Sicherheitsfeature vor. Von der Verquickung mit DANE rieten Experten in Buenos Aires ab. "Entweder glaubt man an DANE und dann macht man es, oder nicht" sagte der Chef des Internet Architecture Board, Andrew Sullivan. Dem DNS "ein bisschen zu glauben" sei unsinnig.
Als Alternative wird erwogen, die Mailserver-Policy per WebPKI zu authentifizieren. In beiden Welten parallel die Policy vorzuhalten, sorge letztlich nur für Verwirrung, vor allem bei Inkonsistenzen. Man sollte SMTP STS und SMTP mit DANE grundsätzlich nicht mischen, sagten mehrere Experten. Auch die Reporting-Funktion solle nicht direkt auf SMTP STS drauf gepackt, sondern gesondert standardisiert werden.
Mehr Transparenz für Nutzer
Eine andere Empfehlung will den Nutzern einen Leitfaden für die eigene Sicherheit an die Hand geben: Mail User Agent Strict Transport Security (MUA STS, vormals DEEP) soll dem Nutzer anzeigen, ob der Weg zwischen dem eigenen Rechner und dem Mailserver TLS-gesichert ist. Icons oder ein Farbschema stellen dann dar, wie es beim Abholen der Mail oder beim Senden an den Mailprovider um die Vertraulichkeit steht.
Standardmäßig soll beim Einrichten der Box die höchste Sicherheitsstufe vorgewählt sein. Der Nutzer muss sie bewusst herabsetzen, wenn er das nicht will. Bevorzugtes Protokoll soll übrigens nicht STARTTLS, sondern Implicit TLS sein, erklärte in Buenos Aires einer der Autoren, der Oracle-Ingenieur Chris Newman. Anders als STARTTLS erlaubt Implicit TLS das Aushandeln einer TLS-Verbindung bereits im ersten Verbindungsaufbau durch Signalisierung über einen anderen Port.
Wenn für die Mailbox die Vorgabe "vertraulich" eingestellt ist, muss der MUA die Verbindung zur Mailbox kappen, wenn keine TLS-Verbindung zustande kommt. Ein Nutzer-Click nach dem Motto "Bitte doch verbinden" oder "Ausnahme hinzufügen" darf es dann auf keinen Fall geben, heißt es in dem Dokument. Akzeptabel sind laut der Spezifikation allenfalls die Rückmeldungen "Work offline", "Später nochmals versuchen" oder "Status Page des Providers aufrufen". Nur wenn der Nutzer die Vertraulichkeitsstufe für seinen Account in der Konfiguration explizit ändert, kann auf TLS verzichtet werden.
Weniger opportunistisch vor, ein bisschen mehr hinter dem Server
Die beiden STS-Vorschläge können sich laut Newman praktisch ergänzen. Wie unterschiedliche Policies auf beiden Seiten zusammenwirken, also vor und hinter dem Mailserver des Providers, ist noch zu klären. Etwas paradox mutet an, wenn der Nutzer TLS auf dem Weg zur Mailbox erzwingt, der Maildienstleister beim weiteren Versand dann aber Klartext zulässt, wenn die TLS-Aushandlung scheitert. Abhilfe könnte ein dritter Vorschlag bringen, der Nutzern erlauben soll, Mail mit der Anweisung "nur über TLS" zu versehen. Damit würde beim Klartext-Downgrade erzwungen, dass die Mail verworfen wird.
Wer wirklich auf Sicherheit bedacht ist, werde doch eher auf Ende-zu-Ende-Verschlüsselung setzen, kritisierten viele Security-Experten. Die Idee wurde zurückgestellt, weil SMTP STS und MUA STS schnell verabschiedet werden sollen. Ob das STS-Konzept am Ende an DANE vorbeizieht? Angesichts der Liste von Organisationen, die zu den Autoren gehören, scheint das möglich. (ea)
