Mailverschlüsselung mit Thunderbird, der x-te Anlauf

Spätestens seit den Snowden-Enthüllungen ist klar: die Privatspähre einer E-Mail ist ungefähr mit der einer Postkarte gleichzusetzen. Wer sie in die Finger bekommt, kann sie lesen. Ein persönlicher Erfahrungsbericht, was man dagegen tun kann.

Mit E-Mail-Verschlüsselung habe ich mich in der Vergangenheit schon manches Mal beschäftigt: auf meiner Festplatte finde ich Schlüssel von ersten Versuchen im Jahr 2006. Allein – es hat bisher nie geklappt. Selbst die Security-Szene gesteht ein, dass bis heute niemand ein wirklich laientaugliches und zugleich sicheres System entwickelt hat. Trotzdem habe ich mich Anfang November auf Anregung eines Freundes mal wieder daran versucht – diesmal tatsächlich mit Erfolg. Der folgende Bericht basiert auf meinen Erfahrungen der vergangenen Tage, und ich fühle mich damit weit entfernt davon, Verschlüsselungsexperte zu sein. „Einäugiger unter Blinden“ trifft es wohl besser.

Werden Mails denn nicht sowieso verschlüsselt übertragen?

Ja, vielleicht, stellenweise. Im Einzelnen sieht das so aus:

  • Ich erstelle eine Mail – in meinem Mailprogramm oder im Webmailer. Der Entwurf wird regelmäßig zwischengespeichert, lokal oder beim Mailprovider, und zwar unverschlüsselt.
  • Nach dem Klick auf „Senden“ wird die Mail zu meinem Mailprovider übertragen. Hier hat sich in den vergangenen Jahren eine erfreuliche Verbesserung ergeben: praktisch alle Anbieter erzwingen hier inzwischen eine Transportverschlüsselung. Das bedeutet: auf dem Weg von meinem Computer zum Mailprovider sind die Daten von Dritten nicht einsehbar.
  • Mein Mailprovider speichert die Nachricht zwischen (unverschlüsselt) und leitet sie an den Provider des Adressaten weiter. Auch hier gab es in den letzten Jahren ein Fortschrittchen: Mitglieder der Initiative „E-Mail made in Germany“ sichern zu, dass sie Mails untereinander nur verschlüsselt austauschen. Ein Fortschrittchen, weil ich davon nur was habe, wenn sowohl ich als auch der Adressat Kunde der teilnehmenden Partner sind. Und deren Liste ist auch sechs Jahre nach der Einführung überschaubar: web.de, GMX, Deutsche Telekom, Freenet, 1&1, Strato sowie Hornetsecurity. Das bedeutet im Umkehrschluss: Bin entweder ich oder mein Adressat bei einem anderen Provider, wird meine Mail möglicherweise unverschlüsselt übertragen.
  • Der Mailprovider meines Adressaten nimmt die Mail entgegen und speichert sie, man ahnt es: unverschlüsselt. Konkret bedeutet das: Administratoren dieses Providers ebenso wie staatliche Überwachungsorgane haben Zugriff auf die Daten.
  • Der Empfänger schließlich liest die Mail oder ruft sie mit seinem Mailprogramm ab, wo sie – klar – unverschlüsselt gespeichert wird.

Die Abhilfe: Ende-zu-Ende-Verschlüsselung

Bei dem Verfahren, um das es hier gehen soll, durchläuft die Mail alle oben genannten Stationen – mit dem Unterschied, dass die Mail bereits auf meinem PC verschlüsselt wird. Dafür werden wir PGP (Pretty Good Privacy) nutzen. PGP setzt auf ein Public-Key-Verfahren. Das bedeutet, dass ich bei der Ersteinrichtung ein Schlüsselpaar erzeuge. Mit dem ersten – dem öffentlichen – werden Nachrichten verschlüsselt, die an mich gesendet werden. Daher kann ich diesen Schlüssel bedenkenlos frei im Internet veröffentlichen. Das Entschlüsseln dagegen ist nur mit dem zweiten, dem privaten Schlüssel möglich – daher sollte ich den auch extra-sicher verwahren.

