Ob private oder betriebliche Kommunikation – das Unbehagen wächst. Denn Geheimdienste und Mitbewerber trachten danach, aus dem Urgestein E-Mail eine sprudelnde Quelle abzuschöpfen. Der Schwerpunkt dieser Ausgabe informiert über mögliche Gegenmaßnahmen. Los geht es mit verschlüsselnden Clients.

Die langen Stehtische haben dicke Holzplatten, es gibt genug leckeres Fingerfood für alle, die Getränke sind frei, und an einer der dunkelroten Wände zischt ein Kaffeeautomat, wenn Gäste der kostenlosen Veranstaltung auf einen der Knöpfe drücken. Vor dem Vortragsraum im Münchner Hotel “Courtyard by Marriott City Center” (Zimmer ab 160 Euro pro Nacht) sorgen Kellner dafür, dass keine Annehmlichkeit versiegt.

Der Rahmen könnte der einer Verkaufsveranstaltung für dubiose Immobilienfonds sein. Ist er aber nicht, denn eine Stunde zuvor hatten drei Entwickler ihre Mail-Projekte LEAP [1] und Pixelated [2] vorgestellt. Ihr Arbeitgeber, die IT-Firma Thoughtworks [3], bezahlt diese drei und acht weitere Developer in Hamburg sowie im brasilianischen Porto Alegre seit Anfang 2014 und plant wohl, dies weitere eineinhalb Jahre zu tun. Die Rechnung des Abends (der in mehreren europäischen Städten wiederholt wird) begleicht sie auch – und das, obwohl die Entwickler beteuern, dass Thoughtworks kein kommerzielles Produkt um LEAP und Co. plane. Willkommen auf dem Sonnendeck der Open-Source-Szene!

Christoph Klünter, Lisa Junger und Folker Bernitt – so heißen die drei – erklären das intensive Engagement ihres Arbeitgebers: An normalen Tagen passieren 196 Milliarden E-Mails das Internet, und nur sehr wenige davon sind verschlüsselt. Der Rest ist Freiwild für Geheimdienste und Industriespione. Hinzu kommt, dass sich in fast allen Ländern der Mailverkehr auf wenige Provider konzentriert, was die zum lohnenden Objekt für Cyberangriffe und staatliche Eingriffe macht.

Wer als Gegenmaßnahme seine Mails Ende-zu-Ende-verschlüsselt, ist überraschenderweise nicht völlig aus dem Schneider. Weil der Anteil gecrypteter Nachrichten so gering ist, fallen diese nämlich über die Gebühr auf. Mitlauschende Geheimdienste erfassen die unverschlüsselten Header solcher Mails als weiße Raben besonders genau, weil sie annehmen, Absender und Empfänger haben etwas zu verbergen.

Weich gebettet: LEAP, Bitmask und Pixelated

Die Thoughtworks-Leute wollen etwas dazu beitragen, die Situation zu verbessern. Zum einen möchten sie die länderweisen Quasimonopole der Mailprovider aufweichen, indem sie kleineren Firmen und Privatanwendern die technische Möglichkeit an die Hand geben, selber als (verschlüsselungsfreundlicher) Provider aufzutreten. Zum anderen versuchen sie den alten Konflikt zwischen Sicherheit und Usability zu entschärfen, an dem PGP und Gnu PG seit jeher leiden: Aktuelle Schlüssellängen vorausgesetzt, gelten beide Verfahren als sicher – wenn man davon absieht, dass sie den Mailheader im Klartext belassen.

Doch in der praktischen Ende-zu-Ende-Verschlüsselung erweisen sie sich als aufwändig zu handhaben, weshalb die wenigsten Benutzer sie verwenden. Viele verstehen schon das Prinzip von Private und Public Key nicht, andere sind mit dem Erzeugen und Hochladen der Schlüssel überfordert und vielen ist das ständige Eintippen der Passphrase zu viel. Zum Teil in Mailprogramme integrierte Frontends wie der GNU Privacy Assistant (GPA), Seahorse oder Kgpg versuchen den Nutzungsgrad zu heben, erreichen dieses Ziel aber nicht im ausreichenden Maße.

