© ikorch / 123RF.com

Rund 200 Milliarden E-Mails werden pro Tag versendet, die meisten unverschlüsselt. Dabei wäre eine Chiffrierung nicht schwierig – und erscheint derzeit notwendiger denn je.

Die Mail ist ebenso alltäglich wie selbstverständlich: “Bitte übersenden Sie mir doch die vorhandenen Rentenbescheide und eine aktuelle Einkommensübersicht. Hatten Sie in letzter Zeit längere berufliche Auszeiten?” Die Fragen sind verständlich, handelt es sich bei der Absenderin doch um die selbstständige Rentenberaterin, die mit der Klärung des eigenen Rentenkontos beauftragt wurde. Aber will man diese Informationen einfach so per E-Mail versenden? Es bleibt ein flaues Gefühl. Andererseits erscheint es als Overkill, die Unterlagen zu kopieren und zum Briefkasten zu tragen oder gar persönlich vorbeizubringen, wenn sich die Angelegenheit doch mit einem Mausklick per E-Mail erledigen ließe.

Aus Sicht eines Mailservers und damit auch dessen Administrators handelt es sich bei E-Mails schlicht um ASCII-Textdateien, die von Server zu Server übertragen werden. Dabei landen sie sowohl zwischendurch als auch am Ziel als für den Admin frei lesbare Textdatei im Dateisystem. Sie mitzulesen stellt für Administratoren kein Problem dar, auch wenn die einzelne Nachricht in der schieren Masse schnell untergeht. Aber wer weiß, wonach er Ausschau hält, kann lesen, was er möchte.

Und die Begehrlichkeiten sind da. Klein- und Großkriminelle hacken sich in E-Mail-Postfächer und analysieren systematisch vorgefundene Nachrichten – wenn auch in der Regel nur, um Freundschaften und Geschäftsbeziehungen für weitere Betrugsversuche auszuspionieren. Aber auch Politik und Ermittler interessieren sich zunehmend für die elektronische Kommunikation der Bürger. Schon immer konnten Behörden dabei im Rahmen einer gezielten Telekommunikationsüberwachung (TKÜ) auf alle ein- und ausgehenden Nachrichten eines Postfachs zugreifen, bislang allerdings nur unter sehr restriktiven Bedingungen wie beispielsweise einem Richtervorbehalt.

Doch unter der Führung des CSU-Innenministers Horst Seehofer häuften sich in den letzten Jahren Gesetzesinitiativen zur Absenkung des Schutzniveaus privater Kommunikation, was schleichend Tür und Tor für eine präventive anlasslose Massenüberwachung öffnete. Der nächste Vorstoß ist der voraussichtlich Anfang Dezember zur Verabschiedung stehende Gesetzesentwurf zur sogenannten Chat-Kontrolle, nach der Provider Chat-Verläufe und auch Postfächer ihrer Nutzer mittels künstlicher Intelligenz (KI) systematisch nach kinderpornografischen Inhalten scannen sollen. Entsprechende Fundstellen müssten sie dann automatisch an Ermittlungsbehörden melden. Kritiker fürchten sowohl Fehlentscheidungen der KI als auch, dass der berechtigte Kampf gegen Kinderpornografie nur als Vorwand für weitergehende systematische Eingriffe in die freie und sichere Kommunikation genutzt werden könnte. Sie sehen die grundgesetzlich garantierte Gedanken- und Meinungsfreiheit bedroht.

Das gesellschaftliche Interesse an systematischer Mailverschlüsselung wächst langsam, aber stetig. Nachdem die Snowden-Enthüllungen 2013 zunächst vielen die Augen geöffnet hatten, ließ die Begeisterung schnell wieder nach, sich mit Verschlüsselung zu beschäftigen. Doch die kurz darauf eingeführte europaweite Datenschutzgrundverordnung (DSGVO) machte angesichts hoher möglicher Bußgelder und einer breiten öffentlichen Diskussion auch vielen Unternehmen klar, dass sie das Thema nicht beliebig ignorieren können. Hektik ist im Markt deswegen nicht ausgebrochen, und die Mühlen von Verwaltung und Unternehmen mahlen langsam. Aber zunehmend legen auch Unternehmen demonstrativ Wert auf Datenschutz und Datensicherheit und werben damit.