Ist die Einrichtung also geschafft, kann allein der Adressat (genauer gesagt: wer den privaten Schlüssel hat) die Nachricht wieder entschlüsseln – niemand sonst.

Interessant in diesem Zusammenhang: der Berliner Anwaltsgerichtshof hält eine solche Ende-zu-Ende-Verschlüsselung nicht für notwendig. Ist ja bisher auch immer ohne gegangen, ne?

Wie richtet man das diese Ende-zu-Ende-Verschlüsselung nun ein?

Schritt 1: der Mailprovider

Fein raus ist, wessen Mailprovider die Ende-zu-Ende-Verschlüsselung bereits implementiert hat. Das ist zum Beispiel bei posteo.de oder mailbox.org der Fall. Meine wärmste Empfehlung – das sind die Guten!

Ich werde mich im Folgenden auf mailbox.org – meinen Provider beschränken. Dort gibt es den mailbox.org Guard – eine serverseitige PGP-Implementierung. Das hat den großen Vorteil, dass ich verschlüsselte Mails auch im Browser/Webmailer lesen kann. Andernfalls wäre ich immer auf einen Mailclient (z.B. Thunderbird) mit aktivierter Verschlüsselung angewiesen. Es hat auch den Vorteil, dass die Schlüssel gleich für mich erzeugt werden.

Wer oben aufgepasst hat, erkennt aber schon den Haken: mailbox.org kennt meinen geheimen Schlüssel (sie haben ihn ja für mich erzeugt) und speichert diesen auch (sie sollen ja meine eingehenden Mails damit – nach Eingabe einer separaten Passphrase – entschlüsseln). Auf den Support-Seiten heißt es denn auch, diese Methode biete „hinreichende Sicherheit“, aber keine „absolute Sicherheit“.

Ich habe anfangs trotzdem diesen Weg gewählt, weil uns bei unseren Gehversuchen nicht klar war, wo man diese verdammten Schlüssel herbekommt. Bei der Gelegenheit habe ich versehentlich eine weitere nette Funktion von mailbox.org aktiviert: das verschlüsselte Postfach. Das hat zur Folge, dass mailbox.org unverschlüsselte Mails, die für mich eintreffen, mit meinem öffentlichen Schlüssel verschlüsselt und erst dann in mein Postfach zustellt. Das hat den Vorteil, dass mit der Zeit alle meine Mails verschlüsselt auf deren Server liegen, auch wenn die Absender das gar nicht getan hatten. In meinem Fall führte das allerdings zu Ärger: weil die Einrichtung von PGP in Thunderbird Probleme machte, konnte ich meine Mails ein paar Tage lang nur im Browser lesen, weil Thunderbird nicht in der Lage war, sie zu entschlüsseln.

Das Aktivieren des verschlüsselten Postfachs hat noch einen weiteren Haken, wenn man Wegwerfadressen (Spamgourmet, oder künftig besser erine.email?) nutzt: eingehende Nachrichten werden mit dem öffentlichen Schlüssel meiner mailbox.org-Adresse verschlüsselt, Thunderbird wird später aber nach einem privaten Schlüssel für die spamgourmet.com-Adresse suchen. Gibt es den nicht, ist die Nachricht verloren – ich kann sie nicht entschlüsseln. Verschlüsseltes Postfach also: lieber wieder deaktivieren.

Nachdem ich jetzt weiß, dass mailbox.org meinen privaten Schlüssel kennt, müsste ich strenggenommen mein dort erzeugtes Schlüsselpaar archivieren (nicht löschen, denn bereits ausgetauschte Nachrichten kann ich nur damit öffnen!) und mir ein neues Schlüsselpaar erzeugen, das dann wirklich nur ich kenne. Aber erst mal weiter mit dem Mailclient.

Schritt 2: Enigmail und Thunderbird

Das Mailprogramm Thunderbird an sich beherrscht kein PGP – ein Add-On namens Enigmail rüstet das nach (eine Anleitung von Mozilla dazu hier). Das Add-On setzt wiederum auf ein Softwarepaket, das verwirrenderweise GPG (GNU Privacy Guard) heißt. GPG wird nach Installieren von Enigmail automatisch heruntergeladen und eingerichtet. Ist das erledigt, scannt der Einrichtungsassistent mein(e) Postfäch(er) auf bereits vorhandene verschlüsselte Nachrichten, um die Konfiguration daran anzupassen. Bei mir schlug das leider reproduzierbar fehl – der Assistent hängt sich an dieser Stelle auf. Der Entwickler gestand nach einem kleinen Schriftwechsel denn auch ein, dass es da ein Problem gebe und er den Assistenten wohl überarbeiten müsse.