Der Ansatz der gut unterfütterten Thoughtworks-Entwickler nimmt prinzipbedingte Sicherheitsschwächen in Kauf, um die Benutzbarkeit drastisch zu vereinfachen. Ihre pragmatische Rechnung: Das Mitlesen soll für Angreifer aufwändiger und damit teurer werden als dies bei Plaintext-Mails der Fall ist. Die benutzte LEAP-Plattform [1] bietet ein Set aus einem gehärteten Debian, Debian-Paketen und Puppet-Modulen an, welche die Infrastruktur eines sicheren Kommunikations-Serviceproviders bereitstellen und dessen Betrieb aufrecht erhalten. Diese Serverkomponente könnte bei einem Dienstleister arbeiten – dem man dann vertrauen muss –, oder man installiert sie als virtuelle Maschine im eigenen Netz.

LEAP speichert eingehende Plaintext-Mails verschlüsselt, sodass sie ab diesem Zeitpunkt nur der Empfänger lesen kann. Passt ein öffentlicher Schlüssel zur eingehenden Mail, erkennt LEAP dies automatisch und validiert die Mail. Für die Benutzerseite haben die LEAP-Macher den Linux-Client Bitmask [4] im Köcher. Klünter, Junger und Bernitt empfehlen an dem Abend jedoch ihre Webapp Pixelated [2]. Wie jedem Webclient lastet der App aber der Makel an, dass ein Server die Private Keys der Nutzer speichert. Angesichts der Entwicklerressourcen und der hehren Motive verdient das Projektebündnis jedoch Aufmerksamkeit.

Vordiktiert: PEP

Das Projekt Pretty Easy Privacy (PEP, [5]) will ähnlich dem Thoughtworks-Projekt oder Dime (vormals Darkmail, siehe Extra-Artikel hier im Schwerpunkt) die Ver- und Entschlüsselungsmechanismen vom Benutzer abkoppeln. PEP fußt nicht auf dem Web of Trust mit klassischen Keyservern, sondern verifiziert die Schlüssel mit englischen oder deutschen Wortgruppen, die sich gut am Telefon diktieren lassen (Abbildung 1). Den Key setzt PEP aus entropiereichen Quellen des Benutzers zusammen.

Die PEP-Engine ist freie Software – jeder darf und soll sie in seinen Messaging-Client einbauen. Dass der erste unterstützte Client auf den Namen Outlook hört, folgt Marktgegebenheiten, bringt aber Linuxer nicht weiter. Der im schweizerischen Winterthur lebende Entwickler Volker Birk wirbt daher um Geduld: “Die Dinge gehen nur nicht alle auf einmal. PEP liegt bisher ja nur in einer Preview vor. Auch sind wir nur eine kleine Gruppe von Leuten, die dafür umso engagierter daran arbeitet.”

Die wenigen Ressourcen halten Birk nicht vom Blick in die Zukunft ab: “Ich komme gerade vom W3C-Workshop zurück. Da geht es um die Browser-Plugins für Webmailer … Wir werden gerade an die IETF weitergereicht, um die Synchronisationsprotokolle zu standardisieren.” Er selbst programmiert zurzeit an der Android-Version, einem Fork von K-9. Eine erste Testversion will er bis Ende 2014 fertigstellen. Birk plant einen Patch für den Mailclient Mutt, den er selbst nutzt. Irgendwann danach will er eine Lösung für Thunderbird finden. Zudem habe das Kolab-Projekt angekündigt, PEP zusammen mit der nächsten Major-Release auszuliefern, Kontact also fit dafür zu machen (siehe unten).

Während LEAP, PEP oder Dime noch nicht produktiv einsetzbar sind, mühen sich einige große und kleine Webhoster schon länger, auf Privatsphäre und Sicherheit bedachte Benutzer zufrieden zu stellen. Nicht dazu zählen allerdings Google, Yahoo und GMX, letzterer Dienst gibt in seiner Online-Hilfe immerhin eine Kurzanleitung für Thunderbird.

Abbildung 1: Pretty Easy Privacy verifiziert die Schlüssel initial mit englischen oder deutschen Wortgruppen, die sich gut am Telefon diktieren lassen.

