Transportverschlüsselung von E-Mails für den Anwender nutzbar machen

Geschrieben am 30. Dezember 2015

In den letzten Tagen bin ich endlich dazu gekommen, eine Idee umzusetzen, die ich bereits vor geraumer Zeit hatte: Transportverschlüsselung von E-Mails für alle Empfängerdomains zu aktivieren, dabei aber den Anwendern eine Möglichkeit an die Hand zu geben, einzelne E-Mails auch unverschlüsselt zuzustellen, wenn der Empfänger kein TLS unterstützt.

Doch ich beginne am Anfang: Worin besteht das Problem?

Verbreitung der Technologien zur Verschlüsselung von E-Mails

Die E-Mail ist immernoch das zentrale Kommunikationsmedium im Unternehmensumfeld. Doch leider konnten sich Verschlüsselungtechnologien für E-Mails wie S/MIME oder OpenPGP in der Praxis bisher kaum durchsetzen. Die Gründe hierfür möchte ich an dieser Stelle nicht weiter diskutieren. Es bleibt nur festzustellen, dass in der Praxis nur ein Bruchteil der E-Mails S/MIME- oder OpenPGP-verschlüsselt wird. Und das trotz der Erkenntnisse, die uns Edward Snowden beschert hat.

Positiv ist hingegen, dass Transportverschlüsselung (Transport Layer Security, TLS) mittlerweile von ca. 90 Prozent der Mailserver unterstützt wird! Hierbei wird nicht die E-Mail als solche verschlüsselt, sondern die Übertragung der E-Mail erfolgt über eine verschlüsselte Verbindung. Wichtiger Vorteil gegenüber den oben genannten Varianten: es werden auch die Meta-Daten der E-Mail wie Absender, Empfänger, Datum und Betreff (!) verschlüsselt! Angesichts einer derart hohen Verbreitung dieser Variante der Verschlüsselung lohnt es sich, sich hiermit näher auseinander zu setzen.

Auf die weiteren Unterschiede zwischen den Technologien (S/MIME, OpenPGP, TLS) kann an dieser Stelle nicht weiter eingegangen werden. Insbesondere der Aspekt Ende-zu-Ende-Verschlüsselung vs. Transportverschlüsselung ist wichtig; ich verweise insofern nur auf die Wikipedia. Von meiner Seite sei nur angedeutet, dass gerade dieser Unterschied in der Praxis an Relevanz verliert, da es für S/MIME und OpenPGP verschiedene Gatewaylösungen gibt und der Absender nicht wissen kann, welche Technologien auf der Seite des Empfängers zum Einsatz kommen. Auch hier ist die Welt nicht schwarz-weiß. Doch zurück zum Thema dieses Beitrags.

Transport Layer Security (TLS)

Der Teufel steckt wie so häufig auch bei der Transportverschlüsselung im Detail. In der Grundeinstellung arbeiten die Mailserver im sog. „opportunistischen“ TLS-Modus. Das bedeutet, dass ein Mailserver zunächst versucht, jede E-Mail transportverschlüsselt an den Mailserver des Emfängers zuzustellen. Wenn es funktioniert, wunderbar, wenn es aber nicht funktioniert, beispielsweise weil der Empfängerserver TLS gar nicht unterstützt, wird die E-Mail unterschlüsselt zugestellt.

Nun ist diese Vorgehensweise einerseits eine praktische Sache. Denn sie sorgt ja dafür, dass ein großer Anteil der E-Mails transportverschlüsselt übertragen wird. Auf der anderen Seite bringt diese Form der Übertragung dem Absender einer vertraulichen E-Mail im konkreten Fall recht wenig. Schließlich muss er in dem Moment, da er auf „senden“ klickt, sicher sein können, dass seine E-Mail verschlüsselt übertragen wird. Gerade das ist aber im „opportunistischen Modus“ nicht möglich.

Mandatory TLS für einzelne Domains

Bisher habe ich dies dadurch gelöst, dass ich eine Liste von Domains geführt habe, deren Mailserver TLS unterstützen. Für diese Domains habe ich dann Transportverschlüsselung auf dem Mailserver verpflichtend gemacht, sprich, E-Mails werden an diese Domains nur dann heraus geschickt, wenn eine verschlüsselte Verbindung zustande kommt. Schlägt der verschlüsselte Verbindungsaufbau aus irgendeinem Grund fehl, wird die E-Mail zurück gehalten. An alle anderen Domains werden E-Mails auch unverschlüsselt versendet, wenn keine TLS-Verbindung aufgebaut werden kann.

Allerdings hat dieser Ansatz zwei Schwächen:

  1. Der Absender muss selbst vor dem Versand einer E-Mail kontrollieren, ob für die Empfänger auf der E-Mail verpflichtendes TLS konfiguriert wurde. Diese Information kann beispielsweise im Customer Relationship System (CRM) hinterlegt sein. Gerade wenn sich mehrere Empfänger auf einer E-Mail befinden, ist das aber ein Schritt, der in der Praxis unter den Tisch fällt. Der Schwachpunkt liegt konkret darin, dass der E-Mail-Versand unsicher ist, bevor der Absender nicht aktiv wurde und sicher gestellt hat, dass die Empfänger zu den „sicheren Empfängern“ gehören. Es handelt sich also um eine „unsichere Grundeinstellung“. Erst wenn der Absender aktiv etwas tut, wird es „sicher“.
  2. Wenn eine E-Mail vom Server zurück gehalten wird, da ein Empfängerserver auf einmal kein TLS mehr unterstützt, bekommt dies zunächst der Absender nicht mit. Statt dessen muss sich der Postmaster kümmern. Doch kann er zunächst nicht wissen, ob dies ein Fall ist, in dem die E-Mail auch problemlos unverschlüsselt versendet werden kann oder ob es sich um vertrauliche Informationen handelt, die keinesfalls unverschlüsselt versendet werden dürfen. Daher muss der Postmaster sich an den Absender wenden und mit ihm besprechen, wie mit der E-Mail verfahren werden soll. Dieses Procedere bindet viele Ressourcen und ist im Alltag sehr umständlich. Dieser Fall mag unwahrscheinlich erscheinen. Doch hatte ich schon einige Fälle, in denen ein Mailserver entweder vom einen auf den anderen Tag auf einmal kein TLS mehr unterstützte oder aber der primäre Mailserver des Empfängers war ausgefallen, so dass ein sekundärer Mailserver einsprang; dieser unterstützte aber leider kein TLS. Diese Fälle kommen also tatsächlich in der Praxis vor.

