TLS und S/MIME: E-Mail-Verschlüsselung

E-Mail wurde in den 1980ern für ein freundliches Forschungs-Internet entworfen – Verschlüsselung war kein Thema. Heute reist deine Mail durch ein potenziell feindliches Netz: ISPs, neugierige Admins, staatliche Geheimdienste, Cyberkriminelle könnten mithören. Zwei Mechanismen schützen dagegen, und sie arbeiten auf verschiedenen Ebenen: TLS sichert die Transport-Strecke zwischen Mailservern – wie ein verschlossener Geldtransporter zwischen Banken. S/MIME (und das verwandte PGP) verschlüsselt und/oder signiert die Mail selbst, Ende-zu-Ende – wie ein versiegelter Briefumschlag, den nur der Empfänger öffnen kann. TLS ist heute praktisch überall aktiv, ohne dass User es merken. S/MIME dagegen ist Aufwand: jeder Beteiligte braucht ein Zertifikat. Diese Lektion erklärt beide Schichten, warum sie sich nicht ersetzen sondern ergänzen, wann du was brauchst, und wie Signatur und Verschlüsselung praktisch ablaufen. Detaillierte Kryptografie-Grundlagen findest du in Kryptografie und Asymmetrische Verschlüsselung.

1) Transport- vs. Ende-zu-Ende-Verschlüsselung

Klick die Tabs, um den Unterschied bildlich zu sehen:

2) TLS für E-Mail – wo überall

TLS sichert mehrere Strecken im Mail-Versandweg:

Wichtig: TLS zwischen MTAs ist klassisch opportunistisch – „wenn beide es können, dann ja". Das bedeutet, ein Man-in-the-Middle könnte das STARTTLS-Angebot abstreifen und so die Verbindung downgraden auf Klartext. Dagegen gibt es:

• MTA-STS (RFC 8461): Domain veröffentlicht „mein Server verlangt TLS" via DNS+HTTPS. Sender-MTAs müssen das durchsetzen.
• DANE (RFC 7672): DNSSEC-signierter TLSA-Record im DNS. Sender prüft Zertifikat gegen diesen Hash.
• TLS-RPT (RFC 8460): Reports über TLS-Fehler vom Empfänger zurück an den Sender.

3) S/MIME – Aufbau und Funktionsweise

S/MIME (Secure/Multipurpose Internet Mail Extensions, RFC 8551) nutzt asymmetrische Kryptografie auf Basis von X.509-Zertifikaten. Jeder Nutzer hat ein Schlüsselpaar (privat + öffentlich), das Public-Key-Zertifikat wird von einer Certificate Authority (CA) signiert.

S/MIME bietet zwei voneinander unabhängige Funktionen:

• Signieren: Empfänger kann prüfen, dass die Mail wirklich vom angegebenen Absender stammt und unverändert ist (Authentizität + Integrität). Inhalt bleibt lesbar.
• Verschlüsseln: Nur der Empfänger kann die Mail lesen (Vertraulichkeit). Setzt voraus, dass der Absender den Public Key des Empfängers hat.

4) Signieren / Verschlüsseln – Workflow

5) S/MIME vs. PGP – die zwei Welten

Neben S/MIME gibt es eine zweite, ältere Lösung: PGP (Pretty Good Privacy, von Phil Zimmermann 1991, heute meist als GnuPG/OpenPGP, RFC 9580). Beide lösen dasselbe Problem, aber unterschiedlich:

6) Zertifikate für S/MIME besorgen

Wo bekommt man ein S/MIME-Zertifikat?

• Kommerzielle CAs: SwissSign, GlobalSign, Sectigo, DigiCert. 30-100 € pro Person und Jahr.
• Volksverschlüsselung (Fraunhofer-Initiative für Privatpersonen).
• Interne Unternehmens-CA: Eigene Microsoft Active Directory Certificate Services oder OpenSSL-basiert. Funktioniert intern, externe Empfänger müssen aber das Root-CA-Zertifikat vertrauen.
• Microsoft 365 / Exchange Hybrid: Kann eigene S/MIME-Zertifikate verteilen.

Schlüssel-Längen heute: RSA 2048+ oder ECC (z. B. ECDSA P-256). Gültigkeitsdauer: 1-3 Jahre. Kosten und Aufwand sind der Hauptgrund, warum S/MIME außerhalb von Behörden, Banken und Großunternehmen wenig verbreitet ist.

7) PGP-Schlüsselverwaltung im Überblick

