SMTP: Schlechtere Verschlüsselung kann besser sein

In einer perfekten Welt würden nach Bekanntwerden einer Sicherheitslücke alle Server innerhalb weniger Stunden gepatched werden. Neue Verschlüsselungsalgorithmen wären nach wenigen Wochen überall verfügbar und Änderungen an unterstützender Infrastruktur wie z.B. die Implementierung von DANE wären in ein paar Monaten durch. Und dann wacht man auf und stellt fest, dass die Welt leider alles andere als perfekt ist. Und so muss ich nun leider, schweren Herzens und verschämt, eine Aussage invalidieren, die ich in diesem Blog-Eintrag getroffen habe. Damals war ich der Meinung, dass es eine gute Idee sei, auf einem Mailserver - bzw. genauer, auf einem Public MX - die Liste der Verschlüsselungsprotokolle und Ciphers einzuschränken, die unterstützt werden. Ich wähnte mich da damals auf der sicheren Seite, wenn selbst Leute wie Jacob Appelbaum Konfigurationen veröffentlichen, die genau das tun. Aber wenn man darüber nachdenkt, dann ist das eigentlich eine schlechte Idee.

Halten wir uns vor Augen, wie der Versand einer Mail in einfachsten Fall funktioniert: Ein Mailserver, der eine Mail ausliefern will, macht einen MX-Lookup auf die Zieldomain, kontaktiert einen der eingetragenen MX-Hosts und liefert dort die Mail ab. Verschlüsselung auf SMTP-Ebene wird dabei durch die STARTTLS-Erweiterung implementiert. Bietet der Ziel-MX diese Erweiterung nicht an, oder kann kein Crypto-Handshake durchgeführt werden, dann wird der einliefernde Mailserver die Mail einfach unverschlüsselt ausliefern. Seiner Natur nach ist STARTTLS also opportunistisch (man spricht oft auch von opportunistic encryption) - wenn es funktioniert, toll, wenn nicht, dann wird einfach unverschlüsselt weitergemacht. Und genau das ist das Problem: Wenn ich meinen Mailserver so konfiguriere, dass nur sehr starke, moderne, “sichere” Verschlüsselungsarten unterstützt werden, dann werden viele ältere Systeme nicht in der Lage sein, einen SSL/TLS-Handshake durchzuführen. Und dann geht die Mail vollkommen unverschlüsselt über die Leitung. Jetzt könnte man natürlich seinen MX so konfigurieren, dass er gar keine Mails mehr ohne STARTTLS annimmt - aber dann kann man es sich auch gleich sparen, überhaupt einen Mailserver zu betreiben. Und das behaupte ich nicht nur, dazu gibt es auch Zahlen: Sowohl Google als aus auch Facebook (Achtung: Facebook-Account erforderlich) haben vor kurzem ihre Statistiken bzgl. STARTTLS öffentlich verfügbar gemacht.

Jetzt gibt es ja Seiten wie z.B. STARTTLS.info, und da wird man punktemäßig “abgewatscht”, wenn man alte Protokolle unterstützt, schwache oder anonyme Ciphers anbietet oder Zertifikate nutzt, die nicht von einer der großen CAs unterschrieben wurden. Mittlerweile bin ich der Meinung, dass die Jungs da falsch liegen.

  • Wenn ein einliefernder Mailserver ein Zertifikat nicht verifizieren kann, dann ist er anfällig(er) gegen eine MITM-Attacke. Soweit, so gut. Aber was ist die Alternative in dem Fall? Ist es wirklich besser, die Mail dann unverschlüsselt zu übertragen? Oder gar die Einlieferung komplett abzubrechen? Wohl kaum. Mailversand über einen öffentlichen MX wird immer (naja, fast, siehe unten) gegen MITM anfällig sein. Warum also sollte man die Zertifikate verifizieren? Und wenn man die Zertifikate nicht verifiziert, warum sollte man dann welche nehmen, die von einer der großen CAs unterschrieben wurden?
  • Aus dem gleichen Grund ist es wenig sinnvoll, anonyme Cipher nicht zuzulassen. Wenn man sich sowieso schon nicht gegen MITM absichern kann, warum sollte man sich denn dann überhaupt die Mühe machen, die Gegenstelle dazu zu bewegen, ein Zertifikat vorzulegen?
  • Ohne DNSSEC habe ich sowieso nie die Sicherheit, überhaupt mit dem richtigen MX zu sprechen und bin somit immer gegen MITM-Attacken anfällig.
  • Im Zuge des SSL/TLS-Handshakes einigen sich beide Seiten auf ein Set aus Protokollen und Ciphers. Normalerweise präsentiert dabei der Server die Liste der von ihm untertstützten Verschlüsselungseinstellungen und der Client wählt dann das von ihm bevorzugte Set aus. Daraus folgt, dass moderne Software (z.B. eben Postfix) sich ohne jegliche Einstellungen auf eine starke Verschlüsselung einigen wird (meine Debian-Postfixe z.B. einigen sich immer auf ECDHE-RSA-AES256-GCM-SHA384, was wenig Wünsche offen lässt). Wenn eine “suboptimale” Wahl statt findet, dann ist es die Aufgabe des Senders, dies anzupassen - und nicht die des Empfängers. Spiele ich hier an Parametern, dann riskiere ich nur, dass die Mail im Klartext übertragen wird.
  • Tansportwegverschlüsselung - und mehr ist STARTTLS nicht - ist keine End-to-End-Verschlüsselung.

Natürlich gibt es ein paar Ausnahmen, bei denen es Sinn machen kann, sich mehr Gedanken über Verschlüsselung zu machen und nicht nur zu sagen “irgendeine Verschlüsselung ist besser als gar keine”. Im wesentlichen ist dies zum einen, wenn man, z.B. weil Geschäftsbeziehungen bestehen, mit den Postmastern der Gegenstelle eine Vereinbarung über die einzusetzenden Krypto-Algorithmen treffen kann. Dann kann man (in Postfix z.B. über TLS Policy Maps) die ganze Bandbreite an Möglichkeiten ausschöpfen, von der Wahl der Zertifikate über die Protokolle und Ciphers bis hin zum Unterdrücken von unverschlüsselten Übertragungen. Ähnlich sieht es aus, wenn man keinen Public MX, sondern einen Mail Submission Agent (MSA) betreibt, der von Anwendern genutzt wird, um Mails via eMail-Programm einzuliefern. Da hier feststeht, welches der “richtige” Server ist, lohnen sich “vertrauenswürdige” (was auch immer das derzeit heissen will) Zertifikate und eine Feineinstellung der Verschlüsselungs-Algorithmen. Und nicht zuletzt erledigt sich zumindest das Thema “anonyme Ciphers”, wenn beide Seiten DANE (und damit DNSSEC) implementieren.

Ich habe leider keine perfekte Antwort darauf, wie wir auf SMTP bezogen Sicherheit und Privatsphäre am effektivsten schützen können - ich denke aber nicht, dass ein Tuning der TLS-Parameter auf einem öffentlichen MX uns weiter bringt. Im Gegenteil, jede Verschlüsselung ist, zumindest in meinen Augen, um ein vielfaches besser als gar nicht zu verschlüsseln. Langfristig hoffe ich, dass wir in den nächsten Jahren eine rasche und flächendeckende Unterstützung für DNSSEC und DANE sehen werden (da träume ich allerdings schon wieder) und somit sowohl das Skalierungs- als auch das CA-Problem lösen können. Und wenn es wirklich sicher sein soll hat man einfach keine andere Wahl, als bei einem Bier die PGP-Keys auszutauschen.