Überblick über die Welt der E-Mail Verschlüsselung

So lange es E-Mail gibt, so lange diskutiert man darüber wie denn ein sicherer Versand und Zustellung gewährleistet werden kann. Doch was heißt hier sicher? Neben einer adäquaten Spam und Malware Filterung und einer anständigen Verfügbarkeit des Dienstes, möchte man natürlich ein paar Dinge wissen.

  • Ist eine abgesendete Mail wirklich von demjenigen Absender der im Absenderfeld auftaucht und kommt sie genau so bei mir an, wie sie an mich versendet wurde? Denn könnte ich das gewährleisten, wären nahezu jegliche Fraudthemen passè. (Man erwarte den 2. Teil des Blogeintrags…)
  • Kann jemand auf dem langen Weg der E-Mail über die unendlichen weiten des Internets, diese abfangen, sie lesen bzw. deren Inhalt extrahieren und Ihn weitergeben?

Natürlich kann er das, wenn die E-Mail nicht verschlüsselt wurde. Im Prinzip ist es jedem möglich, der an der Leitung oder an Knotenpunkten auf dem Weg vom Sender bis zum Empfänger Netzwerkverkehr dupliziert, extrahiert oder mitschnüffelt. Das können Mailprovider, Netzwerkprovider, Telekommunikationsunternehmen, Geheimdienste , Intelligence Researcher und andere staatliche Behörden etc. sein. Bemerken kann man das nicht.

Aber man kann sich schützen. Entgegen aller Hysterie (hier der Verweis auf E-Fail) ist E-Mail Verschlüsselung je nach Art nämlich eine sehr sichere Methode genau dies zu tun – sich schützen.

Dieser Blogeintrag soll ganz unaufgeregt und auf einer sachlichen Ebene erklären, welche Arten der E-Mail Verschlüsselung es gibt, was Ihre Vor-und Nachteile sind. Ein weiterer Blogeintrag wird sich dann intensiv mit dem Thema der E-Mail Signierung beschäftigen.

Einordnung E-Mail Verschlüsselung

E-Mail Verschlüsselung ist eine Technologie, um die Vertraulichkeit einer Nachricht zu erhalten (englisch: confidentiality – das C in CIA). Kann nur der vorbestimmte Empfängerkreis einer Nachricht deren Inhalt lesen/extrahieren, so bleibt die Vertraulichkeit gewährleistet.

Diffefent Standards for certifying Sender identity (SPF, DKIM, DMARC, S/MIME, OpenPGG) and Encryption (SMTP over TLS / S/MIME)

Dieses Ziel versucht man nun im Kontext der E-Mail Security auf 2 Arten zu erreichen.

  • Auf der Ebene des Transports (Transport Security) mit der Technologie SMTP over TLS und 3 verschiedenen Subvarianten:
    • opportunistic TLS
    • forced TLS
    • forced TLS with certificate check
  • Auf der Ebene des Mailobjekts selbst (Mail Object Security) mit den 2 Standards:
    • S/MIME
    • OpenPGP

Transport Security versus Mail Object Security bei E-Mail Verschlüsselung

Achtung: „Encryption on Transport Layer“ / Verschlüsselung auf Transportebene hat bis auf TL(S) im Namen erst einmal weitgehend nichts mit der klassischen TLS Verschlüsselung im Webbereich zu tun. Beide haben völlig unterschiedliche Eigenheiten. Häufige Aussagen wie z.B. „Verschlüsselung ist eh überall das gleiche“ sind somit überwiegend falsch.

Denn: Mail-Verschlüsselung auf der Ebene des Transport Layers verschlüsselt in einem Tunnel den Datenstrom vom sendenden MTA (Mail Transfer Agent – also sendendes Mail Transfer System = Mail Server/Gateway) zum nächsten (und nur zu dem!) MTA. Nicht zum Empfänger und potentiell auch nicht an allen anderen MTAs – die sich auf dem Weg vom ersten empfangenden MTA bis zum Empfänger befinden.

„Man in the Middle anyone“?

Im Webbereich (HTTPS) passiert die Verschlüsselung vom Client immer „direkt“ zum Server. Dies hat mit den eingesetzten Zertifikaten und deren Prüfung zu tun – mehr dazu unten.

Encryption on Transport Layer - SMTP over TLS, opportunistic TLS, forced TLS, forced TLS with certificate check
Encryption on Transport Layer

„Mail Object Encryption“ (Verschlüsselung auf der Mailobjekt Ebene selbst) hingegen verschlüsselt direkt das Mail Objekt auf seiner Reise zum Empfänger – so lange bis es vom private Key des Empfängers entschlüsselt wird.