SSL/TLS wird zur Norm

Es sind zuallererst die großen Provider, die in den letzten Jahren ihre mehr als überfälligen Hausaufgaben gemacht haben. Wurde eine SSL/TLS-Transportverschlüsselung über viele Jahre und Jahrzehnte nur stiefmütterlich und sehr nachlässig auf den Mailservern der Provider implementiert, haben alle namhaften und verantwortungsbewusst agierenden Anbieter nunmehr nachgezogen. Verbindungen von und zu ihren Mailservern werden – ähnlich wie bei HTTPS – mittels SSL/TLS-Verschlüsselung abgesichert, sodass die Daten nur verschlüsselt durchs Internet laufen.

Es wäre nur zu schön, feststellen zu können, dass alle Anbieter mittels SSL/TLS absichern, doch dem ist nicht so. Es gibt Lücken, auch bei Anbietern, bei denen man das beim besten Willen nicht akzeptieren kann. Ursachen sind meist sehr alte, ungepflegte Mailserver, insbesondere wenn kommerzielle Firewall- oder Spamfiltersysteme zum Einsatz kommen, die SSL/TLS nicht gut unterstützen oder deren Administration nicht durch fachkundige Postmaster vorgenommen wird. Auch Exchange-Server, die direkt im Internet für den Mailempfang erreichbar sind, fallen immer wieder durch fehlende Verschlüsselungsmöglichkeiten auf. Die gute Nachricht: Wann immer Linux-basierte Mailserver wie beispielsweise Postfix zum Einsatz kommen, wird SSL/TLS normalerweise wie selbstverständlich angeboten.

Ob eine Mail also mittels SSL/TLS verschlüsselt wird, kann der Absender weder erkennen noch als sicher voraussetzen. Als erster Anbieter führte darum Mailbox.org ein Verfahren ein, das dem Nutzer schon beim Schreiben der E-Mail anzeigt, ob und wie sich das Zielsystem mittels SSL/TLS erreichen lässt. Andere Provider haben dieses Verfahren mittlerweile kopiert und ebenfalls implementiert.

Noch mehr Sicherheit

Doch mit der Aktivierung von SSL/TLS allein ist es heute nicht getan. Da das Simple Mail Transport Protocol (SMTP) eine Verschlüsselung nur optional vorsieht, könnte ein Man in the Middle den SSL-Verbindungsaufbau unterdrücken und eine unverschlüsselte Klartextverbindung erzwingen. Alternativ könnte ein Angreifer die SSL-Zertifikate der Mailserver gegen seine eigenen austauschen. Doch auch dagegen gibt es Abhilfe: Der seit einigen Jahren verfügbare Standard DANE (DNS-based Authentication of Named Entities [1]) definiert, wie Mailserver mittels entsprechender DNS-Einträge vom Typ TLSA die Fingerprints der von ihnen verwendeten SSL-Zertifikate publizieren können. Das verhindert wirkungsvoll eine Manipulation oder ein Unterdrücken der Zertifikate durch Dritte.

Doch DANE ist bis heute nur bedingt verbreitet: Während datenschutzaffine Mail-Provider wie Mailbox.org, Mail.de oder Posteo als erste Anbieter auf dem Markt demonstrativ DANE anboten und auch große Anbieter wie T-Online, Web.de und GMX nach einiger Zeit nachzogen, tun sich viele Anbieter bis heute sehr schwer damit. Der Grund: Das Publizieren der Zertifikat-Fingerprints per DANE klappt erst dann, wenn sie ihrerseits die jeweilige DNS-Zone mittels DNSSEC gegen Manipulation absichern. Dieser wünschenswerte Schritt stellt aber manche Infrastrukturen vor größere Herausforderungen, sodass viele IT-Verantwortliche ihn fürchten und nicht angehen.

Postmaster, die über eine DNSSEC-gesicherte Domain verfügen, können mit wenigen Handgriffen die Prüfsumme ihres Zertifikats veröffentlichen. Dabei helfen spezielle Webseiten [2], den notwendigen DNS-Record vom Typ TLSA zu erzeugen. Doch Vorsicht: Bei jeder zukünftigen Änderung des SSL-Zertifikats muss man nun an ein Update des eigenen DANE-Records denken. Modern konfigurierte Mailserver wie Postfix blockieren den Mailversand, wenn Zertifikat und per DANE publizierter Fingerprint nicht zusammenpassen oder wenn ein Ziel überraschenderweise kein SSL/TLS anbietet, obwohl ein DANE/TLSA-Record publiziert wurde. In der »main.cf« von sendenden Mailservern sollte die Zeile »smtp_tls_security_level = dane« auch dann eingetragen sein, wenn diese selbst eingehend kein DANE anbieten.

