{"id":722,"date":"2019-04-01T21:56:25","date_gmt":"2019-04-01T19:56:25","guid":{"rendered":"http:\/\/lkl-it.de\/blog\/?p=722"},"modified":"2019-04-04T22:15:46","modified_gmt":"2019-04-04T20:15:46","slug":"encryption-on-transportlayer-im-detail","status":"publish","type":"post","link":"http:\/\/lkl-it.de\/blog\/?p=722","title":{"rendered":"Encryption on Transportlayer &#8211; im Detail"},"content":{"rendered":"\n<p>Wie im \u00dcbersichtsartikel beschrieben wird die Verschl\u00fcsselung in einem Transporttunnel zwischen dem sendenden und den ersten empfangenden MTA eingerichtet. Der TLS Tunnel verschl\u00fcsselt dabei den SMTP Protocol Exchange und im Optimalfall auch alle zwischen den MTAs ausgetauschten Maildaten. Das Mailobjekt selbst wird aber nicht gesch\u00fctzt &#8211; sondern nur der Tunnel! <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img src=\"https:\/\/mailprotection.redbull.com\/Images\/EncryptionOnTunnel.PNG\" alt=\"Encryption on Transport Layer - SMTP over TLS, opportunistic TLS, forced TLS, forced TLS with certificate check\"\/><figcaption>Encryption on Transport Layer<\/figcaption><\/figure>\n\n\n\n<p>Es gibt 3 Arten diesen verschl\u00fcsselten Tunnel handzuhaben, die sich vornehmlich in der Kompliziertheit\/Aufwand der Einrichtung und dem Security Level unterscheiden.<\/p>\n\n\n\n<figure class=\"wp-block-image is-resized\"><img loading=\"lazy\" src=\"http:\/\/lkl-it.de\/blog\/wp-content\/uploads\/image.png\" alt=\"Encryption on Transport Layer - Standards - layered in security Level and complexity in setup and maintenance\" width=\"435\" height=\"134\"\/><figcaption>Encryption on Transport Layer &#8211; Standards<\/figcaption><\/figure>\n\n\n\n<h4><strong>Opportunistic TLS<\/strong><\/h4>\n\n\n\n<ul><li><strong>Technologie:<\/strong> <ul><li>Outbound E-Mail Traffic: Erstellt einen verschl\u00fcsslten TLS Tunnel zum 1. empfangenden MTA (Mail Transfer System) falls dieser MTA SMTP over TLS unterst\u00fctzt und ein funktionierendes, installiertes Serverauthentifizierungs-Zertifikat besitzt.<\/li><li> Inbound E-Mail Traffic: Wenn der sendende MTA versucht verschl\u00fcsselt \u00fcber SMTP over TLS zuzustellen und SMTP over TLS ist aktiviert und ein beliebiges(!) Serverauthentifzierungszertifikat ist installiert &#8211; so wird die eingehende Zustellung erlaubt. <\/li><\/ul><\/li><li><strong>Vorteile:<\/strong><br>Wenn beide MTAs SMTP over TLS konfiguriert haben und sich auf diese Methode einigen &#8211; wird jeglicher SMTP\/Mail Verkehr vom sendenden bis zum 1. empfangenden MTA via SMTP over TLS auf der Transportebene verschl\u00fcsselt. Der Administrative Aufwand f\u00fcr 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.)<\/li><li><strong>Nachteile:<\/strong><br>Wenn einer der 2 MTAs SMTP over TLS nicht unterst\u00fctzt oder dabei ein tempor\u00e4rer Fehler auftritt so werden die E-Mails unverschl\u00fcsselt zugestellt (Protocol Downgrade).  Zudem wird immer nur der Verkehr zwischen dem sendenden und dem 1. empfangenden MTA beeinflussbar verschl\u00fcsselt. Falls auf dem Weg der E-Mail mehrere MTAs \u00fcberschritten werden &#8211; so ist deren Verschl\u00fcsselungsstatus nicht beinflussbar bzw. sie sind unverschl\u00fcsselt. E-Mail Spoofing und Man-in-the-Middle Angriffe sind leicht m\u00f6glich: Da das Zertifikat des MTAs nicht gepr\u00fcft und validiert wird kann DNS Spoofing bzw. Rerouting des Mailverkehrs und Einsatz eines Self Signed Zertifikats dazu f\u00fchren, dass unautorisierte Personen\/Systeme den E-Mail Verkehr abfangen, lesen bzw. deren Inhalte extrahieren ohne dass es Absender und Empf\u00e4nger merken.<\/li><li><strong>Empfehlung: <\/strong>Opportunistic TLS sollte auf jedem MTA als Default Einstellung gesetzt werden. Dies aber mehr aus Kompatibilit\u00e4tsgr\u00fcnden denn aus Sicherheitsgr\u00fcnden. F\u00fcr echte Vertraulichkeit im E-Mail Verkehr reicht diese Technologie nicht.<\/li><\/ul>\n\n\n\n<h4><strong>Forced TLS<\/strong><\/h4>\n\n\n\n<ul><li><strong>Technologie:<\/strong><br><ul><li>Outbound E-Mail Traffic: Erzwingt (forced) einen TLS Tunnel f\u00fcr eine spezifische Mail Zieldom\u00e4ne (@example.com).<br><\/li><li>Inbound E-Mail Traffic: Wenn der sendende MTA (in der Regel identifiziert durch Hostnamen\/IP Adresse) versucht verschl\u00fcsselt \u00fcber STMP over TLS zuzustellen, wird dies akzeptiert. Unverschl\u00fcsselte Mails vom gleichen MTA werden dagegen verworfen.<\/li><\/ul><\/li><li><strong>Vorteile:<\/strong> Jeglicher Verkehr der zwischen dem sendenden und dem 1. empfangenden MTA f\u00fcr die spezifizierte Maildom\u00e4ne (@example.com) gesendet wird, wird mittels SMTP over TLS auf der Transportebene verschl\u00fcsselt. Kein unverschl\u00fcsselter SMTP Verkehr kann Richtung MTA dieser spezifizierten Dom\u00e4ne losgeschickt werden. Protocol Downlevel Angriffe auf dieser Verbindungsstrecke sind nicht mehr m\u00f6glich.<br><\/li><li><strong>Nachteile:<\/strong> Forced TLS f\u00fcr SMTP skaliert schlecht. F\u00fcr jede Zieldom\u00e4ne muss eine spezifische Rule auf dem Mailgateway erstellt werden. Mails k\u00f6nnen verloren gehen, wenn es tempor\u00e4re Probleme mit SMTP over TLS bei der f\u00fcr die empfangende Domain zust\u00e4ndigen MTA gibt. Weiterhin wird die E-Mail nur auf der Strecke vom sendenden bis zum 1. empfangenden MTGA \u00fcber den verschl\u00fcsselten Tunnel gesch\u00fctzt. Wenn die E-Mail mehrere MTAs durchl\u00e4uft so ist ihr Verschl\u00fcsselungsstatus unklar bzw. ist sie unverschl\u00fcsselt. E-Mail Spoofing Angriffe und Man-in-the-Middle Angriffe sind weiterhin m\u00f6glich, das es keinerlei Zertifkatspr\u00fcfung\/Validierung gibt.DNS Spoofing \/ Rerouten von Traffic und Einsatz von einem selbstsignierten Zertifikat kann weiterhin dazu f\u00fchren dass unautorisierte Personen\/Systeme die E-Mails lesen bzw. deren Inhalte extrahieren ohne dass es die Empf\u00e4nger merken.<br><\/li><li><strong>Empfehlung:<\/strong> Setzen sie reines forced TLS nur ein, wenn es ein Businesspartner aus Compliance Gr\u00fcnden von Ihnen verlangt. F\u00fcr einen echten Sicherheitsgewinn setzen sie dagegen forced TLS nur mit Zertifikatsvalidierung (siehe unten) oder gleich eine der Mailobjektverschl\u00fcsselungs-Technologien wie S\/MIME ein.<\/li><\/ul>\n\n\n\n<h4><strong>Forced TLS with certificate check<\/strong><\/h4>\n\n\n\n<ul><li><strong>Technologie:&nbsp;<\/strong><ul><li>Outbound E-Mail Traffic: Erzwingt (forced) einen TLS Tunnel f\u00fcr eine spezifische Mail Zieldom\u00e4ne (@example.com). Das digitale <strong>Zertifikat<\/strong> des MTAs der Zieldom\u00e4ne wird zus\u00e4tzlich <strong>validiert<\/strong> u.a.:<ul><li>Passt der SAN\/CN zur Zieldom\u00e4ne?<\/li><li>Ist das Zertifikat noch g\u00fcltig? <\/li><li>Ist das Zertifikat ggf. gesperrt (OCSP\/CRL check)?<\/li><li>Ist das Zertifikat trusted? <\/li><li>Ist das Zertifikat vom richtigen Typ &#8211; z.B. server authentication flag. <\/li><\/ul><\/li><li>Inbound E-Mail Traffic: Wenn der sendende MTA (in der Regel identifiziert durch Hostnamen\/IP Adresse) versucht verschl\u00fcsselt \u00fcber STMP over TLS zuzustellen und das Zertifikat wird gepr\u00fcft wird dies akzeptiert. Unverschl\u00fcsselte Mails vom gleichen MTA werden dagegen verworfen.<br><\/li><\/ul><\/li><li><strong>Vorteile:<\/strong><br>Jeglicher Verkehr der zwischen dem sendenden und dem 1. empfangenden MTA f\u00fcr die spezifizierte Maildom\u00e4ne (@example.com) gesendet wird, wird mittels SMTP over TLS auf der Transportebene verschl\u00fcsselt. Kein unverschl\u00fcsselter SMTP Verkehr kann Richtung MTA dieser spezifizierten Dom\u00e4ne losgeschickt werden. Protocol Downlevel Angriffe auf dieser Verbindungsstrecke sind nicht mehr m\u00f6glich. Durch die zus\u00e4tzlich Zertifikats\u00fcberpr\u00fcfung sind Spoofing bzw. Man-in-the-Middle Angriffe zwischen dem sendendend und dem f\u00fcr die Zieldom\u00e4ne autorisierten Mailserver nicht mehr m\u00f6glich.<br><\/li><li><strong>Nachteile:&nbsp;&nbsp;<\/strong><br>Forced TLS with certificate check f\u00fcr SMTP skaliert schlecht. F\u00fcr jede Zieldom\u00e4ne muss eine spezifische Rule auf dem Mailgateway erstellt werden. Mails k\u00f6nnen verloren gehen, wenn es tempor\u00e4re Probleme mit SMTP over TLS bei der f\u00fcr die empfangende Domain zust\u00e4ndigen MTA gibt. Mails k\u00f6nnen verloren gehen, wenn der Zertifikatscheck des MTAs f\u00fcr die Zieldom\u00e4ne fehlschl\u00e4gt. Weiterhin wird die E-Mail nur auf der Strecke vom sendenden bis zum 1. empfangenden MTGA \u00fcber den verschl\u00fcsselten Tunnel gesch\u00fctzt. Wenn die E-Mail mehrere MTAs durchl\u00e4uft so ist ihr Verschl\u00fcsselungsstatus unklar bzw. ist sie unverschl\u00fcsselt. <\/li><li><strong>Empfehlung: <\/strong><br>Setzen sie forced TLS with certificate check nur ein, wenn es ein Businesspartner aus Compliance Gr\u00fcnden von Ihnen verlangt oder wenn sie vertretbare Sicherheit haben wollen und keine Verschl\u00fcsselung auf Mailobjektebene mit dem Businesspartner m\u00f6glich ist. <\/li><\/ul>\n\n\n\n<p>Wie schaut es nun mit der Sicherheit bei Verschl\u00fcsselung auf Mailobjekt-Ebenes aus &#8211; so viel sei verraten: deutlich besser. Mehr dazu  <a href=\"http:\/\/lkl-it.de\/blog\/?p=728\">hier<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n\n<p>Vgl. Q &amp;A Secure E-Mail Communication on https:\/\/mailprotection.redbull.com : <a href=\"https:\/\/mailprotection.redbull.com\/\">\u201eResason for using Secure E-Mail communication\u201c<\/a><\/p>\n\n\n\n<p>sowie<\/p>\n\n\n\n<p>Q &amp;A Secure E-Mail Communication on https:\/\/mailprotection.redbull.com\/standards : <a href=\"https:\/\/mailprotection.redbull.com\/standards.html\">\u201eWhich Standards we offer and why\u201c<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Wie im \u00dcbersichtsartikel beschrieben wird die Verschl\u00fcsselung in einem Transporttunnel zwischen dem sendenden und den ersten empfangenden MTA eingerichtet. Der TLS Tunnel verschl\u00fcsselt dabei den SMTP Protocol Exchange und im Optimalfall auch alle zwischen den MTAs ausgetauschten Maildaten. Das Mailobjekt &hellip; <a href=\"http:\/\/lkl-it.de\/blog\/?p=722\">Weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[33,9,34,14,35,36],"_links":{"self":[{"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/722"}],"collection":[{"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=722"}],"version-history":[{"count":7,"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/722\/revisions"}],"predecessor-version":[{"id":748,"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/722\/revisions\/748"}],"wp:attachment":[{"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=722"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/lkl-it.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}