Bei PGP gibt es keine CA – das Vertrauen wird über das Web of Trust aufgebaut: User signieren gegenseitig ihre Schlüssel, je mehr Vertrauensbeziehungen, desto höher die Vertrauenswürdigkeit. Schlüssel können auch über Keyserver (z. B. keys.openpgp.org) veröffentlicht werden.

Praktisch gängige Tools:

• gpg (GnuPG) – Kommandozeile, Standard auf Linux.
• Thunderbird hat OpenPGP eingebaut (seit Version 78, 2020).
• GPGTools für macOS (mit Apple Mail Plugin).
• Gpg4win für Windows mit Outlook-Plugin.

8) Was Verschlüsselung nicht schützt

Wichtig zu wissen, auch bei S/MIME oder PGP: Metadaten bleiben sichtbar.

• From, To, Cc sind im Klartext-Header. Wer mit wem kommuniziert, ist also nicht geheim.
• Subject (Betreff) ist klassisch nicht verschlüsselt. Bei Memory Hole-/Protected-Headers-Erweiterungen geht das, aber selten umgesetzt.
• Zeitstempel, Größe, Routing-Pfad – alles offen.
• Anhänge sind verschlüsselt, aber der Anhangs-Name kann im MIME-Header stehen.

Wer Metadaten schützen will, braucht andere Tools (Tor, Signal, eigene Server). E-Mail-Verschlüsselung schützt den Inhalt, nicht die Tatsache der Kommunikation.

9) Antipatterns

• TLS reicht ja. Nein – sobald die Mail auf dem Empfänger-Server liegt, ist sie wieder im Klartext. Wenn die Mail wirklich vertraulich sein soll, braucht es S/MIME oder PGP.
• S/MIME-Zertifikat abgelaufen. User schickt fortlaufend Mails mit ungültiger Signatur – Empfänger sehen Warnhinweise und vertrauen weniger. Erneuerung in den Kalender.
• Privaten Schlüssel im Mailclient ohne Backup. Beim Wechsel des Geräts sind alte verschlüsselte Mails plötzlich unlesbar. Lösung: Backup der Schlüssel + Zertifikate.
• S/MIME-Empfänger ohne Public Key. Kann eine S/MIME-verschlüsselte Mail nicht öffnen. Lösung: vor Verschlüsselung kurz signiert hin und her senden, damit Public Keys ausgetauscht sind.
• PGP für Anwender mit Computer-Phobie. Funktioniert nicht. Mit DSGVO-Pflichten lieber organisatorisch lösen (Datentransfer-Tools, sichere Portale).
• Klartext-IMAP/POP3/SMTP. Im LAN „sicher genug"? Nein – jedes WLAN, jeder Gast-Anschluss, jeder Proxy könnte mithören. TLS immer.
• Selbst-signierte Zertifikate ohne Verteilung. Outlook zeigt Warnung „Zertifikat nicht vertrauenswürdig" – User klickt weg, gewöhnt sich an Warnungen, Sicherheit verloren.

Zusammenfassung

Zwei Verschlüsselungs-Ebenen: TLS sichert die Transport-Strecke zwischen Mailservern (STARTTLS oder Implicit TLS auf 465/587/993/995). Server sehen den Inhalt im Klartext, aber niemand auf dem Netzwerk-Weg. Härter: MTA-STS und DANE verhindern TLS-Downgrade. S/MIME und PGP verschlüsseln die Mail Ende-zu-Ende: nur der Empfänger kann den Inhalt lesen, auch Mailserver sehen nur einen verschlüsselten Block. Beide bieten Signieren (Authentizität, Integrität) und Verschlüsseln (Vertraulichkeit). S/MIME nutzt X.509-Zertifikate von CAs, in Outlook/Thunderbird integriert. PGP/OpenPGP nutzt Web of Trust mit eigenen Schlüsseln, Thunderbird hat es eingebaut, sonst per Tools (gpg, Gpg4win, GPGTools). Was Verschlüsselung nicht schützt: Metadaten (From/To/Subject klassisch im Klartext). Verbreitung: TLS universell, S/MIME in Großunternehmen/Behörden, PGP eher Nische. Antipatterns: „TLS reicht" (Server-Speicher bleibt klar), abgelaufene Zertifikate, fehlende Key-Backups, S/MIME ohne Public-Key-Austausch, selbst-signierte Zertifikate ohne Trust-Verteilung, Klartext-Protokolle im LAN.

Verwandte Lektionen: Asymmetrische Verschlüsselung · Kryptografie-Grundlagen · HTTPS und TLS · und mehrWeitere relevante LektionenSPF/DKIM/DMARCSMTPSpam-SchutzDigitale SignaturenZertifikate und PKIDSGVOE-Mail-Archivierung