Encryption on Mail Object Layer - S/MIME - OpenPGP / PGP
Encryption on Mail Object Layer

Encryption on Transportlayer – im Detail

Wie oben beschrieben wird die Verschlüsselung in einem Transporttunnel zwischen dem sendenden und den ersten empfangenden MTA eingerichtet. Der TLS Tunnel verschlüsselt dabei den SMTP Protocol Exchange und im Optimalfall auch alle zwischen den MTAs ausgetauschten Maildaten. Das Mailobjekt selbst wird aber nicht geschützt – sondern nur der Tunnel!

Es gibt 3 Arten diesen verschlüsselten Tunnel handzuhaben, die sich vornehmlich in der Kompliziertheit/Aufwand der Einrichtung und dem Security Level unterscheiden.

Encryption on Transport Layer - Standards - layered in security Level and complexity in setup and maintenance
Encryption on Transport Layer – Standards

Opportunistic TLS

  • Technologie:
    • Outbound E-Mail Traffic: Erstellt einen verschlüsslten TLS Tunnel zum 1. empfangenden MTA (Mail Transfer System) falls dieser MTA SMTP over TLS unterstützt und ein funktionierendes, installiertes Serverauthentifizierungs-Zertifikat besitzt.
    • Inbound E-Mail Traffic: Wenn der sendende MTA versucht verschlüsselt über SMTP over TLS zuzustellen und SMTP over TLS ist aktiviert und ein beliebiges(!) Serverauthentifzierungszertifikat ist installiert – so wird die eingehende Zustellung erlaubt.
  • Vorteile:
    Wenn beide MTAs SMTP over TLS konfiguriert haben und sich auf diese Methode einigen – wird jeglicher SMTP/Mail Verkehr vom sendenden bis zum 1. empfangenden MTA via SMTP over TLS auf der Transportebene verschlüsselt. Der Administrative Aufwand für die Einrichtung ist niedrig (beliebiges Self signed Zertifikat ist ausreichend (!)) , opportunistic TLS skaliert ohne weitere Mail Ruleset Changes gut und im Fehlerfall gehen in der Regel keinerlei Mails verloren (Fallback s.u.)
  • Nachteile:
    Wenn einer der 2 MTAs SMTP over TLS nicht unterstützt oder dabei ein temporärer Fehler auftritt so werden die E-Mails unverschlüsselt zugestellt (Protocol Downgrade). Zudem wird immer nur der Verkehr zwischen dem sendenden und dem 1. empfangenden MTA beeinflussbar verschlüsselt. Falls auf dem Weg der E-Mail mehrere MTAs überschritten werden – so ist deren Verschlüsselungsstatus nicht beinflussbar bzw. sie sind unverschlüsselt. E-Mail Spoofing und Man-in-the-Middle Angriffe sind leicht möglich: Da das Zertifikat des MTAs nicht geprüft und validiert wird kann DNS Spoofing bzw. Rerouting des Mailverkehrs und Einsatz eines Self Signed Zertifikats dazu führen, dass unautorisierte Personen/Systeme den E-Mail Verkehr abfangen, lesen bzw. deren Inhalte extrahieren ohne dass es Absender und Empfänger merken.
  • Empfehlung: Opportunistic TLS sollte auf jedem MTA als Default Einstellung gesetzt werden. Dies aber mehr aus Kompatibilitätsgründen denn aus Sicherheitsgründen. Für echte Vertraulichkeit im E-Mail Verkehr reicht diese Technologie nicht.

