Wissensdatenbank

Ende-zu-Ende-Verschlüsselung

OpenPGP-Schlüssel, im Browser erzeugt. Mail an eine andere OpenEmail-Adresse kann versiegelt werden, bevor sie den Tab verlässt, und versiegelte Mail öffnet sich im Lesebereich, entschlüsselt auf dem eigenen Gerät. Die Schlüssel gehören nie uns, wir können sie also nicht herausgeben.

Details

Beide Hälften sind durchgängig verdrahtet. Das Verfassen an eine Empfängerin, deren Schlüssel veröffentlicht ist, versiegelt den Text im Browser, bevor die Anfrage ihn verlässt; der Server bekommt eine Rüstung, die er nicht lesen kann, markiert sie als pgp-mime und baut eine echte multipart/encrypted-Nachricht. Das Lesen läuft umgekehrt genauso: Der Geheimtext wird geholt, im Tab entschlüsselt und als gewöhnliche Mail dargestellt.
Der Algorithmus ist der, den alle anderen bereits verwenden: OpenPGP über openpgp.js und PGP/MIME auf der Leitung. Ein v4-Schlüssel auf Curve25519, dieselbe Form, die Proton ausstellt und die gpg mit seinem standardmäßigen modernen Algorithmus erzeugt. Die Mail, die das hier liest, ist im Prinzip also dieselbe Mail, die Thunderbird, gpg und Proton erzeugen, und nichts hier ist ein eigenes Format, das später aufgedröselt werden müsste.
In der Praxis ist es allerdings OpenEmail zu OpenEmail. Es gibt in diesem Code kein Web Key Directory, keine Keyserver-Abfrage und kein Parsen von Autocrypt-Headern: Der einzige Ort, an dem der Schlüssel einer Empfängerin je gefunden wird, ist unser eigenes Verzeichnis, das aus dieser App veröffentlichte Schlüssel von Menschen hält, deren Adresse auf einer hier gehosteten Domain liegt. Es gibt auch keinen Weg, Ihren Schlüssel herauszugeben. Die App veröffentlicht Ihre öffentliche Hälfte in dieses Verzeichnis und bietet weder Kopie noch Export davon, ein Korrespondenzpartner auf Thunderbird hat also keinen unterstützten Weg, an ihn zu kommen. Mit der weiteren PGP-Welt zusammenzuarbeiten ist eine Eigenschaft des Formats und noch nichts, was das Produkt für Sie erledigt.
Das Lesen ist nicht so begrenzt, denn das Entschlüsseln braucht kein Verzeichnis. Jede PGP/MIME- oder Inline-PGP-Nachricht, die dieses Postfach versiegelt an einen Schlüssel in diesem Browser erreicht, öffnet sich, wer sie auch gesendet und welchen Client er benutzt hat. Dazu gehören Nachrichten, die an einen Schlüssel versiegelt wurden, von dem Sie inzwischen rotiert sind: Ausgemusterte Schlüssel bleiben im Schlüsselbund und werden neben dem aktuellen mitprobiert, das Rotieren kostet Sie also nicht die bereits empfangene Mail.
Grün heißt geöffnet, und es ist auf keinem anderen Weg erreichbar. Die Zeile Details → Sicherheit wird erst grün, nachdem eine Entschlüsselung in diesem Tab tatsächlich Klartext zurückgegeben hat, nie aus einem Feld an der Nachricht, nie aus der Tatsache, dass ein verschlüsselter Umschlag eintraf. Sie lautet „Ende-zu-Ende-verschlüsselt. Mit Ihrem Schlüssel in diesem Browser geöffnet“. Alles darunter hat seinen eigenen Satz statt eines gemeinsamen: wird noch gesucht, Schlüssel gesperrt, an einen Schlüssel versiegelt, den dieser Browser nicht hält, konnte nicht geöffnet werden, hier überhaupt kein Schlüssel, und dieser Browser hat uns nicht nachsehen lassen. „Wir konnten es nicht prüfen“ und „Sie haben den Schlüssel nicht“ sind verschiedene Aussagen, und die Zeile zwingt Sie zu lesen, welche Sie bekommen haben.
S/MIME lässt sich weiterhin nicht öffnen. Es ist CMS unter einem X.509-Zertifikat, openpgp.js kann es nicht anfassen, und es gibt im Produkt keinen Zertifikatsspeicher, der den Schlüssel hielte, falls es das könnte, eine S/MIME-Nachricht sagt deshalb, dass OpenEmail sie nicht öffnen kann, und ihr wird keine Entsperrung angeboten, die nichts bewirken würde.
Die private Hälfte wird in Ihrem Browser erzeugt und verlässt ihn nie: nicht verschlüsselt, nicht in einem Backup, nicht in einem Support-Werkzeug. Der Server bekommt sie nie, es gibt hier also nichts herauszugeben, vorzuladen oder zu verlieren. Sie liegt passphrasengesperrt in einer eigenen IndexedDB-Datenbank, openemail-keyring, bewusst außerhalb der Reichweite des Rats „leeren Sie Ihren Cache“ und des Zurücksetzens in der Debug-Konsole: Beide löschen den Query-Cache, und ein daneben gespeicherter Schlüssel würde aus einem Routine-Support-Rat die dauerhafte Vernichtung jeder verschlüsselten Nachricht machen, die das Konto je erhalten hat. Ihr Konto zu löschen löscht ihn sehr wohl, denn dann geht die Mail ohnehin mit. Ihn zu entsperren hält ihn 15 Minuten ohne Aktivität und höchstens 8 Stunden im Speicher, danach fragt das Lesen der nächsten versiegelten Nachricht wieder nach der Passphrase.
Es gibt kein Escrow und keine Wiederherstellung, und das ist endgültig und nicht bloß ungebaut. Ihre Passphrase ist der einzige Weg hinein; vergessen Sie sie, bleibt jede Nachricht, die irgendjemand an Sie versiegelt hat, als Geheimtext auf unseren Servern liegen, den niemand lesen kann, wir eingeschlossen. Die Mail ist weg, und kein Nachfragen holt sie zurück. Der Einrichtungsbildschirm sagt das, bevor der erste Schlüssel existiert, hinter einem Häkchen, das Sie setzen müssen, und die Backup-Datei ist Pflicht, und die Schaltfläche Fertig bleibt deaktiviert, bis Sie sie heruntergeladen haben. Diese Datei wird bewusst ohne die zusätzliche Härtung im Ruhezustand geschrieben, die dieser Browser verwendet, damit sie sich weiterhin in ältere gpg-Builds importieren lässt: Ein Backup, das Sie anderswo nicht öffnen können, ist kein Backup. Der Schlüssel lebt außerdem in einem Browser auf einem Gerät, und ein Telefon oder ein zweiter Laptop hat nichts, bis Sie diese Datei dort importieren.
Das Verzeichnis hält öffentliche Schlüssel und sonst nichts, und ein Schlüssel gehört zu einer Person und nicht zu einem Postfach, denn einer, der an einer Adresse hinge, müsste zwischen allen kopiert werden, mit denen diese Adresse geteilt ist, und das ist Escrow unter anderem Namen. Einen nachzuschlagen braucht eine angemeldete Sitzung und die Berechtigung zum Senden, nie einen öffentlichen Endpunkt, denn ein offenes Abtasten von Adressen ist ein Orakel, das jedem verrät, welche Adressen hier lebende Postfächer sind. Es antwortet auf „wir hosten das nicht“ und „wir hosten es, und niemand hat einen Schlüssel veröffentlicht“ identisch, denn die beiden unterscheidbar zu machen verschiebt das Orakel nur hinter eine Anmeldung, statt es zu beseitigen. Und ein Schlüssel wird in dem Moment nicht mehr herausgegeben, in dem seine Inhaberin den Zugriff auf die Adresse verliert, und nicht erst, wenn jemand daran denkt, ihn zu widerrufen.
Jedes Byte wird im Browser in dem Moment versiegelt, in dem Sie es schreiben, und genau das lässt den verzögerten Versand überhaupt funktionieren: Eine geplante Nachricht oder eine im Rückgängig-Fenster liegende wird als Geheimtext gespeichert und später von einer Queue versendet, die keinen Schlüssel hält und nichts davon lesen kann. Eine Empfängerin, deren Verzeichnisabfrage FEHLSCHLUG, blockiert den Versand, statt stillschweigend als schlüssellos behandelt zu werden. Und eine versiegelte Nachricht geht nur über einen Pfad hinaus, der eine Nachricht als Ganzes trägt. Ein ausgehender Pfad, der stattdessen einen HTML-Text entgegennimmt, würde die Rüstung als sichtbaren Text abschicken und Erfolg melden, ein Versand, der dort landen würde, wird deshalb abgelehnt, bevor ein Byte hinausgeht, und nicht danach.
Was das Versiegeln kosten wird, gemessen statt geraten: Die Rüstung ist etwa das 1,86-Fache der rohen Bytes, rund 2,7 MB Anhänge passen also in die 5 MB, die der Sendepfad erlaubt, und der Composer verweigert eine größere Nutzlast, bevor er Sekunden damit verbringt, eine zu verschlüsseln, die der Transport ablehnen würde. Verschlüsselte Mail meldet keine Öffnungen und keine Klicks, denn Tracking je Empfänger funktioniert, indem der Text je Person variiert wird, und ein versiegelter Block kann nicht variieren, und ein umgeschriebener Link ist ein Link, den wir lesen können, also das Gegenteil der Behauptung. Ein verschlüsselter Versand kann auch nie über einen Idempotency-Key dedupliziert werden: Ein frischer Sitzungsschlüssel macht den Geheimtext bei jedem Versuch zu anderen Bytes, ein erneuter Versuch hat also nie den Fingerabdruck seines Originals.
Das Planen versiegelt beim Verfassen, nicht beim Senden. Der Composer baut den Geheimtext gegen die Schlüssel, die seine Empfänger an dem Tag halten, an dem Sie schreiben, nicht an dem Tag, an dem die Nachricht hinausginge, also nach der Regel, die dieses Produkt bereits auf Vorlagen und Übersetzungen anwendet, wo eine geplante Nachricht das trägt, was Sie freigegeben haben, und nicht, was sich danach geändert hat. Der Unterschied ist, dass eine veraltete Vorlage lediglich nicht mehr aktuell und ein veralteter Schlüssel unlesbar ist, der Composer nennt das Datum deshalb in Worten, statt eine Einschränkung anzubieten: „Jetzt versiegelt, gesendet am …. Alle darauf brauchen den Schlüssel, den sie heute haben.“ Die Ablehnung, die die andere Hälfte absichert, ist gelandet und hat nie ausgelöst, weil es eine solche Nachricht noch gar nicht geben kann: Gäbe es sie, würde das nachträgliche Bearbeiten verweigert statt stillschweigend erlaubt, denn den Text zu patchen würde Klartext über den Geheimtext schreiben und die Empfänger zu ändern würde ändern, an wen versiegelt wurde, und beides stellt im Klartext zu, während jeder Bildschirm sie weiterhin verschlüsselt nennt.
Zwei Dinge wird der Composer gar nicht erst anbieten und sagt das, statt an der Leitung zu scheitern. Eine Vorlage wird auf dem Server aus einer veröffentlichten Version gerendert, in diesem Browser gibt es also nichts zu versiegeln. Eine Antwort zitiert die Unterhaltung darunter, und dieses Zitat wird angehängt, nachdem der Text versiegelt würde, sodass eine lesbare Kopie des ganzen Threads außerhalb des Siegels läge, Antworten und Weiterleitungen können deshalb nicht verschlüsselt werden, solange der zitierte Verlauf nicht in den Geheimtext eingeschlagen ist.
Nichts davon verbirgt Ihre Betreffzeile, an wen Sie geschrieben haben oder wann. Der Betreff reist bei einer versiegelten Nachricht genauso im Klartext wie bei jeder anderen, und der Lesebereich sagt das an der Nachricht selbst: „Der Betreff und die Adressen sind im Klartext gereist; dieser Text nicht.“ PGP deckt den Textkörper ab, und keine Implementierung davon deckt den Rest ab. Entwürfe sind ebenfalls unversiegelt, weil das automatische Speichern während des Verfassens fortlaufend Klartext in Ihr Postfach schreibt, weil stillschweigend nicht zu speichern Arbeit vernichten würde, und das Schloss legt es in Worten offen.
Versiegelt eintreffende Mail zu erkennen kam zuerst und gilt weiterhin. PGP/MIME, Inline-PGP-Rüstung und S/MIME wurden früher als leerer Text mit zwei bedeutungslosen Anhängen dargestellt, weil der Parser nur reinen Text und HTML als lesbar behandelt und den Rest in die Dateileiste fallen ließ. Diese Teile werden jetzt erkannt, das Protokoll-Beiwerk bleibt aus der Anhangsliste heraus, der Geheimtext wird unversehrt gespeichert, und daraus entschlüsselt der Leser, statt etwas Neues zu holen, und eine Nachricht, die hier niemand öffnen kann, sagt das weiterhin klar.
Eine signierte Nachricht wird als eigene Sache behandelt, weil sie eine ist. Ihr Text ist lesbar, Suche, Regeln und alles andere funktionieren also weiter daran; sie wird nie hinter ein Schloss gesperrt und nie durch eine Entschlüsselung geschickt. Die Zeile meldet gedimmt „Vom Absender signiert. Signatur nicht geprüft“, und sie bleibt gedimmt, bis hier tatsächlich etwas eine Signatur prüfen kann, was bislang nichts tut, auch nicht bei einer erfolgreich entschlüsselten Nachricht. Zu sehen, dass eine Nachricht versiegelt ist, ist nicht dasselbe wie sie geöffnet zu haben, und sie geöffnet zu haben ist nicht dasselbe wie zu wissen, wer sie versiegelt hat.
Bei einer verschlüsselten Nachricht wird der Text allem vorenthalten, was ihn sonst läse: dem Suchauszug, dem Textdurchgang des Phishing-Scorers, der KI-Schreibprüfung, Textbedingungen in Regeln, dem Import von Kalendereinladungen und den Thread-Zusammenfassungen. Die Authentifizierungshälfte der Phishing-Prüfung läuft weiter, denn DMARC, DKIM und SPF werden aus Headern gelesen, die Geheimtext nicht verbirgt. Das Entschlüsseln ändert daran nichts. Der Klartext existiert nur in dem Tab, der ihn geöffnet hat, eine versiegelte Nachricht bleibt also unsuchbar und bleibt auch nach dem Lesen außerhalb der KI-Funktionen, und eine Übersetzung wird dafür nicht angeboten. Das ist der Preis der Behauptung und kein Versäumnis.