Damit man mir wirklich, wirklich keine Ungeduld vorwerfen kann, habe ich dem Einrichtungsassistenten beim letzten Versuch zwei Stunden Zeit gegeben – ohne Erfolg. Im Fehlerprotokoll konnte ich anschließend sehen, dass der Assistent schon nach wenigen Sekunden steckengeblieben war. Wenn es also nach – sagen wir mal – zwei, drei Minuten nicht weitergeht, kann man den Assistenten gefahrlos abbrechen und die verbleibenden Schritte von Hand vornehmen.

Der erste ist das Aktivieren von OpenPGP pro Postfach. Dazu öffne ich die Kontenverwaltung und sehe dort einen neuen Eintrag „OpenPGP-Sicherheit“. Den wähle ich aus und aktiviere rechts „Aktiviere OpenPGP-Unterstützung“. Im Screenshot sieht man auch die übrigen Einstellungen, die ich gewählt habe:

Anschließend kehre ich ins Hauptfenster zurück, blende mit der Alt-Taste die Menüleiste ein und öffne das Enigmail-Menü:

Sollte ich hier nur ein drastisch verkürztes Menü mit zwei Einträgen sehen, liegt das daran, dass ich – siehe voriger Schritt – PGP für keines meiner Postfächer aktiviert habe.

Schlüssel verwalten: Importieren…

Im Menü wähle ich nun den Punkt „Schlüssel verwalten“, da ich Thunderbird ja noch meine Schlüssel mitteilen muss, die ich bei mailbox.org erstellt und heruntergeladen habe. Wer das nicht getan hat – ist nicht schlimm – in der Schlüsselverwaltung kann man auch Schlüsselpaare erstellen. Das ist sogar die bessere Alternative, denn dann kennt wirklich niemand außer mir meinen privaten Schlüssel (unter der Voraussetzung, dass mein Computer nicht kompromittiert ist…).

Apropos Schlüssel von mailbox.org herunterladen: die Schlüssel erhalte ich von mailbox.org als unverschlüsselte Textdatei. Die kann ich kurz abspeichern, um sie in Enigmail einzulesen – dauerhaft auf meiner Festplatte speichern sollte ich sie nicht. Besser aufgehoben sind sie in einem Passworttresor wie KeePass.

Sind die Schlüssel importiert, empfiehlt es sich, die Schlüsseleigenschaften zu prüfen (Rechtsklick auf den Schlüssel>Schlüsseleigenschaften). Der unterste Wert „Sie verlassen sich auf Zertifizierungen“ sollte auf „absolut“ gesetzt werden – ich habe diesen Schlüssel ja selbst importiert, daher habe ich volles Vertrauen. Lasse ich diesen Schritt weg, wird mir mein eigener Schlüssel an anderer Stelle unter Umständen als nur bedingt vertrauenswürdig angezeigt.

…oder in Thunderbird erzeugen lassen.

Habe ich noch kein Schlüsselpaar, klicke ich oben auf Erzeugen>neues Schlüsselpaar, wähle das gewünschte Mailkonto aus und vergebe eine Passphrase. Das erhöht die Sicherheit weiter, denn dann kann der private Schlüssel erst nach Eingabe dieser Passphrase genutzt werden. Fiele also jemand mein Thunderbird-Profil in die Hände (ja, es soll noch Menschen geben, die ihre Datensicherung nicht verschlüsseln…), kann er ohne Passphrase trotzdem keine Mails entschlüsseln.

Das Ablaufdatum habe ich mal zehn Jahre in die Zukunft gesetzt – welche Schritte danach notwendig sind, weiß ich ehrlich gesagt noch nicht genau.