Forced TLS

  • Technologie:
    • Outbound E-Mail Traffic: Erzwingt (forced) einen TLS Tunnel für eine spezifische Mail Zieldomäne (@example.com).
    • Inbound E-Mail Traffic: Wenn der sendende MTA (in der Regel identifiziert durch Hostnamen/IP Adresse) versucht verschlüsselt über STMP over TLS zuzustellen, wird dies akzeptiert. Unverschlüsselte Mails vom gleichen MTA werden dagegen verworfen.
  • Vorteile: Jeglicher Verkehr der zwischen dem sendenden und dem 1. empfangenden MTA für die spezifizierte Maildomäne (@example.com) gesendet wird, wird mittels SMTP over TLS auf der Transportebene verschlüsselt. Kein unverschlüsselter SMTP Verkehr kann Richtung MTA dieser spezifizierten Domäne losgeschickt werden. Protocol Downlevel Angriffe auf dieser Verbindungsstrecke sind nicht mehr möglich.
  • Nachteile: Forced TLS für SMTP skaliert schlecht. Für jede Zieldomäne muss eine spezifische Rule auf dem Mailgateway erstellt werden. Mails können verloren gehen, wenn es temporäre Probleme mit SMTP over TLS bei der für die empfangende Domain zuständigen MTA gibt. Weiterhin wird die E-Mail nur auf der Strecke vom sendenden bis zum 1. empfangenden MTGA über den verschlüsselten Tunnel geschützt. Wenn die E-Mail mehrere MTAs durchläuft so ist ihr Verschlüsselungsstatus unklar bzw. ist sie unverschlüsselt. E-Mail Spoofing Angriffe und Man-in-the-Middle Angriffe sind weiterhin möglich, das es keinerlei Zertifkatsprüfung/Validierung gibt.DNS Spoofing / Rerouten von Traffic und Einsatz von einem selbstsignierten Zertifikat kann weiterhin dazu führen dass unautorisierte Personen/Systeme die E-Mails lesen bzw. deren Inhalte extrahieren ohne dass es die Empfänger merken.
  • Empfehlung: Setzen sie reines forced TLS nur ein, wenn es ein Businesspartner aus Compliance Gründen von Ihnen verlangt. Für einen echten Sicherheitsgewinn setzen sie dagegen forced TLS nur mit Zertifikatsvalidierung (siehe unten) oder gleich eine der Mailobjektverschlüsselungs-Technologien wie S/MIME ein.

Forced TLS with certificate check

  • Technologie: 
    • Outbound E-Mail Traffic: Erzwingt (forced) einen TLS Tunnel für eine spezifische Mail Zieldomäne (@example.com). Das digitale Zertifikat des MTAs der Zieldomäne wird zusätzlich validiert u.a.:
      • Passt der SAN/CN zur Zieldomäne?
      • Ist das Zertifikat noch gültig?
      • Ist das Zertifikat ggf. gesperrt (OCSP/CRL check)?
      • Ist das Zertifikat trusted?
      • Ist das Zertifikat vom richtigen Typ – z.B. server authentication flag.
    • Inbound E-Mail Traffic: Wenn der sendende MTA (in der Regel identifiziert durch Hostnamen/IP Adresse) versucht verschlüsselt über STMP over TLS zuzustellen und das Zertifikat wird geprüft wird dies akzeptiert. Unverschlüsselte Mails vom gleichen MTA werden dagegen verworfen.
  • Vorteile:
    Jeglicher Verkehr der zwischen dem sendenden und dem 1. empfangenden MTA für die spezifizierte Maildomäne (@example.com) gesendet wird, wird mittels SMTP over TLS auf der Transportebene verschlüsselt. Kein unverschlüsselter SMTP Verkehr kann Richtung MTA dieser spezifizierten Domäne losgeschickt werden. Protocol Downlevel Angriffe auf dieser Verbindungsstrecke sind nicht mehr möglich. Durch die zusätzlich Zertifikatsüberprüfung sind Spoofing bzw. Man-in-the-Middle Angriffe zwischen dem sendendend und dem für die Zieldomäne autorisierten Mailserver nicht mehr möglich.
  • Nachteile:  
    Forced TLS with certificate check für SMTP skaliert schlecht. Für jede Zieldomäne muss eine spezifische Rule auf dem Mailgateway erstellt werden. Mails können verloren gehen, wenn es temporäre Probleme mit SMTP over TLS bei der für die empfangende Domain zuständigen MTA gibt. Mails können verloren gehen, wenn der Zertifikatscheck des MTAs für die Zieldomäne fehlschlägt. Weiterhin wird die E-Mail nur auf der Strecke vom sendenden bis zum 1. empfangenden MTGA über den verschlüsselten Tunnel geschützt. Wenn die E-Mail mehrere MTAs durchläuft so ist ihr Verschlüsselungsstatus unklar bzw. ist sie unverschlüsselt.
  • Empfehlung:
    Setzen sie forced TLS with certificate check nur ein, wenn es ein Businesspartner aus Compliance Gründen von Ihnen verlangt oder wenn sie vertretbare Sicherheit haben wollen und keine Verschlüsselung auf Mailobjektebene mit dem Businesspartner möglich ist.

Wie schaut es nun mit der Sicherheit bei Verschlüsselung auf Mailobjekt-Ebenes aus – so viel sei verraten: deutlich besser. Mehr dazu bald hier auf diesem Blog.


Vgl. Q &A Secure E-Mail Communication on https://mailprotection.redbull.com : „Resason for using Secure E-Mail communication“

sowie

Q &A Secure E-Mail Communication on https://mailprotection.redbull.com/standards : „Which Standards we offer and why“

Dieser Beitrag wurde unter Allgemein abgelegt und mit , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.