Unverschlüsselt: Kolab

Kolab Systems bietet mit My Kolab.com [6] eine gehostete Groupware an. Die darin verwalteten Daten lagern laut Anbieter zwar “sicher geschützt in einem Rechenzentrum in der Schweiz”, E-Mails chiffrieren kann der Webclient jedoch nicht. Wer seine Nachrichten verschlüsseln möchte, muss folglich zu einem fähigen lokalen Mailclient greifen, Kolab Systems empfiehlt Kontact oder Thunderbird mit Enigmail.

Auch wer selbst einen Kolab-Server aufsetzen möchte, benötigt einen Desktop-Client: Der standardmäßig eingerichtete Webmailer Roundcube kann ebenfalls keine E-Mails chiffrieren. Erst in einer der kommenden Versionen wollen die Roundcube-Entwickler eine S/MIME- und Open-PGP-Unterstützung integrieren. Zwar existieren bereits Plugins, die eine Verschlüsselungsfunktion nachrüsten, die Firma legt diese Erweiterungen jedoch nicht bei.

Den Grund verrät Georg Greve, CEO von Kolab Systems, gegenüber dem Linux-Magazin: “Alle uns bekannten Methoden erlauben immer auch die Kompromittierung des Schlüssels. Entweder wird er direkt auf dem Server abgelegt oder über das HTML-5-Storage für die Webanwendung zugreifbar. Beides ist aber nach unserer Einschätzung nicht gut genug und erlaubt es, den Schlüssel direkt zu kompromittieren. Das wiederum ist schlechter als nicht zu verschlüsseln, weil die Erwartungshaltung des Nutzers zum Zeitpunkt der Verschlüsselung eine andere ist. Kolab empfiehlt daher die Verschlüsselung auf dem Desktop.” Langfristig möchte Kolab Systems jedoch auch eine Verschlüsselung im Webclient anbieten. Das Unternehmen prüft dazu derzeit verschiedene Konzepte, zu denen auch PEP (siehe oben) gehört. Wann eine Umsetzung mit welcher Lösung erfolgt, konnte Georg Greve noch nicht sagen und widerspricht damit PEP-Mann Volker Birk indirekt.

Altgedient: Web.de Mail

Das kostenlose Postfach bei Web.de verschlüsselt auf Wunsch E-Mails nach dem S/MIME-Standard mit X.509-Zertifikaten. Wer bei Web.de ein Postfach anlegt, erhält automatisch ein eigenes Zertifikat. Die Verschlüsselung einer E-Mail läuft besonders einfach zwischen zwei Web.de-Nutzern ab: Zunächst senden sich beide Gesprächspartner eine signierte E-Mail. Web.de importiert dann automatisch den Schlüssel aus dem dabei angehängten X.509-Zertifikat des Gegenübers. Der Verfasser einer E-Mail muss dann in seinem Webclient nur noch die Verschlüsselungsart einstellen: RC2 mit 128 Bit Schlüssellänge, 3DES mit 168 Bit oder AES mit 265 Bit (Abbildung 2).

Den ganzen Ablauf versteckt der Webclient vor seinen Anwendern. Die X.509-Zertifikate beziehungsweise Schlüssel erzeugt das Web.de Trustcenter. Anwender müssen dem Dienst allerdings vertrauen, denn theoretisch könnte Web.de nicht nur E-Mails unbemerkt entschlüsseln, sondern auch die Identität des Anwenders annehmen und von ihm signierte E-Mails verschicken. Über die Einstellungen kann der Anwender sein X.509-Zertifikat immerhin als P12-Datei herunterladen. Sofern die E-Mail an ein Konto bei Web.de, T-Online, GMX oder Freenet gerichtet ist, nutzt Web.de einen verschlüsselten Übertragungsweg. Wie die Verschlüsselung und der Versand dabei genau ablaufen, verraten die Maildienste allerdings nicht.

Abbildung 2: Auf Anhieb erkennen Anwender bei Web.de nicht, welches Verschlüsselungsverfahren sich hinter welcher Einstellung verbirgt. Anders als mancher Mitbewerber macht sich der große Provider aber wenigstens Gedanken um Vertraulichkeit.