Zu guter Letzt habe ich mir unter dem Menüpunkt „Erzeugen“ der Schlüsselverwaltung noch ein Widerrufszertifikat pro Schlüsselpaar erstellt. Auch das ist ein zweischneidiges Schwert, wie openpgp-schulungen.de erklärt. Einerseits kann ich damit mein Schlüsselpaar im Notfall (wenn es in falsche Hände geraten ist) unwiderbringlich zerstören. Andererseits kann das auch jeder tun, dem dieses Zertifikat in die Hände fällt – und mir damit gehörigen Ärger einbrocken. Diesen Schritt im Zweifel also weglassen – und ansonsten das erzeugte Zertifikat in einem Passwort-Safe wie KeePass verwahren.

Schlüssel veröffentlichen

Geschafft! Wenn alles geklappt hat, kann ich jetzt verschlüsselte Nachrichten senden und empfangen. In der Praxis wird mir aber niemand solche Nachrichten schicken, weil mein öffentlicher Schlüssel nicht bekannt ist. Und auch ich kenne ja von niemandem den öffentlichen Schlüssel. Enigmail bietet daher an, meinen öffentlichen Schlüssel künftig an jede versandte Mail anzuhängen – so verbreitet sich der Schlüssel allmählich in meinem Bekanntenkreis. Das ist aber eine ziemliche Gießkannenmethode: der Schlüssel wird ungefragt an jede Mail angehängt und bläht diese auf. Auch wer den Schlüssel bereits hat oder überhaupt nicht haben will, bekommt ihn von mir zugeschickt – wieder und wieder.

Die bessere Alternative ist die Veröffentlichung auf einem Keyserver. Auch da wird es wieder verwirrend, denn davon gibt es nicht nur einen. Ich habe meine Schlüssel notgedrungen mal bei den ersten dreien hochgeladen, die mir begegneten:

Ein Absender, der PGP konfiguriert hat und mir eine Nachricht schicken will UND einen dieser Keyserver nutzt, sollte also nichts weiter tun müssen: sein Mailclient findet meinen öffentlichen Schlüssel und verschlüsselt seine Nachricht damit. Gelingt dies nicht, muss ich ihm meinen öffentlichen Schlüssel doch manuell zukommen lassen (oder den Schlüssel auf weiteren Keyservern veröffentlichen – Hinweise nehme ich gerne entgegen).

Die Keyserver brauchen einen Moment, um den hochgeladenen Schlüssel zu verarbeiten. Also etwas Geduld, falls der hochgeladene Schlüssel nicht gleich gefunden wird.

Uuuund… Test.

Wer noch kein Gegenüber zum Testen hat, kann auf den GPG-Test von PHPGangsta zurückgreifen. Dazu erstelle ich in Thunderbird eine neue Mail. Empfänger ist gpgtest@phpgangsta.de, Betreff „REQUEST MAIL“. So wie ich Thunderbird konfiguriert habe, wird diese Nachricht zunächst nur signiert, nicht verschlüsselt. Das ist für diesen Test okay. Um die Nachricht zu signieren, fragt Thunderbird vor dem Versenden die Passphrase meines Schlüssels ab. Damit er das nicht all zu häufig tut, kann man unter Enigmail>Einstellungen>Passphrasen-Ablaufzeit einen höheren Wert eintragen – der Standard von fünf Minuten ist recht lästig.

In einem zweiten Schritt kann ich dem Test-Bot eine verschlüsselte und/oder signierte Nachricht schicken. Dazu verwende ich den selben Adressaten mit dem Betreff „DECRYPT AND CHECK“. Da ich diesem Empfänger noch nie eine verschlüsselte Nachricht geschickt habe, aktiviere ich diese Option im Mail-Fenster explizit: Enigmail>Nachricht verschlüsseln. Beim Klick auf „Senden“ öffnet Thunderbird ein neues Fenster mit dem Hinweis, dass für gpgtest@phpgangsta.de kein gültiger Schlüssel gefunden wurde (an meinem lokalen Schlüsselbund). Mit dem Button „fehlende Schlüssel herunterladen“ kommen die Keyserver ins Spiel.