Im Postfach

SSL gut, alles gut? Mitnichten, denn es sichert ja nur die TCP/IP-Verbindung zwischen zwei konkreten Mailservern. Niemand weiß, ob die Nachricht im weiteren Verlauf vielleicht auch über unverschlüsselte Verbindungen übertragen wird. Zudem landet die E-Mail selbst im Klartext auf den Servern, sowohl in der Inbox des Empfängers als auch im Sent-Folder des Absenders.

Und so finden sich in einem über Jahre, vielleicht auch Jahrzehnte betriebenen elektronischen Postfach viele höchstpersönliche Dinge, die besser nicht in die Öffentlichkeit gelangen sollten. Dazu bedarf es keiner plakativen Beispiele aus dem Bereich Steuer und Gesundheit, auch ganz normale Nachrichten lassen stets tief in das Leben eines Menschen blicken. Dazu gehört sicherlich auch manche E-Mail, die man vielleicht besser nicht geschrieben hätte oder die Positionen vertritt, hinter denen man viele Jahre später vielleicht nicht mehr steht. Welche Auswirkungen ein viele Jahre alter Tweet aus Jugendzeiten haben kann, erfuhr erst kürzlich die Bundessprecherin der Grünen Jugend, Sarah-Lee Heinrich. Und dabei handelte es sich immerhin bereits um ein öffentliches Posting.

Jeder Nutzer sollte sich fragen: Welche Auswirkungen hätte es, wenn meine komplettes E-Mail-Postfach öffentlich werden würde? Denn das kann schnell geschehen. Ein schlecht gewähltes IMAP-Passwort lässt sich leicht hacken, es kann in einem unaufmerksamen Moment einer Phishing-Seite offenbart oder durch eine lokale Vireninfektion abgefangen worden sein. Kriminelle hacken Postfächer systematisch und reihenweise, und in jedem Fall hätten die Angreifer dabei stets auch Zugriff auf alle darin gespeicherten E-Mails. Selbst wenn der Nutzer alles perfekt macht, könnten Angreifer auch auf den Server des Anbieters gelangen.

Abhilfe schafft hier nur ein Verschlüsseln der E-Mails mittels PGP oder S/MIME. Beide Verfahren unterliegen ganz grundsätzlich demselben Prinzip: Jeder Nutzer besitzt ein sogenanntes asymmetrisches Schlüsselpärchen. Es besteht aus einem öffentlichen Schlüssel (Public Key), mit dem er verschlüsselt und digital unterschreibt, sowie einem geheimen Schlüssel (Private Key), mit dem er entschlüsselt und eine digitale Unterschrift überprüft werden kann. Dabei schützt ein vom Nutzer zu wählendes Passwort den Private Key gegen unbefugte Zugriffe. Dieses Passwort darf er auf keinen Fall vergessen. Geht es verloren, ist die Schlüsseldatei unbrauchbar, und auf alle damit verschlüsselten Daten lässt sich nicht mehr zugreifen.

Den eigenen öffentlichen Schlüssel speichert man zusammen mit denen anderer Empfänger in einer lokalen Schlüsseldatenbank, die man auch Keyring (Schlüsselbund) nennt. Da sich für eine Mailadresse im Lauf der Zeit mehrere Schlüssel erzeugen lassen, besitzt jeder Schlüssel eine eigene ID. Zudem lässt sich die Echtheit eines Schlüssels anhand eines Fingerprints überprüfen, eines mathematisch eindeutigen Fußabdrucks. Den kann man auch auf Visitenkarten oder im Webimpressum veröffentlichen oder am Telefon überprüfen, was es Kommunikationspartnern erlaubt sicherzustellen, dass ihnen wirklich der richtige Schlüssel vorliegt.

