Encryption on Transportlayer – im Detail

Wie im Übersichtsartikel 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.

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 hier

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“