Voreingestellt ist keys.openpgp.org – aber Fehlanzeige, dort gibt es keinen passenden Schlüssel. Beim zweiten Server – pgp.mit.edu – erhoffe ich mir mehr, denn das ist auch der Server, den der Test-Bot standardmäßig nutzt. Dort erhalte ich allerdings einen Timeout. Beim dritten Server – hkps.pool.sks-keyservers.net – habe ich schließlich Erfolg. Also den aktuellsten Schlüssel auswählen, herunterladen und Klick auf „Schlüsselliste aktualisieren“ (Oh Mann!). Jetzt wird der passende Schlüssel gefunden und ich darf endlich, endlich auf „Absenden“ drücken.

Bei meinen Tests hat der Test-Bot auf sämtliche Nachrichten mit „Error while parsing mail“ geantwortet. Ich dokumentiere es hier trotzdem, weil das Verfahren bei einem echten Empfänger im Grunde das gleiche ist: neue Mail öffnen, Signieren und/oder Verschlüsseln auswählen, gegebenenfalls öffentlichen Schlüssel suchen. Und ich dokumentiere es, weil es zeigt, womit man sich auch im Jahr 2019 beim Mail-Verschlüsseln herumschlagen muss…

Henne und Ei

Jetzt weiß immer noch niemand, dass ich verschlüsselte Mails empfangen kann. Ein bisschen Mundpropaganda hier, ein paar Tests mit Geek-Freunden da… Und als Ergänzung signiere ich ab sofort alle meine ausgehenden Mails mit meinem privaten Schlüssel. Damit kann ich zumindest (Eingeweihte) diskret darauf hinweisen, dass ich so Verschlüsselungssachen kann.

Das Signieren einer Mail ist nicht zu verwechseln mit der Mail-Signatur, mit der man die eigene Telefonnummer oder Bitte-drucken-sie-diese-Mail-nicht-aus-sie-wissen-schon-die-Umwelt! unter jede ausgehende Mail pappt. Signieren ist vielmehr das elektronische Pendant zu einer Unterschrift – es bestätigt dem Empfänger, dass diese Nachricht wirklich von *mir* kommt. Natürlich nur mittel-aussagekräftig, denn es ist etwas selbstreferenziell: weil ich den Schlüssel selbst erstellt habe, bestätige ich mir selbst, dass ich ich bin. Erst wenn mein Gegenüber meinen öffentlichen Schlüssel importiert und sicherstellt, dass er diesen tatsächlich unverändert von mir erhalten hat, gewinnt die Sache an Aussagekraft:

Nach dem Import des Schlüssels empfiehlt es sich also, die Schlüsselverwaltung zu öffnen, die Eigenschaften des Schlüssels zu öffnen und rechts auf das unscheinbare „Z“ zu drücken:

Darauf öffnet sich ein Fenster, das aus dem echten Leben inspiriert scheint: Hand aufs Herz – wie genau haben sie das jetzt eigentlich geprüft mit der Echtheit des Schlüssels?

Was lernen wir jetzt aus all diesen Klimmzügen? Eine Gruppe von Security-Experten fasst es im Juli provokant folgendermaßen zusammen: „PGP ist schlecht und sollte verschwinden“. Ich bin nach diesem langen Bericht zugegebenermaßen auch etwas ernüchtert. Ja, es bringt mehr Sicherheit (wenn man nicht einen der vielen möglichen Fehler begeht). Dafür ist es ziemlich kompliziert. Und – Henne/Ei – mir fehlt aktuell der Anwendungsfall. Wenn ich Passwörter übermitteln will, nutze ich tatsächlich sichere Chats auf Signal oder Telegram. Aber wer weiß, wofür es noch nützlich sein wird… Feedback willkommen!

