Hier ist eine unbequeme Wahrheit: Die 'sichere' E-Mail, die du gerade gesendet hast, ist wahrscheinlich über das Internet in einer Form unterwegs gewesen, die ein ausreichend motivierter Angreifer lesen konnte. Nicht, weil es keine Verschlüsselung gäbe, sondern weil das E-Mail-Ökosystem Ebenen von Verschlüsselung hat, die unterschiedliche Dinge schützen — und die meisten Menschen nicht verstehen, welche Ebene was schützt.
Wenn wir über E-Mail-Verschlüsselung sprechen, reden wir tatsächlich über drei unterschiedliche Technologien, die drei unterschiedliche Probleme lösen. Wenn man sie gleichsetzt, führt das zu falscher Sicherheit oder unnötiger Paranoia. Lass uns das entwirren.
TLS: Die Reise verschlüsseln
Transport Layer Security — TLS — ist die Verschlüsselung, die du bei den meisten modernen E-Mails standardmäßig bekommst. Wenn deine E-Mail von deinem Mailserver zum Mailserver des Empfängers reist, verschlüsselt TLS diese Verbindung. Jeder, der den Datenverkehr abfängt, sieht nur Kauderwelsch.
Das ist dieselbe Technologie, die das Schloss in der Adressleiste deines Browsers platziert. Sie ist gut verstanden, weit verbreitet und weitgehend unsichtbar. Wenn du eine E-Mail über Gmail, Outlook oder einen seriösen E-Mail-Dienst sendest, schützt TLS mit hoher Wahrscheinlichkeit die Verbindung.
Aber TLS hat eine kritische Einschränkung: Es verschlüsselt nur Daten während der Übertragung. Sobald deine E-Mail beim Mailserver des Empfängers ankommt, wird sie entschlüsselt und im Klartext gespeichert (oder mit den eigenen Schlüsseln des Servers verschlüsselt, auf die der Betreiber Zugriff hat). Wenn jemand den Mailserver kompromittiert oder der Betreiber gezwungen wird, Daten herauszugeben, bietet TLS keinen Schutz.
Es gibt noch eine Feinheit: TLS wird zwischen Servern ausgehandelt und ist nicht immer garantiert. Wenn der Server des Empfängers TLS nicht unterstützt oder eine Fehlkonfiguration vorliegt, kann die E-Mail auf unverschlüsselte Übertragung zurückfallen. Die meisten großen Anbieter verlangen inzwischen TLS, aber es ist nicht universell. Googles Transparenzbericht zeigt, dass etwa 10 % der ausgehenden Gmail-Nachrichten immer noch an Server gehen, die keine Verschlüsselung unterstützen.
Für die meisten geschäftlichen E-Mails reicht TLS aus. Es schützt vor passivem Abhören — also vor jemandem, der die Leitung zwischen Servern anzapft. Es schützt nicht vor kompromittierten Servern, rechtlichen Herausgabeverlangen oder vor ausgefeilten Angreifern, die Verkehr abfangen und manipulieren können.
S/MIME: Der Enterprise-Standard
S/MIME — Secure/Multipurpose Internet Mail Extensions — verschlüsselt die E-Mail-Nachricht selbst, nicht nur die Verbindung. Die E-Mail wird auf deinem Gerät verschlüsselt, bevor sie es verlässt, und nur das Gerät des Empfängers kann sie entschlüsseln. Die Mailserver dazwischen sehen nur verschlüsselten Inhalt.
S/MIME verwendet dieselbe Zertifikatsinfrastruktur wie HTTPS. Du bekommst ein Zertifikat von einer Certificate Authority, das deinen öffentlichen Schlüssel enthält und deine Identität bestätigt. Wenn dir jemand eine verschlüsselte E-Mail senden möchte, verwendet er deinen öffentlichen Schlüssel, um sie zu verschlüsseln. Nur dein privater Schlüssel — der dein Gerät nie verlässt — kann sie entschlüsseln.
Die Enterprise-Welt liebt S/MIME, weil es sich in vorhandene Identitätsinfrastrukturen integriert. Wenn dein Unternehmen bereits Zertifikate für VPN-Zugriff oder Code Signing nutzt, lässt sich das auf E-Mail-Verschlüsselung relativ einfach erweitern. Outlook hat integrierte S/MIME-Unterstützung, ebenso die meisten Enterprise-E-Mail-Clients.
Aber S/MIME bringt Reibung mit sich. Sowohl Absender als auch Empfänger benötigen Zertifikate. Ihr müsst öffentliche Schlüssel austauschen, bevor ihr sicher kommunizieren könnt. Zertifikatsmanagement ist mühsam — Zertifikate laufen ab, werden widerrufen und müssen gesichert werden. Wenn du deinen privaten Schlüssel verlierst, sind alle E-Mails, die an diesen Schlüssel verschlüsselt wurden, für immer verloren.
Es stellt sich auch die Frage, wem du vertraust. S/MIME-Zertifikate stammen von Certificate Authorities, was bedeutet, dass du diesen CAs vertraust, Identitäten korrekt zu prüfen und ihre Infrastruktur zu schützen. Nationalstaatliche Angreifer haben schon CAs kompromittiert. Für die meisten Bedrohungsmodelle ist das akzeptabel, aber es ist nicht die im paranoiden Sinn echte Ende-zu-Ende-Sicherheit.
PGP: Die Cypherpunk-Wahl
PGP — Pretty Good Privacy — ist älter als S/MIME und verfolgt einen anderen philosophischen Ansatz. Anstatt sich auf Certificate Authorities zu verlassen, nutzt PGP ein 'Web of Trust', in dem Nutzer die Schlüssel der anderen direkt verifizieren. Es gibt keine zentrale Instanz, die entscheidet, wer wer ist.
Die Kryptografie ist ähnlich wie bei S/MIME: Public-Key-Verschlüsselung, bei der nur der private Schlüssel des Empfängers die Nachricht entschlüsseln kann. Aber das Schlüsselmanagement ist grundlegend anders. Du generierst deine eigenen Schlüssel, veröffentlichst deinen öffentlichen Schlüssel auf Key-Servern oder deiner Website und verifizierst die Schlüssel anderer über direkten Austausch oder indem du Personen vertraust, die sie bereits verifiziert haben.
PGP ist beliebt bei Journalisten, Aktivisten und Sicherheitsforschern — bei Menschen, die gute Gründe haben, zentralen Autoritäten zu misstrauen. Es ist auch berüchtigt dafür, schwer korrekt zu nutzen zu sein. Schlüsselmanagement ist manuell und fehleranfällig. Die Tools waren historisch benutzerunfreundlich. Studien haben gezeigt, dass selbst technische Nutzer Fehler machen, die ihre Sicherheit kompromittieren.
Das Web-of-Trust-Modell klingt elegant, skaliert aber schlecht. In der Praxis verifizieren die meisten PGP-Nutzer Schlüssel entweder über Seitkanäle (persönliches Treffen, Telefonanruf zur Bestätigung von Fingerprints) oder vertrauen einfach Schlüsseln, die sie online finden — was einen großen Teil des Sicherheitsvorteils zunichtemacht.
In der Sicherheitscommunity wird laufend darüber gestritten, ob PGP noch zweckmäßig ist. Das Protokoll ist alt, die Implementierungen sind komplex und die Usability-Probleme wurden nie gelöst. Einige argumentieren, dass moderne Alternativen wie Signal (für Messaging) mit weniger Reibung bessere Sicherheit bieten. Für E-Mail speziell bleibt PGP jedoch der Standard für Ende-zu-Ende-Verschlüsselung außerhalb des Enterprise-Umfelds.
Die richtige Verschlüsselung wählen
Welche Verschlüsselung solltest du also verwenden? Das hängt davon ab, wogegen du dich schützen willst.
Für allgemeine geschäftliche E-Mails reicht TLS wahrscheinlich aus. Es ist automatisch, weitgehend universell und schützt vor den häufigsten Bedrohungen. Stelle sicher, dass dein E-Mail-Anbieter TLS erzwingt, und erwäge, MTA-STS zu aktivieren, um Downgrade-Angriffe zu verhindern.
Für regulierte Branchen oder sensible interne Kommunikation ergibt S/MIME Sinn. Die Zertifikatsinfrastruktur integriert sich in das Identity-Management von Unternehmen, und die großen E-Mail-Clients unterstützen es nativ. Der Aufwand für Zertifikatsmanagement wird durch die Compliance- und Sicherheitsvorteile gerechtfertigt.
Für wirklich sensible Kommunikation, bei der du der Infrastruktur nicht vertraust — Whistleblowing, Journalismus, Aktivismus — sind PGP oder eine dedizierte sichere Messaging-Plattform angemessen. Sei aber realistisch in Bezug auf die Usability-Herausforderungen und die operative Sicherheit, die nötig ist, um sie effektiv zu nutzen.
Ein wichtiger Hinweis: Verschlüsselung schützt den Inhalt, nicht die Metadaten. Selbst mit PGP oder S/MIME können Beobachter sehen, wer mit wem wann und wie oft E-Mails austauscht. Für manche Bedrohungsmodelle sind diese Metadaten genauso sensibel wie der Inhalt. Wenn das auf dich zutrifft, ist E-Mail möglicherweise unabhängig von der Verschlüsselung nicht das richtige Werkzeug.
Frequently asked questions
Ist Gmail verschlüsselt?
Gmail verwendet TLS für die Übertragung und verschlüsselt gespeicherte E-Mails mit den Schlüsseln von Google. Das schützt vor externen Angreifern, aber nicht vor Google selbst oder vor rechtlichen Anforderungen. Für Ende-zu-Ende-Verschlüsselung, bei der Google deine E-Mails nicht lesen kann, müsstest du S/MIME oder PGP ergänzen.
Kann ich S/MIME und PGP zusammen verwenden?
Technisch ja, aber es gibt selten einen Grund dafür. Sie lösen dasselbe Problem mit unterschiedlichen Vertrauensmodellen. Wähle eines basierend auf deinem Umfeld und deinem Bedrohungsmodell.
Warum nutzen nicht mehr Menschen E-Mail-Verschlüsselung?
Usability. Sowohl S/MIME als auch PGP erfordern Einrichtung, Schlüsselmanagement und Abstimmung mit Empfängern. Für die meisten Menschen überwiegt die Reibung den wahrgenommenen Nutzen. TLS bietet für typische Anwendungsfälle 'gut genug'-Sicherheit.
Wie sieht es mit verschlüsselten E-Mail-Diensten wie ProtonMail aus?
Dienste wie ProtonMail verschlüsseln dein Postfach mit Schlüsseln, die aus deinem Passwort abgeleitet sind, sodass selbst sie deine gespeicherten E-Mails nicht lesen können. E-Mail zwischen ProtonMail-Nutzern ist Ende-zu-Ende verschlüsselt. E-Mail an externe Nutzer kann mit einem Passwort verschlüsselt werden oder fällt auf TLS zurück.