Das Erzeugen eines solchen Schlüsselpärchens ist heutzutage denkbar einfach und erfolgt in der Regel automatisch bei der ersten Benutzung der jeweiligen PGP-Software. Der öffentliche Public Key lässt sich dann einzeln oder automatisch an Kommunikationspartner übermitteln. Mailprogramme wie Thunderbird bieten an, den öffentlichen Schlüssel auf Knopfdruck an eine ausgehende E-Mail anzuhängen. Zudem lässt er sich auf öffentliche PGP-Keyserver hochladen, wo Interessierte ihn automatisiert finden können.

Revoke-Zertifikate speichern

Ein einmal in Umlauf gebrachter Schlüssel lässt sich zwar nicht mehr löschen, doch man kann ihn im Falle eines Schlüsseldiebstahls oder Passwortverlusts für ungültig erklären. Dafür sollte man rechtzeitig – das heißt direkt nach der Schlüsselerzeugung – ein entsprechendes Widerrufszertifikat (Revoke-Zertifikat) erzeugen und an sicherer Stelle im eigenen Dateisystem speichern. Geht das eigene Passwort verloren, klappt das nicht mehr. Zudem sollte man Schlüssel nicht auf unbestimmte Zeit ausstellen, sondern ihnen ein wenige Jahre in der Zukunft liegendes Ablaufdatum zuweisen. Es lässt sich von Zeit zu Zeit verlängern und schützt vor der unangenehmen Situation, dass ein unendlich lange gültiger Schlüssel unkontrolliert verloren gegangen sein könnte.

Alle diese Möglichkeiten finden sich in der Regel in der Schlüsselverwaltung des eigenen Mailprogramms. Dazu rufen Sie über einen Klick auf die rechte Maustaste die Eigenschaften und Aktionsmöglichkeiten des eigenen Schlüssels auf (Abbildung 1).

Abbildung 1: Die Optionen zum Verwalten des eigenen Schlüssels finden sich im Kontextmenü.

Es bleibt ein Problem: Es lässt sich zunächst nicht überprüfen, ob ein Schlüssel tatsächlich vom Inhaber der jeweiligen Mailadresse stammt. Angreifer können recht problemlos für beliebige Mailadressen eigene PGP-Keys erzeugen und in Umlauf bringen. Die öffentlichen PGP-Keys anderer Nutzer gelten daher im eigenen Keyring zunächst als nicht vertrauenswürdig. Absender und Empfänger können sich dort jedoch den spezifischen PGP-Fingerprint anzeigen lassen und ihn über ein anderes Kommunikationsmedium – notfalls per kurzen Telefonanruf – verifizieren.

Soweit die Theorie. In der Praxis verwenden heute viele Anwender die empfangenen Schlüssel auch ohne Überprüfung. In den Einstellungen des Mailprogramms lässt sich festlegen, ab welcher Vertrauensstufe ein Schlüssel zum Versenden dienen darf. Das ist sicherlich nicht optimal und könnte eine trügerische Sicherheit vermitteln. Andererseits ist jede Form der angewandten Verschlüsselung zunächst besser als gar keine, sodass man es hier im Sinne der Sache gegebenenfalls pragmatisch angehen sollte. Ein empfangener Schlüssel ist dann unsicher, wenn er zum Zeitpunkt des Empfangs von einem Dritten manipuliert wurde und man dem so kompromittierten Schlüssel dauerhaft traut. Geht man jedoch davon aus, dass der (vielleicht schon lange zurückliegende) Schlüsselaustausch damals sicher war, kann dieser Schlüssel gegen alle zukünftigen unerwünschten Mitleser und dem Man in the Middle erfolgreich schützen.

Da manuelle Prüfungen für eine große Masse an Kommunikationspartnern keinen guten Weg darstellen, implementiert PGP das Konzept eines Web of Trust. Dabei signieren Nutzer nach sorgfältiger persönlicher Prüfung der jeweiligen Identität die Schlüssel anderer Nutzer (Abbildung 2) und erhöhen damit deren Vertrauenswürdigkeit. Die jeweiligen Unterschriften werden dann Bestandteil des Public Keys des Nutzers (Abbildung 3). Haben Schlüssel irgendwann durch viele Unterschriften bekannter vertrauenswürdiger Kommunikationspartner einen ausreichend guten Leumund, kann man auf eine manuelle eigene Prüfung verzichten. Noch heute finden darum auf Konferenzen wie den Chemnitzer Linux-Tagen PGP-Keysigning-Partys statt [3]. Dazu muss man die eigenen PGP-Schlüssel und standardmäßig den Personalausweis oder Reisepass als Identitätsnachweis mitbringen, denn eine sorgfältige Überprüfung ist Pflicht.

