Man kann sich nicht immer aussuchen, mit wem man in Projekten wie kommuniziert. So bin ich als Linuxer natürlich oft mit Kunden konfrontiert, die ein MS Betriebssystem nutzen. Einige dieser Kunden setzen in der Kommunikation mit mir inzwischen vernünftigerweise folgene Mittel ein:
- Sie stellen entweder kryptierte Verbindungen zu speziellen ihrer Mail-Server zur Verfügung
- oder aber sie verwenden die Kombination Thunderbird/GnuPGP/enigmail, um Mails zu verschlüsseln und an mich zu versenden, in denen schützenswerte geschäftsrelevante Informationen hinterlegt sind. Hierzu haben wir unsere Public OpenPGP Keys ausgetauscht.
Generell hat die Bereitschaft von Kunden, Mails (Ende zu Ende) zu verschlüsseln, seit den publizierten Ereignissen im IT-Security-Umfeld der letzten zwei Jahre zugenommen.
Manchmal taucht nun das Thema auf, dass Kunden in der Mail Dinge farblich oder fett markieren wollen. Das sind sie aus der firmeninternen Kommunikation so gewohnt. Damit steht dann der Wunsch nach etwas auf der Tagesordnung, das eine Quelle von viel Unheil darstellt – nämlich der Wunsch nach HTML-formatierten Mails. Aus Security-Perspektive stellt das etwas dar, was man aus meiner Sicht unbedingt vermeiden sollte. Formatierte Information gehört in Anhänge, nicht in den Body einer Mail. Aber ist dieser Anspruch praxisnah und vermittelbar? Mein Erfahrung ist: Nicht jeder Kunden kann und will mit dieser Einschränkung leben und arbeiten – auch bei aller vorhandener Bereitschaft zur Verschlüsselung nicht.
Potentielles Problem unter Kmail beim Öffnen von HTML-Mails, die mit Thunderbird/enigmail kryptiert wurden
Will der Kunde unbedingt HTML-Mails austauschen, so ergibt sich u.U. das Problem,
- dass der Kunde (unter MS Win 7) mit Hilfe von Thunderbird/enigmil zwar eine von mir unter Linux mit Hilfe von Kmail erstellte und mit GnuPG/GPG kryptierte HTML Mail empfangen und ansehen kann,
- aber ich selbst eine unter Thunderbird verfasste, mit “enigmail” kryptierte HTML Mail nur in Plain Text Form erhalte und der HTML-Anhang der Mail beim Öffnen nur krypierte Anweisungen enthält.
Der Grund liegt in einer speziellen unter Thunderbird/enigmail standardmäßig eingestellten Variante der Verschlüsselung – nämlich “Inline PGP”. Siehe hierzu:
http://de.wikipedia.org/ wiki/ PGP/ INLINE
https://www.enigmail.net/ forum/ viewtopic.php? f=3&t=134
Ein Grund für den standardmäßigen Einsatz von “Inline PGP” ist u.a. der, dass etliche (u.a. MS-lastige) Mail Clients mit der normierten Verschlüsselungsvariante “PGP/Mime” nicht richtig umgehen können. Siehe z.B.:
http://www.phildev.net/ pgp/ pgp_clear_vs_mime.html
Leider führt “Inline PGP” dazu, dass HTML Mails im Rahmen der Verschlüsselung nicht korrekt als Attachment-Streams kryptiert werden. Letzteres zieht bei meinem Kunden dann konsistenterweise Warnungen beim Versuch der Verschlüsselung einer erstellten HTML-Mail nach sich – nämlich dass vorgenommene Formatierungen beim Verschlüsseln und Signieren verloren gehen werden.
Gibt es einen Ausweg? Zumindest im Prinzip: ja. Man muss “enigmail” so einstellen, dass es den definierten Standard “PGP/MIME” zur Kryptierung anstelle von Inline PGP verwendet. Dann ist für eine standardkonforme Verschlüsselung von Mail-Attachments und damit – bei Wahl einer entsprechenden Versandart – auch für eine ordnungsgemäße Behandlung von HTML-Mails gesorgt.
Linux Mail Clients, die GnuPG/GPG einbinden, können i.d.R. mit Mails und Attachments umgehen, die gemäß der “PGP/MIME”-Regeln
kryptiert wurden. Siehe zu “PGP/MIME” etwa :
http://de.wikipedia.org/ wiki/ PGP/ MIME
http://de.wikipedia.org/ wiki/ OpenPGP
Dies trifft natürlich auch auf Kmail zu. So ist also der Einsatz von “PGP/Mime” durch den Kunden (mit MS Win, Thunderbird) zumindest in der Kommunikation mit mir kein Problem. Die entsprechenden Einstellungen können unter “Thunderbird/enigmail” zudem spezifisch für einen Mail Account vorgenommen werden. Hat der Kunde die Möglichkeit, einen spezifischen Mail-Account für die Kommunikation mit mir zu nutzen, so ist man als Linux-Kmail-Nutzer aus dem Schneider – nicht jedoch zwangsläufig als Security-Berater; s.hierzu einen speziellen Absatz weiter unten.
Erforderliche Einstellungen unter Thunderbird/enigmail
Zwei Schritte sind erforderlich, damit mit Thunderbird erstellte und mittels “enigmail” kryptierte HTML Mails auf einem Linux-System mit Kmail-Client nach Dekryptierung als HTML Mails geöffent werden können und danach alle vom Absender vorgenommenen Formatierungen auch angezeigt werden:
- Schritt 1: Aktivierung von “PGP/MIME”
Das entsprechende mit Häkchen zu versehende Feld findet man unter Thunderbird für Windows unter
Extras >> Konten-Einstellungen >> dein relevanter Mail Account >> OpenPGP-Sicherheit >> PGP/MIME standardmäßig verwenden. - Schritt 2: Versand im Format “Reintext und HTML”
Vor dem Versenden der E-Mail aus dem E-Mail-Erstellungsdialog von Thunderbird muss der Anwender explizit die Einstellung “Reintext und HTML” unter dem Menüpunkt “Optionen >> E-Mail Format” vornehmen.
Letzteres könnte man zwar auch als globale bzw. empfängerspezifische Option festlegen. Ich persönlich würde das aber nicht tun, sondern als Standard “Reintext” wählen. Es gilt ja nach wie vor die Maxime, dass HTML-Mails in der Mail-Kommunikation mit mir nur im Ausnahmefall zum Zuge kommen sollen.
Eine ausführlichere Beschreibung zu den vorzunehmenden Einstellungen von Thunderbird findet man z.B. unter:
https://micahflee.com/ 2013/ 09/ html-email-attachments-and-flowed-text-in-enigmail/
Sicherheitsaspekte
Nun ein paar Worte zu einigen potentiellen und interessanten Sicherheitsproblem von “enigmail” im Zusammenhang mit PGP/MIME, nämlich u.a. dem atomatischen Öffnen und Dekryptieren von Mails im Hintergrund. Siehe hierzu im Besonderen den Kommentar von Alan Eliasen zu dem eben zitierten Artikel
https://micahflee.com/ 2013/09/ html-email-attachments-and-flowed-text-in-enigmail/
und weitere entsprechende Hinweise unter
https://futureboy.us/ pgp.html
Letzterer Artikel enthält übrigens auch grundsätzliche und interessante Hinweise zum Einsatz von OpenPGP/GnuPG.
Besonders interessant und lehrreich im Zusammenhang mit “enigmail” ist die Diskussion zu dem besonders kritisierten Punkt im Zshg. mit PGP/MIME, der den enigmail-Entwicklern als Bug gemeldet und danach heftig diskutiert wurde. Siehe hierzu:
http://sourceforge.net/ p/ enigmail/ bugs/226/
und die dortigen Kommentare.
Was ist nun meine Meinung zu deser Debatte ? Grob Folgendes :
Ich verstehe die Kritik und die Bedenken von Hrn. Eliasen gut; inbesondere den von ihm geäußerte Kritik an der durch Thunderbird (mit Hilfe von enigmail) automatisch in Gang gesetzten Dekryptierung von PGP/MIME-verschlüsselten Mails samt Anhängen im
Hintergund. Auch die grundsätzlich in Betracht gezogenen Angriffsmethoden auf akustischer Ebene waren bis zu Gegenmaßnahmen auf der GnuPG-Seite relevante Punkte.
Aber: 100%-ige Sicherheit gibt es nicht – und in der Praxis werden nach Abwägung von Risiken immer wieder Kompromisse zu schließen sein. Dabei muss auch die sichere und bequeme Handhabung einer SW durch den Anwender einbezogen werden. Das ist hier durchaus relevant.
Nehmen wir mal an, nur autorisierte User haben Zugang zum PC/Laptop des Kunden: Wenn dann – also im Normalbetrieb – im Hintergrund dekryptierte Mails von einem Angreifer mitgeschnitten werden sollten, dann bestünde bereits ein grundsätzliches, über Thunderbird weit hinausgehendes Problem auf dem attackierten Computer bzw. im umgebenden Netzwerk. Auch akustische Attaken würden ein hohes Maß an krimineller Energie am Standort des empfangenden Computers voraussetzen.
Ferner geht es ja zunächst vor allem darum, dass der Kunde Mails überhaupt verschlüsselt über das Internet transportiert. Man muss ja (leider) schon dankbar sein, wenn man einen Nicht-IT-Fachmann dazu bewegen konnte, die für entsprechende Verschlüsselungsmaßnahmen notwendige Energie aufzuwenden. Bequem und einfach ist das für den Normalverbraucher eher nicht. Als wenig praxistauglich bis realitätsfern muss man gar Eliasen’s Aufruf zu einer manuellen Verschlüsselung des Mail-Bodies durch den Windows-Anwender einstufen.
In einer Hochsicherheitskommunikation ist die “Ende zu Ende”-Verschlüsselung auf dem Transportweg natürlich nur ein Teil der erforderlichen Maßnahmen. Die sichere kryptierte Ablage der Mails auf dem sendenden wie auf dem empfangenden System gehört mit in ein umfassendes Maßnahmenpaket. Aber sobald ein funktionierender Transfer mit einer “Ende zu Ende”-Verschlüsselung etabliert wurde, hat man immerhin einen wichtigen Schritt in Richtung einer verbesserten Sicherheit im Informationsaustausch hinter sich gebracht.
Alles weitere betrifft dann die Sicherheit der Informationsablage und Informationssnutzung auf den sendenden bzw. empfangenden Systemen. U.a. will man ja bei kryptierten Mails eine gewisse Grundsicherheit auch dann noch aufrecht erhalten, wenn ein physikalischer Zugriff (z.B. auf einen gestohlenen oder unbewachten Laptop) durch unautorisierte User erfolgt und ggf. nach Einsatz von Passwort-Crackernein Login durch den ungebetenen Gast gelingt. Hier zieht dann das Argument von Eliasen bzgl. der automatischen Dekryptierung wirklich:
Ohne explizit geforderte Dekryptierung durch einen autorisierten User sollte kein System eine Dekryptierung von Mails in Gang setzen. Der potentielle nicht-autorisierte Angreifer erhielte hier ggf. Zugang zu den geheim zu haltenden Informationen, ohne das Passwort für den privaten Schlüssel überhaupt benutzen zu müssen. Letzteres wäre z.B. dann gegeben, wenn der Angreifer Thunderbird nutzen kann und enigmail das erforderliche Passwort noch aus einem meist stadardmäßif vorkonfigurierten Zwischenspeicher bezieht.
Dieser Bedrohung kann man aber bei Bedarf dadurch begegnen, dass man den Schlüssel mit einem sicheren Passwort versieht und enigmail/GnuPG anweist, das Passwort für den privaten Schlüssel nicht – auch nicht für einen kurzen Zeitraum – zwischenzuspeichern. Bequemer wird der Einsatz von Thunderbird/enigmal dadurch aber nicht. (Steht Sicherheit wirklich über allem, so wird man ferner die Harddisks verschlüsseln, um im Verlustfall grundsätzlich mehr Sicherheit zu haben.)
Ferner möchte ich anmerken, dass die enigmail-Entwickler ja schließlich gerade aufgrund der geführten Debatte (dankenswerterweise) Schritte in Richtung einer besseren und kontrollierteren Handhabung der Dekryptierung vorgenommen haben.
Bleibt das Restrisiko, dass größere mit PGP/Mime verschlüsselte HTML-Anhänge eine Menge an bekannten Textfragmenten wie etwa Tags enthalten. Dies kann gut ausgestatteten Angreifern mindestens theoretisch eine Grundlage für statistik-basierte Dekryptierungsversuche
verschaffen. Sollte dieses Problem wirklich bestehen, dann würde ich darin insgesamt aber eher eine Schwäche des Kryptierungsverfahrens (also von GnuPG) sehen als von “enigmail”.
Habe ich die Wahl zwischen weiter bestehenden Rest-Risiken und einem total unverschlüsselten Email-Verkehr, so ziehe ich – nach entsprechender Unterweisung des Kunden – immer noch den Einsatz einer Verschlüsselung vor.
Abschließend gilt grundsätzlich :
Mit HTML-Mails sind jenseits von Wechselwirkungen mit Verschlüsselungsprogrammen weitere schwerwiegende Risiken verbunden, denen man sich im Rahmen einer sicheren Kommunikation (bei allem gegenseitigen Vertrauen der Kommunikationspartner) erst gar nicht aussetzen sollte. Der Kunde sollte also dahingehend beraten werden, HTML-Mails im Normalfall auch in der Kommunikation mit vertrauenswürdigen Kommunikationspartnern (in diesem Falle u.a. mit mir) zu vermeiden.
Selbst sollte man seinen E-Mail Client so einstellen, dass er HTML-Mails zunächst nur im Plain Text Format öffnet. Im Falle, dass HTML-Formatierungen wirklich eine wichtige Rolle spielen, kann man den PGP/MIME HTML-Anhang immer noch öffnen. Als Paranoiker auch bei vertrauenswürdigen Quellen ggf. zunächst in einem Standard-Editor, um den HTML-Code vor einer Ausführung zu analysieren. 🙂