9 Antworten auf „Mailverschlüsselung mit Thunderbird, der x-te Anlauf“

  1. Wenn von Mail-Verschlüsselung die Rede ist wird leider meist nur von PGP gesprochen. Meiner letzten Erfahrung nach (ja, sie liegt ein paar Jährchen zurück) konnte zumindest Outlook von Haus aus mit S/MIME umgehen – somit entfällt das für Laien schwer verständliche Installlieren von Plugins etc. Auch Thunderbird scheint das bereits intus zu haben: https://www.thunderbird-mail.de/lexicon/entry/80-e-mail-verschl%C3%BCsselung-mit-s-mime/
    Und btw. nicht nur mailbox.org + posteo.de sind die Guten, auch web.de und GMX haben schon länger eine Verschlüsselung in petto – sehr innovativ für solch große Anbieter, wie ich finde. Kommt schätzungsweise daher, dass sie Open Xchange verwenden als Kundenbackend.

    1. Danke Micha.
      Tja, dann vielleicht gelegentlich noch mal ein Test mit S/MIME…
      Dass web.de und GMX auch Verschlüsselung beherrschen stimmt – mir ging es bei dieser Empfehlung generell darum, wie sehr ich mich mit den Werten dieser Unternehmen identifizieren kann (oder vielmehr: die mit meinen?). Die unerträgliche Startseite der beiden etwa – prallvoll mit Werbung und Verdummungs“nachrichten“ – kann man selbst als zahlender Kunde nicht umgehen. Da sind mir die genannten tausendmal lieber, die sich ihre Dienstleistung von mir bezahlen lassen und mich im Gegenzug in Ruhe lassen. Und auch sonst sind posteo und mailbox.org ja meilenweit vorne, was Privatsphäre-Schutz angeht, aber das wolltest du ja vermutlich gar nicht in Zweifel ziehen.

  2. Danke für deinen sorgfältigen Bericht! Großartig.

    * Die unterschiedlichen Bezeichnungen (Open)PGP und GnuPG gehen leider auf ein paar unschöne Geschehnisse zurück (z.B.: https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_investigation -> crypto-Export-Gesetze der USA, aber es gibt auch noch die Problematik um Freie Software oder nicht).

    * Auch die FSF hat eine gute Beschreibung bzgl. E-Mail-Verschlüsselung und betreibt einen Service um das Setup zu testen (ähnlich wie bei phpgangsta eine e-Mail-Adresse, edward-de@fsf.org ): https://emailselfdefense.fsf.org/de/ .

    * phpgangsta habe ich mal kontaktiert, meine Tests sind auch fehlgeschlagen. Und anstatt den keyserver zu befragen hättest du auf der Seite selber den richtigen Schlüssel herunterladen können.

    * S/Mime hat meines Wissens das „Problem“ der trusted root authorities, du musst also irgendwann einmal einer Entität volles Vertrauen aussprechen (system-immanent).

  3. Und für den Mac OS Nutzer, der mit Mail arbeitet geht es so:
    GPG Tools installieren, https://gpgtools.org/ (30 Tage Trial, dann ca. 25€ einmalig (wars mir jetzt mal wert, geht vermutlich auch anders))
    Installieren und mit GPG Keychain einen eigenen Schlüssel kreieren.
    Den öffentlichen Teil des Schlüssels hochladen, damit andere dich finden können (GPG Keychain fragt nach ob man das möchte)
    Unter Mail/Einstellungen/Allgemein unten links „Plug-Ins verwalten“ anclicken und GPG aktivieren
    Mit GPG Keychain oder z.B. hier https://keyserver1.pgp.com/vkd/GetWelcomeScreen.event kann man dann die öffentlichen Schlüssel der anderen suchen.
    Bekommt man einen Schlüssel von einer Freund*in geschickt, kann man den entweder direkt importieren oder aber den Text in die Zwischenablage kopieren (GPG Keychain merkt das und fragt nach) und schon steht einem der Schlüssel zur Verfügung.
    Das war es eigentlich schon. Wenn man jetzt eine E-Mail schreibt, zeigt Mail recht oben ein offenes Schloss an. Mit einem Click das Schloss verschliessen und schon schickt man verschlüsselt. YES we can!

    Good Luck & lasst nicht locker. Habe mich auch lange davor gedrückt, aber Edward Snowdens Buch Permanent Record hat mich noch mal richtig wach gerüttelt!!!

  4. Ich wurde darauf hingewiesen, dass meine signierten Mails auf Android-Geräten praktisch nicht lesbar sind. Aus unerfindlichen Gründen stellen diese Smartphones den Text in irrwitzig kleiner Schrift dar. Vergrößern per Pinch-Zoom-Geste ist nicht möglich. Daher habe ich das Signieren meiner ausgehenden Mails wieder abgeschaltet.

Kommentare sind geschlossen.