Inhaltsverzeichnis
- Die drei Bedeutungen von «verschlüsselter E-Mail»
- Transportverschlüsselung: notwendig, nicht ausreichend
- Ende-zu-Ende: PGP vs. S/MIME
- Zero-Access-Verschlüsselung des Anbieters
- Das Metadaten-Problem, das alle überspringen
- Wo die großen Anbieter wirklich stehen
- Ein Entscheidungsrahmen
Die drei Bedeutungen von «verschlüsselter E-Mail»
«Verschlüsselte E-Mail» ist eine der am meisten strapazierten Wendungen im Privacy-Markt, weil fast jeder Anbieter sie wahrheitsgemäß behaupten kann und dabei völlig Verschiedenes meint. Es gibt drei unterschiedliche Verschlüsselungsschichten in der E-Mail, und sie schützen gegen drei verschiedene Gegner:
- Transportverschlüsselung (TLS / STARTTLS) — die Verbindung zwischen zwei Mailservern ist verschlüsselt. Das stoppt einen passiven Lauscher auf der Leitung. Es ist heute nahezu universell und das absolute Minimum, kein Feature.
- Ende-zu-Ende-Verschlüsselung (PGP oder S/MIME) — der Nachrichtentext wird auf dem Gerät des Absenders mit dem öffentlichen Schlüssel des Empfängers verschlüsselt, sodass nur dessen privater Schlüssel ihn öffnen kann. Kein Server im Pfad kann ihn lesen.
- Zero-Access-Verschlüsselung des Anbieters — der Anbieter speichert dein Postfach mit aus deinem Passwort abgeleiteten Schlüsseln verschlüsselt, sodass selbst er die in deinem Konto liegenden Nachrichten nicht lesen kann.
Wenn ein Massenanbieter sagt «deine E-Mail ist verschlüsselt», meint er fast immer Schicht 1, manchmal Schicht 1 plus Festplattenverschlüsselung im Ruhezustand. Wenn ein privatsphärenbewusster Entwickler nach verschlüsselter E-Mail fragt, meint er fast immer Schicht 2 oder 3. Diese Lücke ist das ganze Thema dieses Leitfadens.
Transportverschlüsselung: notwendig, nicht ausreichend
TLS — meist über SMTP mit STARTTLS ausgehandelt — verschlüsselt den Sprung zwischen zwei Mailservern. Sein Wert ist echt: Es hindert jemanden, der das Netzwerk abhört, daran, deine Post im Flug zu lesen, und moderne Mail-Infrastruktur nutzt es fast überall.
Aber TLS ist Hop-für-Hop, nicht Ende-zu-Ende. Eine Nachricht durchläuft typischerweise mehrere Server zwischen Absender und Empfänger, und an jedem Hop wird sie entschlüsselt, verarbeitet und für die nächste Etappe neu verschlüsselt. Das heißt, jeder Server in der Kette — dein Anbieter, der des Empfängers und jedes Relay dazwischen — verarbeitet die Nachricht im Klartext. Transportverschlüsselung schützt die Nachricht vor Außenstehenden auf der Leitung; sie tut nichts, um sie vor den Anbietern selbst zu schützen.
Es gibt einen zweiten Haken: STARTTLS ist standardmäßig opportunistisch. Kündigt der empfangende Server kein TLS an, fallen viele Absender stillschweigend auf Klartext-Zustellung zurück, statt zu scheitern. «Wir nutzen TLS» garantiert also nicht einmal, dass eine bestimmte Nachricht über den ganzen Pfad verschlüsselt war. Deshalb ist Transportverschlüsselung, so essenziell sie ist, der Boden und nicht die Decke.
Ende-zu-Ende: PGP vs. S/MIME
Ende-zu-Ende-Verschlüsselung (E2EE) verlagert die Verschlüsselung an die Endpunkte. Der Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers; nur dessen privater Schlüssel kann sie entschlüsseln. Da die Server dazwischen den privaten Schlüssel nie halten, kann keiner den Text lesen — weder dein Anbieter noch ein Relay noch der Anbieter des Empfängers. Es ist dasselbe Public-Key-Modell, das die CLI-Passwortmanager und die Schlüsselverwaltung trägt, die wir für Entwickler behandeln; der Unterschied liegt darin, wer die Schlüsselverteilung steuert.
Zwei Standards dominieren, und ihr Unterschied dreht sich ganz um Vertrauen und Schlüsselverteilung:
PGP (OpenPGP). Ein dezentrales «Web of Trust». Nutzer erzeugen eigene Schlüsselpaare und tauschen ihre öffentlichen Schlüssel direkt aus, indem sie sie außerhalb des Kanals prüfen (ein Fingerabdruck per Anruf, ein von einem gemeinsamen Kontakt signierter Schlüssel). Es ist maximal flexibel und braucht keine zentrale Instanz, aber die Schlüsselverteilung ist manuell, woher PGPs Ruf der Reibung kommt. Es ist der Standard bei Einzelpersonen, Journalisten und Open-Source-Gemeinschaften.
S/MIME. Öffentliche Schlüssel werden über Zertifikate einer zentralen Zertifizierungsstelle (CA) an Identitäten gebunden. Das vereinfacht den Rollout in einer verwalteten Organisation enorm — die IT stellt Zertifikate zentral bereit — bindet dein Vertrauen aber an diese CA-Hierarchie. S/MIME ist die übliche Wahl in Unternehmen und Behörden, wo bereits eine verwaltete PKI existiert.
Beide liefern dieselbe Kerngarantie: eine Nachricht, die kein Server in der Mitte lesen kann, plus eine digitale Signatur, die den Absender beweist und dass nichts verändert wurde. Der Preis ist in beiden Fällen, dass auch der Empfänger mitmachen muss. Du kannst keine E2EE-Nachricht transparent an jemanden ohne Schlüssel senden.
Zero-Access-Verschlüsselung des Anbieters
Es gibt ein drittes Modell, das den Schmerz der Schlüsselverteilung für den häufigen Fall eines privaten Postfachs umgeht: Zero-Access-Verschlüsselung beim Anbieter.
Hier verschlüsselt der Anbieter dein gespeichertes Postfach mit aus deinem Passwort abgeleiteten Schlüsseln, auf deinem Gerät, sodass der Server für dein Konto nur Chiffretext speichert. Selbst der Anbieter kann die Post im Ruhezustand nicht lesen. Proton Mail ist die bekannteste Umsetzung: Nachrichten zwischen Proton-Nutzern sind standardmäßig Ende-zu-Ende verschlüsselt, und das gesamte Postfach wird unter Zero-Access-Verschlüsselung gehalten, sodass Proton selbst es nicht lesen kann.
Die ehrliche Grenze liegt in der Natur der E-Mail. Wenn ein Proton-Nutzer einem Gmail-Nutzer schreibt, kann die Nachricht nicht Ende-zu-Ende verschlüsselt werden, es sei denn, der Gmail-Nutzer hat ebenfalls PGP, weil das andere Ende keinen Schlüssel hat. Proton löst das, indem es dich eine passwortgeschützte Nachricht an einen Nicht-Nutzer senden lässt: Der Empfänger öffnet sie über einen Link und ein Passwort, das du separat teilst. Das ist eine echte Brücke, aber das Passwort muss über einen anderen Kanal geteilt werden — dieselbe Grundbedingung wie bei PGP, nur bequemer verpackt.
Zero-Access-Verschlüsselung reizt, weil sie dir ein lesbares, auf dem Gerät durchsuchbares Postfach ohne Einrichtung gibt, das der Anbieter dennoch nicht lesen kann — ohne jeden Korrespondenten zur Schlüsselverwaltung zu zwingen.
Das Metadaten-Problem, das alle überspringen
Das ist der wichtigste und am meisten ignorierte Punkt jeder ehrlichen Diskussion über verschlüsselte E-Mail: Verschlüsselung schützt den Inhalt, nicht die Metadaten.
Selbst bei makelloser Ende-zu-Ende-Verschlüsselung läuft Folgendes in der Regel im Klartext und kann von deinem Anbieter, dem des Empfängers und dem Netzwerk protokolliert werden:
- wer die Nachricht gesendet und wer sie empfangen hat,
- der Zeitstempel,
- die Nachrichtengröße,
- und, in vielen Implementierungen, die Betreffzeile.
Verschlüsselung beantwortet also «was sagte die Nachricht», aber nicht «wer spricht mit wem, wann und wie oft». Für ein Bedrohungsmodell, in dem das Verbergen deiner Kontakte zählt — nicht nur deiner Worte — reicht die Inhaltsverschlüsselung allein nicht. Anbieter, die die Speicherung von Metadaten minimieren, und Werkzeuge auf Netzwerkebene adressieren einen anderen Teil des Problems. Behandle die Metadatengrenze als Designtatsache der E-Mail, nicht als Fehler eines einzelnen Anbieters, und plane entsprechend.
Wo die großen Anbieter wirklich stehen
| Anbieter | Im Transit | Im Ruhezustand | Ende-zu-Ende standardmäßig | Anbieter kann deine Post lesen |
|---|---|---|---|---|
| Gmail (Verbraucher) | TLS | Ja (Google hält die Schlüssel) | Nein | Ja |
| Outlook / Microsoft 365 (Verbraucher) | TLS | Ja (Microsoft hält die Schlüssel) | Nein | Ja |
| Gmail Workspace + CSE / S/MIME | TLS | Ja | Nur wenn konfiguriert | Reduziert mit CSE |
| Proton Mail | TLS | Zero-Access (du hältst die Schlüssel) | Ja, zwischen Proton-Nutzern | Nein |
Das Muster ist konstant: Die Massendienste verschlüsseln im Transit und im Ruhezustand, halten aber die Schlüssel und können daher — und tun es für Funktionen und rechtliche Anfragen — Inhalte lesen. Ende-zu-Ende auf Gmail oder Outlook zu erreichen ist möglich, erfordert aber bewusste Konfiguration (S/MIME oder clientseitige Verschlüsselung in bestimmten kostenpflichtigen Stufen). Proton Mail ist standardmäßig E2EE-und-Zero-Access gebaut, was es zum am häufigsten genannten Anbieter macht, wenn «verschlüsselte E-Mail» Schicht 2 oder 3 statt Schicht 1 meint.
Eine Anmerkung zur Überprüfung, im Geist der Datensouveränität: Eine Verschlüsselungsbehauptung, die du nicht prüfen kannst, ist eine Behauptung, keine Garantie. Open-Source-Clients — Proton veröffentlicht seine — erlauben unabhängigen Prüfern zu bestätigen, dass Schlüssel auf deinem Gerät erzeugt werden und Klartext nie den Server erreicht. Bevorzuge Anbieter, deren Behauptungen prüfbar sind, gegenüber solchen, die sie nur aufstellen.
Ein Entscheidungsrahmen
Hör auf zu fragen «welche E-Mail ist am stärksten verschlüsselt» und frage stattdessen «wer darf das nicht lesen können, und ist der Empfänger bereit mitzumachen?»
Transportverschlüsselung genügt, wenn der Inhalt alltäglich ist und deine einzige Sorge ein Netzwerk-Lauscher ist. Jeder seriöse Anbieter gibt dir das bereits; es gibt nichts einzurichten.
Nutze Ende-zu-Ende (PGP oder S/MIME), wenn bestimmte Nachrichten für jeden Server im Pfad unlesbar sein müssen und der Empfänger einen Schlüssel halten kann — ein Kollege, die Quelle eines Journalisten, eine Organisation mit verwaltetem S/MIME. Akzeptiere den Schlüsselaustausch-Schritt als Preis der Garantie.
Nutze einen Zero-Access-Anbieter wie Proton Mail, wenn du dein ganzes Postfach für den Anbieter unlesbar willst, ohne jeden Korrespondenten zu PGP zu zwingen, mit einem passwortgeschützten Rückfall für die gelegentliche verschlüsselte Nachricht an einen Außenstehenden.
Was du auch wählst, denk an zwei Dinge. Erstens: Metadaten sind nicht verschlüsselt — Verschlüsselung verbirgt die Worte, nicht die Beziehung. Zweitens: Prüfe die Behauptung — bevorzuge Open-Source-Clients und eine privatsphärenfreundliche Gerichtsbarkeit, damit «wir können deine Post nicht lesen» etwas ist, das du nachprüfen kannst, statt etwas, das du glauben musst.
Für die Speicherseite desselben Privacy-Setups siehe unseren Leitfaden zu verschlüsseltem Cloudspeicher für Entwickler, und für die größere Frage, Daten aus US-Gerichtsbarkeits-Diensten herauszuhalten, die Säule zur Datensouveränität.