Abbildung 2: Das Signieren eines fremden Schlüssels erhöht dessen Vertrauenswürdigkeit und erfordert entsprechende Sorgfalt.

Abbildung 3: Die Eigenschaften eines Schlüssels zeigen dessen Fingerprint und die Signierungen anderer Nutzer.

Doch das Konzept der gegenseitigen PGP-Signierung ist aufwendig, erfordert Initiative und viel Interaktion – einer der Hauptgründe, warum sich PGP nie flächendeckend durchsetzen konnte. Modernde Ansätze sehen darum vor, den eigenen PGP-Schlüssel über spezielle Schlüsselserver des Providers anzubieten, von wo Kommunikationspartner ihn automatisch beziehen können. Das schließt zwar eine Manipulation durch Administratoren des vom Nutzer gewählten Anbieters nicht aus, sorgt ansonsten jedoch schon sehr zuverlässig dafür, dass die Schlüssel nicht mehr beliebig von Dritten erzeugt und in Umlauf gebracht werden können. Über Verfahren wie WKS/WKD können Inhaber eigener Domains darum einstellen, wessen PGP-Keyserver für Schlüssel der eigenen Domain befragt werden sollen. Doch nur wenige Provider bieten systematisch eigene PGP-Keyserver an und haben für ihre Mail-Domains entsprechende WKD-Records gesetzt. Wenn doch, steht einem automatischen Schlüsselaustausch nichts mehr im Wege. PGP-Implementierungen wie GnuPG können die richtigen Schlüsselserver dann automatisch erkennen und Schlüsselmaterial herunterladen.

S/MIME mit zentralem Ansatz

S/MIME, das zweite bekannte Mailverschlüsselungsverfahren, chiffriert und signiert grundsätzlich vergleichbar zu PGP, geht aber bei der Frage der Schlüsselerzeugung und -verwaltung einen zentralistischeren Weg. Hier werden S/MIME-Zertifikate von einer zentralen Zertifizierungstelle ausgestellt, überwacht und gegebenenfalls auch wieder für ungültig erklärt. S/MIME eignet sich damit für einen strukturierten Einsatz in einem sehr kontrollierten Umfeld, beispielsweise in Behörden oder großen Unternehmen. Daher verwundert es wenig, dass klassische Business-Mailclients wie Outlook S/MIME stets nativ unterstützt haben. Hier lassen sich automatisiert flächendeckend glaubwürdige Verschlüsselungsstrukturen aufbauen.

Für den privaten Einsatz ist S/MIME hingegen weniger praktikabel, da es zunächst an einer sinnvollen zentral organisierten Zertifikatsstelle fehlt. Vor vielen Jahren gab es über das Projekt S-Trust einen Ansatz der Sparkassen, S/MIME-Zertifikate für die breite Masse auszustellen, der sich jedoch nicht durchsetzen konnte. Am praktikabelsten erscheint bis heute das vom Fraunhofer Institut betriebene und empfehlenswerte Projekt Volksverschlüsselung [4], das jedoch ebenfalls keine flächendeckende Bedeutung erreichen konnte.

Unverschlüsselte Metadaten

Wird eine E-Mail mittels PGP oder S/MIME verschlüsselt, betrifft das den gesamten Body der E-Mail, also den Nachrichtentext sowie etwaige Dateianhänge. Die Metadaten des Mail-Headers, also Angaben wie Absender, Empfänger, Message-ID und Datum, bleiben weiterhin lesbar. Auch der Betreff einer E-Mail gehört klassischerweise zu den nicht verschlüsselten Header-Daten einer E-Mail. Auf Wunsch verstecken moderne PGP-Implementierungen ihn ebenfalls im verschlüsselten Body der Nachricht, sodass er erst nach einer Entschlüsselung lesbar wird.

Verschlüsseln im Mailclient

