Verschlüsseln oder nicht- das ist hier keine Frage

Dass die Informations- und IT-Sicherheit in den letzten Jahren auch in Mainstream-Medien viel Beachtung findet, ist grundsätzlich gut. Steter Tropfen höhlt den Stein. Wer etwas ständig vor Augen hat, schärft seine Aufmerksamkeit für das Thema. Leider führt das auch zu einem unangenehmen Nebeneffekt: Getreu dem Grundsatz „Good news are no news“ erhalten schlechte Nachrichten überproportional viel Platz in analogen und digitalen Medien. So auch vor etwa zwei Wochen die eFail-Schwachstelle in Verschlüsselungs-Clients (CVE-2017-17688 und CVE-2017-17689). Durch eFail ist es für einen Angreifer unter bestimmten Umständen möglich, die verschlüsselte Botschaft im Klartext zu erhalten. Das ist natürlich berichtenswert, vor allem, weil eFail weitgehend unabhängig von E-Mail-Client und Verschlüsselungsstandard (PGP oder S/MIME) wirkt. Es ist sogar komplett unabhängig vom Verschlüsselungsalgorithmus, denn der wird gar nicht angegriffen.

Dreh- und Angelpunkt von eFail sind Versäumnisse in der Implementierung von Verschlüsselung im Mail-Client. Die Informationssicherheit kennt drei Schutzziele: Integrität, Vertraulichkeit und Verfügbarkeit. Verschlüsselung ist eine klassische Maßnahme, um Vertraulichkeit zu gewährleisten. Integrität hingegen wird nur als Nebeneffekt sichergestellt: Wenn jemand den verschlüsselten Text-Blob verändert, lässt er sich nicht mehr entschlüsseln und damit ist klar, dass die Integrität kompromittiert wurde. Doch was ist, wenn der Teil der Nachricht vor dem verschlüsselten Blob verändert wird? Genau das macht eFail. Zunächst wird die Nachricht über einen Man-in-the-middle-Angriff abgefangen und der Lead-In verändert. Sebastian Schinzel und sein Team, die den Angriff veröffentlich haben, konnten zahlreiche, so genannte Exfiltration Gadgets, in die Mail einsetzen. Das kann ein Stück HTML-Code mit dem Verweis auf ein Bild oder auf ein anderes Objekt sein. Im Endeffekt führt das dazu, dass der E-Mail Client den entschlüsselten Text an einen Host unter der Kontrolle des Angreifers schickt.

EFail funktioniert, weil die Integritätskontrolle des Clients versagt – Würde die komplette Mail auf Unverändertheit kontrolliert werden, könnte man keinen fremden Code einsetzen. Es fehlt – prinzipbedingt – sowohl bei S/MIME als auch bei OpenPGP eine verpflichtende Integritätssicherung. TLS nutzt so etwas übrigens schon lange, technisch ist das kein Problem. Es gibt auch schon Implementierungen wie Modification Detection Code (MDC) bei OpenPGP, doch nach wie vor nutzen Clients MDC nicht oder nicht konsequent. Nichtsdestotrotz lassen sich OpenPGP-basierte Clients mit recht wenig Mühe reparieren, S/MIME erfordert mehr Aufwand.

So weit zu den Fakten, doch darum geht es in diesem Blog-Post nicht primär. Dass E-Mail Clients verwundbar sind ist eine Sache, wie das kommuniziert und verbreitet wird, eine andere. Gerade bei eFail hagelte es nach der Veröffentlichung massive Kritik. Zu früh und zu unspezifisch soll die Bekanntmachung erfolgt sein. Tatsächlich enthielten viele Artikel zu Anfang den Ratschlag, die Plug-Ins abzuschalten oder nicht mehr zu nutzen. Nun ist eine kompromittierte Verschlüsselung eine der schlimmsten Schwachstelen, die man sich vorstellen kann, doch so dramatisch wirkte eFail nicht. Zuerst musste der Man-in-the-middle-Angriff erfolgreich sein und zum anderen ließ sich die Angriffsfläche durch die richtige Konfiguration des Mail-Clients erheblich reduzieren.

Die zu frühe Veröffentlichung und viele, zu wenig lösungsorientierte, Artikel sorgten aber für den generellen Eindruck, dass Verschlüsselung an sich wirkungslos wäre. Dem ist nicht so, auch wenn es, gerade bei deren Anwendung als E-Mail Schutzmechanismus, längst überfälligen Nachholbedarf gibt. Inzwischen hat jeder Verschlüsselungshersteller Anleitungen für eine sichere Konfiguration veröffentlicht, für die meisten Tools liegen auch Updates vor. Am grundsätzlichen Problem, dass Verschlüsselung in der Umsetzung zum einen zu komplex ist und zum anderen dem technisch Möglichen hinterherhinkt, ändert das nichts. Man kann nur hoffen, dass solche Vorfälle bei den Herstellern den Willen zur fortschrittlicheren Umsetzung stärken. Der Krypto-Messenger Signal könnte ein gutes Beispiel dafür sein, wie man es richtig macht. Signal gibt es heute schon für alle wichtigen Mobile-Betriebssysteme sowie für Mac, Windows und (Debian) Linux. Eine Erweiterung für Outlook würde den Markt gehörig aufmischen und das generelle Sicherheitsniveau in der Kommunikation deutlich erhöhen.