Rumberlinert: Mailbox.org

Den Dienst Mailbox.org [7] betreibt die in der Linux-Szene bekannte Berliner Heinlein GmbH. Das Unternehmen wirbt mit einem Serverstandort in Berlin, der Einhaltung deutscher Datenschutzgesetze und einer Verschlüsselung. Das letzte Versprechen kann der Dienst jedoch nur teilweise einlösen. So chiffriert Mailbox.org wie LEAP auf Wunsch alle E-Mails mit dem Public Key des Users. Auf dem Mailbox.org-Server liegen damit ausschließlich chiffrierte Nachrichten, auf dem Weg im Internet laufen sie aber weiterhin im Klartext, und der Kunde braucht ein gewisses Vertrauen zu den Admins des Betreibers. Und es gibt noch einen anderen Haken: Speichert ein E-Mail-Client eine gerade versendete E-Mail im »Sent« -Ordner auf dem Server, bleibt sie dort unverschlüsselt liegen. Mailbox.org arbeitet nach eigenen Angaben an diesem Problem.

Um die automatische Verschlüsselung zu aktivieren, müssen User nur ihren Public Key hochladen. In Zukunft möchte Mailbox.org zusätzlich den Private Key auf seinen Servern speichern. Die Ver- und Entschlüsselung könnte damit zwar automatisch geschehen, der Anwender gibt jedoch seinen Private Key in fremde Hände. Mailbox.org hätte dann nicht nur Zugriff auf den E-Mail-Verkehr, sondern müsste etwa auf Anweisung durch Gerichte die E-Mails herausgeben.

Beim Versand einer E-Mail versucht Mailbox.org einen verschlüsselten Kanal zum Empfänger aufzubauen. Das funktioniert allerdings nur, wenn auch das Gegenüber mitspielt. Den gesicherten Versand dürfen Nutzer sogar erzwingen. Die Zustellung scheitert dann, wenn der Empfänger keine Verschlüsselung erlaubt. Experten wählen sogar zwischen verschiedenen Sicherheitsstufen und gestatten beispielsweise die Zustellung nur an Empfänger mit einem validen DANE-Record-Eintrag. In der Praxis müssen Anwender jedoch häufig E-Mails an nicht entsprechend abgesicherte Postfächer versenden. Wer mit Mailbox.org verschlüsselte E-Mails austauschen möchte, kommt somit unter dem Strich nicht um einen lokalen Mailclient herum. Zu einem solchen rät sogar Mailbox.org in seiner Onlinehilfe.

Aufgepfropft: Mailpile

Wessen Mailprovider im Web nicht verschlüsselt, kann auf Mailpile [8] ausweichen. Dieser in Python geschriebene Webmailclient funktioniert ähnlich wie Roundcube: Anwender starten Mailpile auf einem eigenen Server oder dem PC und greifen mit dem Browser darauf zu (Abbildung 3). Gegenüber dem E-Mail-Provider verhält sich Mailpile wie ein lokaler Mailclient. Im Gegensatz zu Roundcube bietet Mailpile fest integrierte und einfach zu nutzende Verschlüsselungsfunktionen. Um eine E-Mail zu verschlüsseln, genügt etwa in der »Compose« -Ansicht ein Klick auf das entsprechende Symbol.

Zum De- und Chiffrieren nutzt Mailpile den Open-PGP-Standard und enkodiert die Nachricht, noch bevor es sie an den E-Mail-Dienst übergibt. Der kann folglich nicht mitlesen. Bei einem Einsatz auf einem Server könnte ein Angreifer diesen jedoch kompromittieren. Da Mailpile die Nachrichten mit Gnu PG verschlüsselt, wandert zudem der Klartext zwischen Browser und Mailpile-Server durch das Internet. Den Zugang zu Mailpile und somit dem eigenen Postfach schützt nur ein einfaches Passwort. Anwender müssen daher zusätzliche Sicherungsmaßnahmen ergreifen. Derzeit befindet sich Mailpile noch in der Betaphase, der Quellcode [9] steht wahlweise unter der GNU Affero General Public License oder der Apache License 2.0.