Stößt ein Mailprogramm wie Thunderbird auf eine verschlüsselte E-Mail, prüft es zunächst, an welche Schlüssel-IDs diese Mail verschlüsselt wurde und ob sich im eigenen Schlüsselbund dafür ein Secret Key zum Entschlüsseln findet. Falls ja, fordert das Programm den Benutzer auf, den eigenen Schlüssel durch Eingabe des zugehörigen Kennworts zu entsperren. Man kann die Mail anschließend normal und problemlos lesen und bei Bedarf auch mitsamt Betreff im Inhaltsverzeichnis der Inbox anzeigen.

Sinnvollerweise behält das Mailprogramm den entschlüsselten Schlüssel für eine längere Zeit im Arbeitsspeicher, sodass er sich stundenlang ohne Passworteingabe verwenden lässt. Der Nutzer kann so bequem und transparent unzählige verschlüsselte E-Mails lesen und bearbeiten, ohne dass ihm dabei auffällt, dass die Nachrichten gerade im Hintergrund entschlüsselt werden. Erst nach längerer Inaktivität oder nach einem Neustart des Mailprogramms muss er das Schlüsselpasswort erneut eingegeben. Das sorgt für maximale Benutzbarkeit, birgt jedoch theoretisch auch die Möglichkeit, dass ein Angreifer den ungesicherten Schlüssel aus dem Arbeitsspeicher auslesen könnte.

Für das Senden einer E-Mail hingegen kommt der allgemein bekannte und passwortfrei vorliegende Public Key des Empfängers zum Einsatz, sofern einer existiert. Bei einer Nachricht an mehrere Empfänger lassen sich die E-Mails simultan mit den Schlüsseln aller Empfänger verschlüsseln und so auch von allen problemlos öffnen. Der einzige kleine Nachteil: Fachleute könnten normalerweise versteckte BCC-Empfänger anhand ihres nun in der E-Mail verwendeten Schlüssels erkennen. Standardmäßig wird übrigens auch eine Nachricht an den Absender selbst verschlüsselt, anderenfalls könnte er die von ihm selbst geschriebene E-Mail später in seinem Sent-Folder nicht mehr dekodieren.

Verschlüsseln bei Webmail

Anders sieht es aus, wenn der Nutzer über Webmailsysteme auf sein Postfach zugreifen möchte. Hier hat sich das Browser-Plugin Mailvelope durchgesetzt. Es läuft lokal im Webbrowser des Nutzers und erkennt, wenn der Webmailer des Anbieters eine PGP-verschlüsselte E-Mail enthält. Es dekodiert die enthaltene E-Mail, tauscht den Inhalt der Webseite gegen die unverschlüsselte Nachricht aus und zeigt sie an.

Auch das Absenden einer verschlüsselten E-Mail kann Mailvelope übernehmen. Bevor die im Klartext geschriebene E-Mail auf die Reise geht, verschlüsselt Mailvelope sie lokal und überträgt sie erst dann zum Webmailsystem des Anbieters. Das Verfahren erscheint auf den ersten Blick gut, denn das Dekodieren erfolgt nur lokal auf dem Rechner des Nutzers. Sicherheitsexperten beklagen jedoch die Implementierung von Mailvelope als Browser-Plugin: Sie führt dazu, dass das sensible PGP-Key-Material im nicht optimal schützbaren Plugin-Bereich des Browsers gespeichert wird. Außerdem gilt Javascript als nur wenig geeignet für die Implementierung sicherer Kryptografie.

Einen etwas anderen Weg gehen Implementierungen wie das Guard-System der Groupware-Lösung Open-Xchange: Hier liegt der Schlüssel sicher auf dem Server des Anbieters, ein vom Nutzer einzugebendes Passwort schützt ihn vor unbefugtem Zugriff. Das Ver- und Entschlüsseln übernimmt der Server, was ein Browser-Plugin überflüssig macht. So kann man auch unterwegs von fremden Rechnern aus jederzeit beruhigt auf das eigene Postfach zugreifen.

Ob es mehr Schutz bietet, hier dem professionellen Server-Betrieb des Mail-Providers zu vertrauen, oder ob angesichts üblicher Viren- und Ransomware-Attacken der eigene Schlüssel tatsächlich auf dem privaten PC sicher lagert, muss jeder Anwender mit sich selbst ausmachen. (jcb)