Die bessere Lösung: sichere Grundeinstellung

An dieser Stelle habe ich nun mit meinen Überlegungen angesetzt. Wie sähe eine optimale Lösung aus? Für mich wäre folgendes ideal:

  • Der Mailserver stellt für alle Empfängerdomains sicher, dass E-Mails ausschließlich verschlüsselt übertragen werden (sichere Grundeinstellung). Bei ca. 90 Prozent der Empfängerdomains würde dies problemlos funktionieren. Mails an ca. 10 Prozent der Empfängerdomains würden vom Server zurück gehalten, da das Gegenüber kein TLS unterstützt.
  • Wird eine E-Mail wegen fehlender TLS-Unterstützung des Gegenüber zurück gehalten, wird der Absender der E-Mail (nicht der Postmaster) darüber per E-Mail unmittelbar informiert. In der Benachrichtigungsmail kann der Absender selbst nun entscheiden, wie mit der konkreten E-Mail weiter verfahren werden soll. Er hat zwei Buttons, auf die er klicken kann: „E-Mail unsicher senden“ oder „E-Mail löschen“.

Diese Lösung umgeht die oben stehenden Probleme und reduziert sogar weiter den Administrationsaufwand, da keine Liste von Domains mehr geführt werden muss, die TLS unterstützen. Vor allem kann ein Absender beim Klicken auf „senden“ nun davon ausgehen, dass seine E-Mail sicher übertragen wird (sichere Grundeinstellung). Er muss nicht erst auf einer Liste nachsehen, also nichts mehr aktiv tun, um sichere E-Mails zu senden, wie es vorher der Fall war; er muss nun etwas tun, um unsichere E-Mails zu senden!

Dies bedeutet einerseits eine Vereinfachung des Arbeitsablaufs für den Anwender, da er sich beim Versand einer E-Mail nun keine Gedanken mehr machen muss, ob seine E-Mail sicher übertragen wird; er kann einfach davon ausgehen. Wenn die sichere Übertragung fehl schlägt, wird er vom System „angesprochen“ und muss sich nur in diesen Fällen überhaupt mit dem Thema befassen.

Andererseits gewinnt auch das Sicherheitsniveau. Denn der Anwender wird durch die Implementierung gezwungen, eine bewusste Entscheidung für den unsicheren Versand zu treffen – und zwar für jede einzelne E-Mail, die unsicher übertragen werden soll. Es ist technisch sicher gestellt, dass der unsichere Versand von E-Mails nicht ignoriert bzw. unreflektiert in Kauf genommen wird. Da nun häufiger eine Bestätigung vom Anwender verlangt wird, dürfte dies auch eine eindrucksvollere psychologische Wirkung haben als der eingangs skizzierte Ansatz. Das Thema E-Mail-Verschlüsselung wird dadurch mehr ins Bewusstsein der Anwender gerückt.

Auf der Negativseite mag stehen, dass der Absender nun nicht mehr zwingend alles für den Versand seiner E-Mail getan hat, wenn er auf „senden” geklickt hat. Denn es kann ja sein, dass die E-Mail wegen fehlender TLS-Unterstützung der Gegenseite zurück gehalten wird. Gerade bei E-Mails, bei denen es wichtig ist, dass sie zeitnah versandt werden, muss der Absender also nach dem Versand seiner E-Mail nochmals in sein Postfach schauen, ob die E-Mail möglicherweise zurück gehalten wurde und er noch tätig werden muss. Dieser Nachteil scheint mir aber gegenüber den oben genannten Vorteilen gering; zumal das Medium E-Mail nicht für die Echtzeitkommunikation gedacht ist und es immer mal vorkommen kann, dass eine E-Mail länger für die Übertragung zum Empfänger benötigt.

Implementierung

Diese Lösung habe ich in den letzten Tagen in Form einer Python-Anwendung implementiert. Kann eine E-Mail nun nicht transportverschlüsselt zugestellt werden, erhält der Absender eine E-Mail nach folgendem Muster:

Wenn der Absender auf einen der Buttos klickt, wird eine Webseite im lokalen Netzwerk aufgerufen und die jeweilige Aktion ausgeführt.

Der unverschlüsselte Versand der Nachricht wird technisch dadurch realisiert, dass die E-Mail umgeleitet wird auf einen zweiten Mailserver, der so konfiguriert wurde, dass er E-Mails auch unverschlüsselt zustellt, wenn das Gegenüber kein TLS unterstützt.

Die technischen Details meiner Lösung erläutere ich gerne auf Nachfrage. Sprechen Sie mich gerne an, wenn Sie über das Thema diskutieren möchten – oder andere Ideen oder Erfahrungen haben. Ich bin an einem Austausch zu diesem Thema sehr interessiert.