Abbildung 3: Mailpile ist ein zusätzliches Frontend für einen beliebigen nicht-verschlüsselnden E-Mail-Dienst.

Eingeklinkt: Web PG und Google End-to-End

Einen anderen Weg geht das unter der GPLv2 veröffentlichte Web PG [10]. Diese Erweiterung für Firefox und Chrome bindet Gnu PG in den Browser ein. Das versetzt Anwender in die Lage, direkt im Browser ihre Schlüssel zu verwalten und über das Kontextmenü der rechten Maustaste schnell Texte zu ver- und entschlüsseln.

Für den Artikel interessant ist Web PGs Gmail-Integration: Nach der Anmeldung bei Googles Webmailer klingt sich das Plugin wie in Abbildung 4 in die Weboberfläche ein. Über die zusätzlichen Buttons de- und chiffriert der Benutzer die Mails. Die Entwickler klassifizieren diese Integration zurzeit allerdings als experimentell, der Benutzer muss sie in den Web-PG-Einstellungen explizit freischalten. Des Weiteren tippen Anwender den Text zunächst im Klartext ein. Bei einer Zwischenspeicherung landet die Nachricht damit doch wieder unverschlüsselt auf den Google-Servern.

Die Oberfläche von Web PG ist äußerst übersichtlich gestaltet, Kenntnisse im Umgang mit Gnu PG benötigen Anwender nicht. Die Schlüsselverwaltung lässt kaum Wünsche offen: Schlüssel sind importier-, exportier- und mit Schlüsselservern abgleichbar. Anwender dürfen unter anderem das Ablaufdatum ändern und Unterschlüssel hinzufügen. Bei der Schlüsselerzeugung lässt Web PG die Wahl zwischen den Algorithmen DSA, RSA und El Gamel, Schlüssel sind 1024, 2048, 3072 oder 4096 Bits lang.

Abbildung 4: Web PG und ein Browserplugin verschaffen Gmail-Nutzern doch noch Gelegenheit, Nachrichten zu verschlüsseln.

Auch Google arbeitet derzeit an einer Erweiterung für Chrome. Die End-to-End [11] getaufte und der Apache License 2.0 unterworfene Software blendet auf Knopfdruck ein Fenster ein, in dem sich eine Nachricht de- und enkodieren lässt (wie in Abbildung 5). Innerhalb von Gmail dechiffriert die Erweiterung Nachrichten automatisch.

Die Ver- und Entschlüsselung übernimmt eine eigens für das Projekt neu entwickelte Javascript-Bibliothek, die dem Open-PGP-Standard folgt. Nach ihrer Installation generiert die Erweiterung automatisch einen Schlüssel, der Anwender muss lediglich seine E-Mail-Adresse eintippen. Schlüssel lassen sich im- und exportieren. Im Gegensatz zu Web PG befindet sich End-to-End noch in einer frühen Entwicklungsphase. Wer es einsetzen möchte, muss die Erweiterung selbst übersetzen. Darüber hinaus warnen die Entwickler vor Fehlern und Sicherheitslücken.

Abbildung 5: Googles End-to-End läuft nur im Chrome-Browser. Die Erweiterung ver- und entschlüsselt E-Mails in einem separaten Fenster.

Eingetütet: Mailvelope

Eine Alternative zu Web PG bietet Mailvelope (Abbildung 6, [12]). Diese Erweiterung für Firefox und Chrome befindet sich ebenfalls noch im Beta-Stadium, unterstützt aber weitaus mehr Webmailer als Web PG: Gmail, GMX, Microsoft (Mail.live.com), Posteo, Yahoo und Web.de. Sie arbeitet nach dem Open-PGP-Standard und untersteht der GNU Affero General Public License. Sie kann Schlüssel importieren, exportieren und erzeugen. Letzteres erfolgt grundsätzlich mit dem RSA-Algorithmus. Der Anwender wählt nur die Schlüsselgröße in den drei Stufen 1024, 2048 oder 4096 Bit.

Abbildung 6: Eine Nachricht per Mailvelope zu schreiben, geschieht in einem Extrafenster und ist etwas komplizierter gelöst als in Web PG.