„STARTTLS“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen Versionsunterschied
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
K →E-Mail: Tippfehler entfernt
Wam4223 (Diskussion | Beiträge)
4 Bearbeitungen
Linkvorschlag-Funktion: 3 Links hinzugefügt.
Markierungen: Visuelle Bearbeitung Mobile Bearbeitung Mobile Web-Bearbeitung
 
(33 dazwischenliegende Versionen von 15 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''STARTTLS''' bezeichnet ein Verfahren zum Einleiten der [[Verschlüsselung]] einer [[Netzwerkprotokoll|Netzwerkkommunikation]] mittels [[Transport Layer Security]] (TLS). Falls keine zusätzlichen Schutzmaßnahmen gegen einen [[Downgrade-Angriff]] umgesetzt werden, handelt es sich dabei um eine [[opportunistische Verschlüsselung]].
'''STARTTLS''' bezeichnet ein Verfahren zum Einleiten der [[Verschlüsselung]] einer [[Netzwerkprotokoll|Netzwerkkommunikation]] mittels [[Transport Layer Security]] (TLS). Das Verfahren beginnt in einer unverschlüsselten [[Klartext (Kryptographie)|Klartextverbindung]], welche durch das STARTTLS-Kommando zu einer verschlüsselten Verbindung aufgewertet wird. Falls keine zusätzlichen Schutzmaßnahmen gegen einen [[STARTTLS#Downgrade-Angriff|Downgrade-Angriff]] umgesetzt werden, handelt es sich dabei um eine [[opportunistische Verschlüsselung]].


STARTTLS wurde von der [[Internet Engineering Task Force]] (IETF) im Jahr 1999 für [[E-Mail]] standardisiert<ref name="RFC2487" /> und sollte einige Probleme adressieren, die bei der Verwendung von implizitem TLS auf einem separaten [[Port (Netzwerkadresse)|Port]] auftreten.<ref name="RFC2595" /> Seit 2018 rät die IETF jedoch für den Zugriff vom [[Mailclient]] zum [[Mailserver]] von STARTTLS ab und empfiehlt nur noch implizites TLS.<ref name="RFC8314" />
⚫
== Funktionsweise ==


⚫
== Funktionsweise ==
Der [[Client]] baut zunächst eine unverschlüsselte Netzwerkverbindung zum [[Server]] auf und verwendet dabei den für Klartextkommunikation vorgesehenen Port. Sofern der Server Unterstützung von STARTTLS signalisiert, sendet der Client den STARTTLS-Befehl. Die beiden Kommunikationspartner beginnen mit dem TLS-Handshake und handeln eine Verschlüsselung aus. Anschließend wird das Anwendungsprotokoll verschlüsselt fortgesetzt.
Der [[Client]] baut zunächst eine unverschlüsselte Netzwerkverbindung zum [[Server]] auf und verwendet dabei den für Klartextkommunikation vorgesehenen Port. Sofern der Server Unterstützung von STARTTLS signalisiert, sendet der Client den STARTTLS-Befehl. Die beiden Kommunikationspartner beginnen mit dem TLS-Handshake und handeln eine Verschlüsselung aus. Anschließend wird das Anwendungsprotokoll verschlüsselt fortgesetzt.


{{Anker|Implizites TLS}}
STARTTLS unterscheidet sich vom '''impliziten TLS''', bei dem der TLS-Handshake bereits unmittelbar nach Verbindungsaufbau einsetzt, ohne jegliche Klartextkommunikation. Die Nutzung von TLS wird hierbei durch Verwendung eines dedizierten Ports impliziert, der ausschließlich für verschlüsselte Kommunikation verwendet wird.
STARTTLS unterscheidet sich vom '''impliziten TLS''', bei dem der TLS-Handshake bereits unmittelbar nach Verbindungsaufbau einsetzt, ohne jegliche Klartextkommunikation. Die Nutzung von TLS wird hierbei durch Verwendung eines dedizierten Ports impliziert, der ausschließlich für verschlüsselte Kommunikation verwendet wird. Im E-Mail-Client [[Mozilla Thunderbird]] wird diese Einstellung als „SSL/TLS“ bezeichnet.<ref>{{Internetquelle |url=https://www.privacy-handbuch.de/handbuch_31c.htm |titel=E-Mails (allgm.) – Thunderbird – SMTP, POP3, IMAP |werk=Privacy-Handbuch |abruf=2020-05-14}}</ref>


Bei STARTTLS wird hingegen explizit ausgehandelt, ob TLS genutzt werden soll. Als STARTTLS im Jahr 1999 entstand<ref name="rfc2487">https://tools.ietf.org/html/rfc2487</ref><ref name="rfc2595" />, war die unverschlüsselte Datenübertragung im Internet weit verbreitet. In diesem Kontext hatte STARTTLS den Vorteil, dass es einen einfach zu implementierenden Upgrade-Mechanismus darstellt, um TLS zu verwenden, sofern verfügbar, und sonst auf eine unverschlüsselte Übertragung zurückzufallen ([[opportunistische Verschlüsselung]]). Ein weiterer Vorteil ist die Einsparung von Portnummern bei der [[Internet Assigned Numbers Authority|IANA]], da im Gegensatz zu implizitem TLS nur ein Port sowohl für verschlüsselte als auch unverschlüsselte Übertragung benötigt wird.<ref name="rfc2595">https://tools.ietf.org/html/rfc2595</ref>
Bei STARTTLS wird hingegen explizit ausgehandelt, ob TLS genutzt werden soll. Als STARTTLS im Jahr 1999 entstand,<ref name="RFC2487" /><ref name="RFC2595" /> war die unverschlüsselte [[Datenübertragung]] im Internet weit verbreitet. In diesem Kontext hatte STARTTLS den Vorteil, dass es einen einfach zu implementierenden Upgrade-Mechanismus darstellt, um TLS zu verwenden, sofern verfügbar, und sonst auf eine unverschlüsselte Übertragung zurückzufallen ([[opportunistische Verschlüsselung]]). Ein weiterer Vorteil ist die Einsparung von Portnummern bei der [[Internet Assigned Numbers Authority|IANA]], da im Gegensatz zu implizitem TLS nur ein Port sowohl für verschlüsselte als auch unverschlüsselte Übertragung benötigt wird.<ref name="RFC2595" />


Der Hauptnachteil von STARTTLS ist, dass dieser Upgrade-Mechanismus gegen [[Man-in-the-Middle-Angriff]]e anfällig ist. Durch Manipulation der Klartextbefehle kann der Angreifer die TLS-Verschlüsselung verhindern. Zum Schutz vor einem solchen [[Downgrade-Angriff]] sind zusätzliche Maßnahmen erforderlich, beispielsweise [[DNS-based Authentication of Named Entities|DANE]] oder MTA-STS. Ein Nachteil in Verbindung mit einer [[Firewall]] kann sein, dass [[Deep Packet Inspection]] auf Anwendungsschicht benötigt wird, um verschlüsselte und unverschlüsselte Verbindungen zu unterscheiden.
Der Hauptnachteil von STARTTLS ist, dass dieser Upgrade-Mechanismus gegen [[Man-in-the-Middle-Angriff]]e anfällig ist. Durch Manipulation der Klartextbefehle kann der Angreifer die TLS-Verschlüsselung verhindern. Zum Schutz vor einem solchen [[#Downgrade-Angriff|Downgrade-Angriff]] sind zusätzliche Maßnahmen erforderlich, beispielsweise [[#DANE|DANE]] oder [[#MTA-STS|MTA-STS]]. Ein Nachteil in Verbindung mit einer [[Firewall]] kann sein, dass [[Deep Packet Inspection]] auf Anwendungsschicht benötigt wird, um verschlüsselte und unverschlüsselte Verbindungen zu unterscheiden.


In den folgenden Jahren nahm die Verbreitung von TLS weiter zu. Bei einer Neubewertung im Jahr 2018 bevorzugen die STARTTLS-Entwickler nunmehr implizites TLS. Von einer Klartextübertragung wird gänzlich abgeraten.<ref name="rfc8314">https://tools.ietf.org/html/rfc8314</ref>
In den folgenden Jahren nahm die Verbreitung von TLS weiter zu. Seit 2018 rät die IETF beim Zugriff auf einen [[Post Office Protocol|POP3-Server]], [[Internet Message Access Protocol|IMAP-Server]] oder einen [[Mail Submission Agent]] zu implizitem TLS. Von einer Klartextübertragung wird gänzlich abgeraten.<ref name="RFC8314" />


== E-Mail ==
== E-Mail ==
⚫
STARTTLS ist seit 1999 als Erweiterung für das [[Simple Mail Transfer Protocol]] (SMTP) spezifiziert. Der Client beginnt die Verbindung mit dem aus [[Extended SMTP]] bekannten Schlüsselwort <code>EHLO</code>. Falls eine Unterstützung des Servers gegeben ist, listet er STARTTLS als Erweiterung auf. Dem Client steht es anschließend frei mittels des Schlüsselworts <code>STARTTLS</code> den TLS-Handshake einzuleiten.<ref name="RFC2487" />

⚫
STARTTLS ist seit 1999 als Erweiterung für das [[Simple Mail Transfer Protocol]] (SMTP) spezifiziert. Der Client beginnt die Verbindung mit dem aus [[Extended SMTP]] bekannten Schlüsselwort <code>EHLO</code>. Falls eine Unterstützung des Servers gegeben ist, listet er STARTTLS als Erweiterung auf. Dem Client steht es anschließend frei mittels des Schlüsselworts <code>STARTTLS</code> den TLS-Handshake einzuleiten.<ref name="rfc2487" />


Das folgende Beispiel zeigt eine SMTP-Verbindung mit STARTTLS (<span style="color:blue;">Server blau</span>, <span style="color:green;">Client grün</span>):
Das folgende Beispiel zeigt eine SMTP-Verbindung mit STARTTLS (<span style="color:blue;">Server blau</span>, <span style="color:green;">Client grün</span>):
Zeile 30: Zeile 31:
[hier beginnt der TLS-Handshake]
[hier beginnt der TLS-Handshake]


Kurz nach SMTP folgte die Spezifikation für das [[Internet Message Access Protocol]] (IMAP), sowie den heute nicht mehr gängigen [[Application Configuration Access Protocol]] (ACAP) und [[Post Office Protocol]] (POP). Bei letzterem wird als Schlüsselwort <code>STLS</code> verwendet, da Befehle bei POP immer vier Buchstaben lang sind.
Kurz nach SMTP folgte die [[Spezifikation]] für das [[Internet Message Access Protocol]] (IMAP), sowie den heute nicht mehr gängigen [[Application Configuration Access Protocol]] (ACAP) und [[Post Office Protocol]] (POP). Bei letzterem wird als Schlüsselwort <code>STLS</code> verwendet, da Befehle bei POP immer vier Buchstaben lang sind.


=== Ports ===
=== Ports ===

Daneben gibt es auch Portzuweisungen für implizites TLS. Die folgende Tabelle listet die von der [[Internet Assigned Numbers Authority|IANA]] zugewiesenen Portnummern. Der Buchstabe ‚S‘ hinter den Protokollbezeichnungen kennzeichnet die Variante mit implizitem TLS.
Daneben gibt es auch Portzuweisungen für implizites TLS. Die folgende Tabelle listet die von der [[Internet Assigned Numbers Authority|IANA]] zugewiesenen Portnummern. Der Buchstabe ‚S‘ hinter den Protokollbezeichnungen kennzeichnet die Variante mit implizitem TLS.


Zeile 47: Zeile 47:
|}
|}


RFC 8314 empfiehlt die Nutzung von implizitem TLS für sämtliche Kommunikation zwischen dem [[Mail User Agent]] und dem [[E-Mail-Provider]]. Im Fall von SMTP bezieht sich diese Empfehlung ausschließlich auf [[Mail Submission Agent|Mail Submission]] (Nutzer zu Provider), da nur dort die Portnummer konfigurierbar ist.<ref name="rfc8314" /> Über SMTP für [[Mail Transfer Agent|Mail Transfer]] (Provider zu Provider) macht der RFC keine Aussage. Da bei letzterem das Protokoll auf Port 25 festgelegt ist und durch die Kommunikationspartner nicht geändert werden kann, kommt dafür lediglich STARTTLS in Frage.
<nowiki>RFC&nbsp;8314</nowiki><ref name="RFC8314" /> empfiehlt die Nutzung von implizitem TLS für sämtliche Kommunikation zwischen dem [[E-Mail-Programm|Mail User Agent]] und dem [[E-Mail-Anbieter|E-Mail-Provider]]. Im Fall von SMTP bezieht sich diese Empfehlung ausschließlich auf [[Mail Submission Agent|Mail Submission]] (Nutzer zu Provider), da nur dort die Portnummer konfigurierbar ist.<ref name="RFC8314" /> Über SMTP für [[Mail Transfer Agent|Mail Transfer]] (Provider zu Provider) macht der RFC keine Aussage. Da bei letzterem das Protokoll auf Port&nbsp;25 festgelegt ist und durch die Kommunikationspartner nicht geändert werden kann, kommt dafür lediglich STARTTLS in Frage.


Aus historischen Gründen ist neben SMTPS auch ein Protokoll von [[Cisco]] aus dem [[Multicast]]-Umfeld dem TCP-Port 465 zugewiesen.<ref>{{cite web
Aus historischen Gründen ist neben SMTPS auch ein Protokoll von [[Cisco Systems|Cisco]] aus dem [[Multicast]]-Umfeld dem TCP-Port 465 zugewiesen.<ref>{{Internetquelle |url=http://www.iana.org/assignments/port-numbers |titel=Port Numbers |hrsg= [[Internet Assigned Numbers Authority]] |datum=2009-09-14 |abruf=2009-09-15}}</ref> Eine Erklärung dazu gibt der Abschnitt 7.3 des <nowiki>RFC&nbsp;8314</nowiki>.<ref>{{RFC-Internet |RFC=8314 |Titel=Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |Datum=2018 |Abschnitt=7.3}}</ref>
|url = http://www.iana.org/assignments/port-numbers
|title = Port Numbers
|publisher = Internet Assigned Numbers Authority
|date = 2009-09-14
|accessdate = 2009-09-15
}}</ref> Einen Erklärung dazu gibt der Abschnitt 7.3 des RFC 8314.<ref name="rfc8314" />


=== Downgrade-Angriff ===
=== Downgrade-Angriff ===
⚫
Ein [[Man-in-the-Middle-Angriff|Man-in-the-Middle-Angreifer]] kann die TLS-Verschlüsselung stören, indem er die STARTTLS-Erweiterung entfernt oder überschreibt und dadurch vorgibt, der Server unterstütze kein STARTTLS. Dieser Angriff wird auch als ''Stripping Attack'' oder ''STRIPTLS'' bezeichnet und geschah beispielsweise im Dezember 2008 beim Mobilfunk-Provider O2.<ref>{{Internetquelle |url=https://www.heise.de/security/meldung/Eingriff-in-E-Mail-Verschluesselung-durch-Mobilfunknetz-von-O2-206233.html |titel=Eingriff in E-Mail-Verschlüsselung durch Mobilfunknetz von O2 |werk=Heise security |datum=2008-09-17 |abruf=2014-08-22}}</ref>
⚫
Führt der Client die Verarbeitung in der unverschlüsselten Verbindung fort, so ist es dem Angreifer möglich, die E-Mails unbemerkt mitzulesen und zu manipulieren.


⚫
Ein Schutz vor diesem Angriff ist bei Mail Submission vergleichsweise einfach möglich, indem der Mail User Agent so konfiguriert wird, dass er eine Verschlüsselung erfordert. Beispielsweise hatten frühere Thunderbird-Versionen die Auswahl zwischen ''TLS, wenn möglich'' und ''TLS'' (im Sinne von ''TLS erzwingen'').
⚫
Ein [[Man-in-the-Middle-Angriff|Man-in-the-Middle-Angreifer]] kann die TLS-Verschlüsselung stören, indem er STARTTLS-Erweiterung entfernt oder überschreibt und dadurch vorgibt, der Server unterstütze kein STARTTLS. Dieser Angriff wird auch als ''Stripping Attack'' oder ''STRIPTLS'' bezeichnet und geschah beispielsweise im Dezember 2008 beim Mobilfunk-Provider O2.<ref>{{cite web
|url = https://www.heise.de/security/meldung/Eingriff-in-E-Mail-Verschluesselung-durch-Mobilfunknetz-von-O2-206233.html
|title = Eingriff in E-Mail-Verschlüsselung durch Mobilfunknetz von O2
|publisher = Heise Verlag
|date = 2008-09-17
|accessdate = 2014-08-22
⚫
}}</ref>
⚫
Führt der Client die Verarbeitung in der unverschlüsselten Verbindung fort, so ist es dem Angreifer möglich die E-Mails unbemerkt mitzulesen und zu manipulieren.


Bei Mail Transfer kann TLS nicht ohne weiteres erzwungen werden, da es für einen E-Mail-Provider nicht ersichtlich ist, ob der Ziel-Server TLS wirklich unterstützt oder nicht. Um diese Information zu signalisieren, kann der Server-Betreiber die Verfahren DANE oder MTA-STS verwenden.
⚫
Ein Schutz vor diesem Angriff ist bei bei Mail Submission vergleichsweise einfach möglich, indem der Mail User Agent so konfiguriert wird, dass er eine Verschlüsselung erfordert. Beispielsweise hatten frühere Thunderbird-Versionen die Auswahl zwischen „TLS, wenn möglich“ und „TLS“ (im Sinne von „TLS erzwingen“).

⚫
==== DANE ====


⚫
=== DANE ===
{{Hauptartikel|DNS-based Authentication of Named Entities}}
{{Hauptartikel|DNS-based Authentication of Named Entities}}


Bei Mail Transfer kann TLS nicht ohne weiteres erzwungen werden, da es für einen E-Mail-Provider nicht ersichtlich ist, ob der Ziel-Server TLS wirklich unterstützt oder nicht. Um diese Information zu signalisieren, kann der Server-Betreiber ''DANE'' verwenden. DANE erfordert, einen Zertifikats-[[Fingerprint (Hashfunktion)|Fingerprint]] an definierter Stelle im [[Domain Name System]] abzulegen, sowie den Einsatz von [[Domain Name System Security Extensions|DNSSEC]]. Dies stellt Hürden für den Server-Betreiber dar.
''DNS-based Authentication of Named Entities'' (DANE) bindet einen E-Mail-Server an ein [[X.509|PKIX]]-Zertifikat, das auf einen Server oder eine [[Zertifizierungsstelle (Digitale Zertifikate)|Zertifizierungsstelle]] ausgestellt ist. Das Zertifikat kann auch selbstsigniert sein. Der Server-Betreiber muss den [[Fingerprint (Hashfunktion)|Fingerprint]] des Zertifikats an definierter Stelle im [[Domain Name System]] ablegen und [[Domain Name System Security Extensions|DNSSEC]] verwenden. Durch den DNS-Eintrag signalisiert der Server-Betreiber die Unterstützung von STARTTLS und verbietet einen Downgrade auf unverschlüsselte Übertragung.


==== MTA-STS ====
=== MTA-STS ===
⚫
Um den E-Mail-Providern ein zu DANE alternatives Verfahren zur Verfügung zu stellen, hat die [[Internet Engineering Task Force|IETF]] '''SMTP MTA Strict Transport Security''' ('''MTA-STS''') entworfen. MTA-STS erfordert den Einsatz von [[X.509|PKIX]]-Zertifikaten für den Mail-Server sowie für einen Web-Server, auf dem die Policy einer Domain abgelegt wird. Das Vorhandensein einer Policy und damit die Verwendung von MTA-STS signalisiert der Inhaber einer E-Mail-Domain durch einen DNS-Eintrag, der optional DNSSEC-signiert sein kann. Ohne DNSSEC ist das Verfahren gegen Downgrade-Angriffe durch [[DNS-Spoofing]] anfällig.<ref name="RFC8461" />


⚫
MTA-STS erfordert den Einsatz von TLS-Version 1.2 oder höher. Das Mailserver-Zertifikat muss auf den Hostnamen aus dem [[MX Resource Record]] ausgestellt sein. Anders als bei DANE ist die Verwendung selbst ausgestellter Zertifikate nicht möglich.
⚫
Um den E-Mail-Providern ein alternatives Verfahren zur Verfügung zu stellen, hat die [[Internet Engineering Task Force|IETF]] '''SMTP MTA Strict Transport Security''' ('''MTA-STS''') entworfen. MTA-STS erfordert den Einsatz von [[PKIX]]-Zertifikaten für den Mail-Server sowie für einen Web-Server, auf dem die Policy einer Domain abgelegt wird. Das Vorhandensein einer Policy und damit die Verwendung von MTA-STS signalisiert der Inhaber einer E-Mail-Domain durch einen DNS-Eintrag, der optional DNSSEC-signiert sein kann. Ohne DNSSEC ist das Verfahren gegen Downgrade-Angriffe durch [[DNS-Spoofing]] anfällig.<ref name="rfc8461">https://tools.ietf.org/html/rfc8461</ref>

⚫
MTA-STS erfordert den Einsatz von TLS Version 1.2 oder höher. Das Mailserver-Zertifikat muss auf den Hostnamen aus dem [[MX Resource Record]] ausgestellt sein. Anders als bei DANE ist die Verwendung selbst ausgestellter Zertifikate nicht möglich.


Das folgende Beispiel zeigt einen DNS-Eintrag für die Domain example.com:
Das folgende Beispiel zeigt einen DNS-Eintrag für die Domain example.com:
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"


Das Feld „id“ dient zur Feststellung, ob sich eine Policy geändert hat. Die Policy wird unter der URL <code><nowiki>https://mta-sts.example.com/.well-known/mta-sts.txt</nowiki></code> abgelegt und sieht beispielsweise folgendermaßen aus:
Das Feld „id“ dient zur Feststellung, ob sich eine Policy geändert hat. Die Policy wird unter der URL <code style="white-space:nowrap"><nowiki>https://mta-sts.example.com/.well-known/mta-sts.txt</nowiki></code> abgelegt und sieht beispielsweise folgendermaßen aus:


version: STSv1
version: STSv1
Zeile 94: Zeile 81:
max_age: 604800
max_age: 604800


Mit dem Policy-Modus „enforce“ signalisiert der Domain-Inhaber, dass STARTTLS mit einem vertrauenswürdigen Server-Zertifikat zum Einsatz kommt und kein Downgrade auf eine unverschlüsselte Übertragung erfolgen darf.
⚫
MTA-STS und DANE können parallel eingesetzt werden. MTA-STS ist so spezifiziert, dass es eine fehlgeschlagene DANE-Prüfung nicht außer Kraft setzt.<ref name="rfc8461" />

⚫
MTA-STS und DANE können parallel eingesetzt werden. MTA-STS ist so spezifiziert, dass es eine fehlgeschlagene DANE-Prüfung nicht außer Kraft setzt.<ref name="RFC8461" />

{{Siehe auch|HTTP Strict Transport Security}}

=== SMTP TLS Reporting ===
Parallel zu MTA-STS hat die IETF mit '''SMTP TLS Reporting''' ('''TLSRPT''') ein Verfahren für ein automatisiertes [[Berichtswesen|Reporting]] über die Verwendung von TLS eingeführt.<ref>{{RFC-Internet |RFC=8460 |Titel= |Datum=}}</ref> Der Zweck ist es, dass ein E-Mail-Provider Kenntnis über TLS-Fehler eingehender SMTP-Verbindungen erhält, die durch eine Fehlkonfiguration, Interoperabilitätsprobleme oder Downgrade-Angriffe bedingt sein können. Das Reporting schließt damit eine Informationslücke, da es für einen E-Mail-Provider nur schwer ersichtlich ist, ob gerade regulär kein E-Mail-Verkehr stattfindet oder ob der Verkehr durch ein technisches Problem beeinträchtigt ist.

TLS-Reporting wird ähnlich wie [[DMARC]]-Reporting per [[TXT Resource Record]] im DNS konfiguriert. Das folgende Beispiel zeigt den TXT-Record für eine E-Mail-Domain ''example.com'':
_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=<nowiki>mailto:reports@example.com</nowiki>"

Neben der Zustellung von Reports per E-Mail ist auch [[Hypertext Transfer Protocol Secure|HTTPS]] als Zustellungsmethode spezifiziert. Die Reports verwenden das [[JavaScript Object Notation|JSON]]-Textformat mit einem zu [[HTTP Public Key Pinning|HPKP]]-Reports verwandten Schema. Im Report ist eine Statistik über erfolgreiche und fehlerhafte TLS-Verbindungen enthalten sowie welche DANE- oder MTA-STS-Policy angewandt wurde.


== StartTLS bei weiteren Protokollen ==
== Weitere Protokolle ==
Für [[Hypertext Transfer Protocol|HTTP]] gibt es mit RFC 2817 ein zu STARTTLS vergleichbares Verfahren, um TLS-Verbindungen aufzubauen. Üblicherweise wird hier aber implizites [[Hypertext Transfer Protocol Secure|HTTPS]] nach RFC 2818 verwendet.
Für [[Hypertext Transfer Protocol|HTTP]] gibt es mit <nowiki>RFC&nbsp;2817</nowiki><ref>{{RFC-Internet |RFC=2817 |Titel=Upgrading to TLS Within HTTP/1.1 |Datum=2000-05}}</ref> ein zu STARTTLS vergleichbares Verfahren, um TLS-Verbindungen aufzubauen. Üblicherweise wird hier aber implizites [[Hypertext Transfer Protocol Secure|HTTPS]] nach <nowiki>RFC&nbsp;2818</nowiki><ref>{{RFC-Internet |RFC=2818 |Titel=HTTP Over TLS |Datum=2000-05}}</ref> verwendet. Mit dem in <nowiki>RFC&nbsp;9460</nowiki><ref>{{RFC-Internet |RFC=9460 |Titel=Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) |Datum=2023-11 }}</ref> eingeführten [[HTTPS Resource Record]] gibt es die Möglichkeit, die Verwendung von HTTPS zu forcieren.


Auch bei [[Lightweight Directory Access Protocol|LDAP]] (RFC 4511), [[File Transfer Protocol|FTP]] (RFC 4217) und [[Extensible Messaging and Presence Protocol|XMPP]] (RFC 6120) sowie [[Network News Transfer Protocol|NNTP]] (RFC 4642) kann Mithilfe des STARTTLS-Kommandos die Verschlüsselung initiiert werden. Für Telnet existiert ein Entwurf.<ref>{{cite web
Auch bei [[Lightweight Directory Access Protocol|LDAP]] (<nowiki>RFC&nbsp;4511</nowiki><ref>{{RFC-Internet |RFC=4511 |Titel=Lightweight Directory Access Protocol (LDAP): The Protocol |Datum=2006-06}}</ref>), [[File Transfer Protocol|FTP]] (<nowiki>RFC&nbsp;4217</nowiki><ref>{{RFC-Internet |RFC=4217 |Titel=Securing FTP with TLS |Datum=2005-10}}</ref>) und [[Extensible Messaging and Presence Protocol|XMPP]] (<nowiki>RFC&nbsp;6120</nowiki><ref>{{RFC-Internet |RFC=6120 |Titel=Extensible Messaging and Presence Protocol (XMPP): Core |Datum=2011-03}}</ref>) sowie [[Network News Transfer Protocol|NNTP]] (<nowiki>RFC&nbsp;4642</nowiki><ref>{{RFC-Internet |RFC=4642 |Titel=Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) |Datum=2006-10}}</ref>) kann Mithilfe des STARTTLS-Kommandos die Verschlüsselung initiiert werden. Für [[Telnet]] existiert ein Entwurf.<ref>{{Internetquelle |autor=Jeffrey Altman |url=https://tools.ietf.org/html/draft-altman-telnet-starttls-02 |titel=DRAFT Telnet START-TLS Option |hrsg=Internet Engineering Task Force |datum=2006-12-15 |abruf=2019-10-14}}</ref>
|url = https://tools.ietf.org/html/draft-altman-telnet-starttls-02
|title = DRAFT Telnet START-TLS Option
|publisher = Internet Engineering Task Force - Jeffrey Altman
|date = 2006-12-15
|accessdate = 2019-10-14
⚫
}}</ref>


== Normen und Standards ==
== Normen und Standards ==
* RFC 2487 (1999, erste Version, veraltet): SMTP Service Extension for Secure SMTP over TLS.
* {{RFC-Internet |RFC=2487 |Titel=SMTP Service Extension for Secure SMTP over TLS |Datum=1999 |Kommentar=erste Version, veraltet}}
* RFC 3207 (2002, zweite Version): SMTP Service Extension for Secure SMTP over Transport Layer Security.
* {{RFC-Internet |RFC=3207 |Titel=SMTP Service Extension for Secure SMTP over Transport Layer Security |Datum=2002 |Kommentar=zweite Version}}
* RFC 7817 (2016, Ergänzungen): Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols.
* {{RFC-Internet |RFC=7817 |Titel=Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols |Datum=2016 |Kommentar=Ergänzungen}}
* RFC 8314 (2018, Empfehlung für SMTPS statt STARTTLS) Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
* {{RFC-Internet |RFC=8314 |Titel=Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |Datum=2018 |Kommentar=Empfehlung für SMTPS statt STARTTLS}}


== Weblinks ==
== Weblinks ==
* [https://de.ssl-tools.net/mailservers SMTP TLS Tests and Tools in deutsch] (um selbst genutzte E-Mail-Provider auf TLS-Verschlüsselung zu testen)
* [https://de.ssl-tools.net/mailservers SMTP TLS Tests and Tools in Deutsch] (um selbst genutzte E-Mail-Provider auf TLS-Verschlüsselung zu testen)
* Jürgen Schmidt: [https://www.heise.de/security/meldung/Zwangsverschluesselung-fuer-E-Mail-Transport-4177168.html Zwangsverschlüsselung für E-Mail-Transport.] [[heise online]], 28. September 2018.
* Jürgen Schmidt: [https://www.heise.de/security/meldung/Zwangsverschluesselung-fuer-E-Mail-Transport-4177168.html Zwangsverschlüsselung für E-Mail-Transport.] [[heise online]], 28. September 2018.
* [https://www.fastmail.com/help/technical/ssltlsstarttls.html Unterschiede zwischen SSL, TLS und STARTTLS (englisch)]
* [https://www.fastmail.com/help/technical/ssltlsstarttls.html Unterschiede zwischen SSL, TLS und STARTTLS.] fastmail.com (englisch).


== Einzelnachweise ==
== Einzelnachweise ==
<references />
<references>
<ref name="RFC2487">
{{RFC-Internet |RFC=2487 |Titel=SMTP Service Extension for Secure SMTP over TLS |Datum=1999 |Kommentar=erste Version, veraltet}}
⚫
</ref>
<ref name="RFC2595">
{{RFC-Internet |RFC=2595 |Titel=Using TLS with IMAP, POP3 and ACAP |Datum=1999-06}}
⚫
</ref>
<ref name="RFC8314">
{{RFC-Internet |RFC=8314 |Titel=Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |Datum=2018 |Kommentar=Empfehlung für SMTPS statt STARTTLS}}
</ref>
<ref name="RFC8461">
{{RFC-Internet |RFC=8461 |Titel=SMTP MTA Strict Transport Security (MTA-STS) |Datum=2018-09}}
</ref>
</references>


⚫
[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]
{{SORTIERUNG:Starttls}}
⚫
[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Internet-E-Mail-Protokoll]]
[[Kategorie:Internet-E-Mail-Protokoll]]
[[Kategorie:HTTP]]
[[Kategorie:HTTP]]
[[Kategorie:Transport Layer Security]]
[[Kategorie:Internetstandard]]

Aktuelle Version vom 29. November 2024, 11:49 Uhr

STARTTLS bezeichnet ein Verfahren zum Einleiten der Verschlüsselung einer Netzwerkkommunikation mittels Transport Layer Security (TLS). Das Verfahren beginnt in einer unverschlüsselten Klartextverbindung, welche durch das STARTTLS-Kommando zu einer verschlüsselten Verbindung aufgewertet wird. Falls keine zusätzlichen Schutzmaßnahmen gegen einen Downgrade-Angriff umgesetzt werden, handelt es sich dabei um eine opportunistische Verschlüsselung.

STARTTLS wurde von der Internet Engineering Task Force (IETF) im Jahr 1999 für E-Mail standardisiert[1] und sollte einige Probleme adressieren, die bei der Verwendung von implizitem TLS auf einem separaten Port auftreten.[2] Seit 2018 rät die IETF jedoch für den Zugriff vom Mailclient zum Mailserver von STARTTLS ab und empfiehlt nur noch implizites TLS.[3]

Funktionsweise

[Bearbeiten | Quelltext bearbeiten]

Der Client baut zunächst eine unverschlüsselte Netzwerkverbindung zum Server auf und verwendet dabei den für Klartextkommunikation vorgesehenen Port. Sofern der Server Unterstützung von STARTTLS signalisiert, sendet der Client den STARTTLS-Befehl. Die beiden Kommunikationspartner beginnen mit dem TLS-Handshake und handeln eine Verschlüsselung aus. Anschließend wird das Anwendungsprotokoll verschlüsselt fortgesetzt.

STARTTLS unterscheidet sich vom impliziten TLS, bei dem der TLS-Handshake bereits unmittelbar nach Verbindungsaufbau einsetzt, ohne jegliche Klartextkommunikation. Die Nutzung von TLS wird hierbei durch Verwendung eines dedizierten Ports impliziert, der ausschließlich für verschlüsselte Kommunikation verwendet wird. Im E-Mail-Client Mozilla Thunderbird wird diese Einstellung als „SSL/TLS“ bezeichnet.[4]

Bei STARTTLS wird hingegen explizit ausgehandelt, ob TLS genutzt werden soll. Als STARTTLS im Jahr 1999 entstand,[1][2] war die unverschlüsselte Datenübertragung im Internet weit verbreitet. In diesem Kontext hatte STARTTLS den Vorteil, dass es einen einfach zu implementierenden Upgrade-Mechanismus darstellt, um TLS zu verwenden, sofern verfügbar, und sonst auf eine unverschlüsselte Übertragung zurückzufallen (opportunistische Verschlüsselung). Ein weiterer Vorteil ist die Einsparung von Portnummern bei der IANA, da im Gegensatz zu implizitem TLS nur ein Port sowohl für verschlüsselte als auch unverschlüsselte Übertragung benötigt wird.[2]

Der Hauptnachteil von STARTTLS ist, dass dieser Upgrade-Mechanismus gegen Man-in-the-Middle-Angriffe anfällig ist. Durch Manipulation der Klartextbefehle kann der Angreifer die TLS-Verschlüsselung verhindern. Zum Schutz vor einem solchen Downgrade-Angriff sind zusätzliche Maßnahmen erforderlich, beispielsweise DANE oder MTA-STS. Ein Nachteil in Verbindung mit einer Firewall kann sein, dass Deep Packet Inspection auf Anwendungsschicht benötigt wird, um verschlüsselte und unverschlüsselte Verbindungen zu unterscheiden.

In den folgenden Jahren nahm die Verbreitung von TLS weiter zu. Seit 2018 rät die IETF beim Zugriff auf einen POP3-Server, IMAP-Server oder einen Mail Submission Agent zu implizitem TLS. Von einer Klartextübertragung wird gänzlich abgeraten.[3]

E-Mail

[Bearbeiten | Quelltext bearbeiten]

STARTTLS ist seit 1999 als Erweiterung für das Simple Mail Transfer Protocol (SMTP) spezifiziert. Der Client beginnt die Verbindung mit dem aus Extended SMTP bekannten Schlüsselwort EHLO. Falls eine Unterstützung des Servers gegeben ist, listet er STARTTLS als Erweiterung auf. Dem Client steht es anschließend frei mittels des Schlüsselworts STARTTLS den TLS-Handshake einzuleiten.[1]

Das folgende Beispiel zeigt eine SMTP-Verbindung mit STARTTLS (Server blau, Client grün): 

220 mx1001.wikimedia.org ESMTP Exim 4.89 Mon, 13 Jan 2020 23:12:13 +0000
EHLO client.example.org
250-mx1001.wikimedia.org Hello client.example.org [2001:db8:13b:2048::113]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-STARTTLS
250 HELP
STARTTLS
220 TLS go ahead
[hier beginnt der TLS-Handshake]

Kurz nach SMTP folgte die Spezifikation für das Internet Message Access Protocol (IMAP), sowie den heute nicht mehr gängigen Application Configuration Access Protocol (ACAP) und Post Office Protocol (POP). Bei letzterem wird als Schlüsselwort STLS verwendet, da Befehle bei POP immer vier Buchstaben lang sind.

Ports

[Bearbeiten | Quelltext bearbeiten]

Daneben gibt es auch Portzuweisungen für implizites TLS. Die folgende Tabelle listet die von der IANA zugewiesenen Portnummern. Der Buchstabe ‚S‘ hinter den Protokollbezeichnungen kennzeichnet die Variante mit implizitem TLS.

Protokoll (Port) Protokoll mit implizitem TLS (Port) Bemerkung
SMTP (587, teilweise auch 25) SMTPS (465) Bezieht sich nur auf Mail Submission.
IMAP (143) IMAPS (993)
POP3 (110) POP3S (995)

RFC 8314[3] empfiehlt die Nutzung von implizitem TLS für sämtliche Kommunikation zwischen dem Mail User Agent und dem E-Mail-Provider. Im Fall von SMTP bezieht sich diese Empfehlung ausschließlich auf Mail Submission (Nutzer zu Provider), da nur dort die Portnummer konfigurierbar ist.[3] Über SMTP für Mail Transfer (Provider zu Provider) macht der RFC keine Aussage. Da bei letzterem das Protokoll auf Port 25 festgelegt ist und durch die Kommunikationspartner nicht geändert werden kann, kommt dafür lediglich STARTTLS in Frage.

Aus historischen Gründen ist neben SMTPS auch ein Protokoll von Cisco aus dem Multicast-Umfeld dem TCP-Port 465 zugewiesen.[5] Eine Erklärung dazu gibt der Abschnitt 7.3 des RFC 8314.[6]

Downgrade-Angriff

[Bearbeiten | Quelltext bearbeiten]

Ein Man-in-the-Middle-Angreifer kann die TLS-Verschlüsselung stören, indem er die STARTTLS-Erweiterung entfernt oder überschreibt und dadurch vorgibt, der Server unterstütze kein STARTTLS. Dieser Angriff wird auch als Stripping Attack oder STRIPTLS bezeichnet und geschah beispielsweise im Dezember 2008 beim Mobilfunk-Provider O2.[7] Führt der Client die Verarbeitung in der unverschlüsselten Verbindung fort, so ist es dem Angreifer möglich, die E-Mails unbemerkt mitzulesen und zu manipulieren.

Ein Schutz vor diesem Angriff ist bei Mail Submission vergleichsweise einfach möglich, indem der Mail User Agent so konfiguriert wird, dass er eine Verschlüsselung erfordert. Beispielsweise hatten frühere Thunderbird-Versionen die Auswahl zwischen TLS, wenn möglich und TLS (im Sinne von TLS erzwingen).

Bei Mail Transfer kann TLS nicht ohne weiteres erzwungen werden, da es für einen E-Mail-Provider nicht ersichtlich ist, ob der Ziel-Server TLS wirklich unterstützt oder nicht. Um diese Information zu signalisieren, kann der Server-Betreiber die Verfahren DANE oder MTA-STS verwenden.

DANE

[Bearbeiten | Quelltext bearbeiten]

DNS-based Authentication of Named Entities (DANE) bindet einen E-Mail-Server an ein PKIX-Zertifikat, das auf einen Server oder eine Zertifizierungsstelle ausgestellt ist. Das Zertifikat kann auch selbstsigniert sein. Der Server-Betreiber muss den Fingerprint des Zertifikats an definierter Stelle im Domain Name System ablegen und DNSSEC verwenden. Durch den DNS-Eintrag signalisiert der Server-Betreiber die Unterstützung von STARTTLS und verbietet einen Downgrade auf unverschlüsselte Übertragung.

MTA-STS

[Bearbeiten | Quelltext bearbeiten]

Um den E-Mail-Providern ein zu DANE alternatives Verfahren zur Verfügung zu stellen, hat die IETF SMTP MTA Strict Transport Security (MTA-STS) entworfen. MTA-STS erfordert den Einsatz von PKIX-Zertifikaten für den Mail-Server sowie für einen Web-Server, auf dem die Policy einer Domain abgelegt wird. Das Vorhandensein einer Policy und damit die Verwendung von MTA-STS signalisiert der Inhaber einer E-Mail-Domain durch einen DNS-Eintrag, der optional DNSSEC-signiert sein kann. Ohne DNSSEC ist das Verfahren gegen Downgrade-Angriffe durch DNS-Spoofing anfällig.[8]

MTA-STS erfordert den Einsatz von TLS-Version 1.2 oder höher. Das Mailserver-Zertifikat muss auf den Hostnamen aus dem MX Resource Record ausgestellt sein. Anders als bei DANE ist die Verwendung selbst ausgestellter Zertifikate nicht möglich.

Das folgende Beispiel zeigt einen DNS-Eintrag für die Domain example.com: 

_mta-sts.example.com.   IN TXT "v=STSv1; id=20160831085700Z;"

Das Feld „id“ dient zur Feststellung, ob sich eine Policy geändert hat. Die Policy wird unter der URL https://mta-sts.example.com/.well-known/mta-sts.txt abgelegt und sieht beispielsweise folgendermaßen aus: 

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
mx: backupmx.example.com
max_age: 604800

Mit dem Policy-Modus „enforce“ signalisiert der Domain-Inhaber, dass STARTTLS mit einem vertrauenswürdigen Server-Zertifikat zum Einsatz kommt und kein Downgrade auf eine unverschlüsselte Übertragung erfolgen darf.

MTA-STS und DANE können parallel eingesetzt werden. MTA-STS ist so spezifiziert, dass es eine fehlgeschlagene DANE-Prüfung nicht außer Kraft setzt.[8]

SMTP TLS Reporting

[Bearbeiten | Quelltext bearbeiten]

Parallel zu MTA-STS hat die IETF mit SMTP TLS Reporting (TLSRPT) ein Verfahren für ein automatisiertes Reporting über die Verwendung von TLS eingeführt.[9] Der Zweck ist es, dass ein E-Mail-Provider Kenntnis über TLS-Fehler eingehender SMTP-Verbindungen erhält, die durch eine Fehlkonfiguration, Interoperabilitätsprobleme oder Downgrade-Angriffe bedingt sein können. Das Reporting schließt damit eine Informationslücke, da es für einen E-Mail-Provider nur schwer ersichtlich ist, ob gerade regulär kein E-Mail-Verkehr stattfindet oder ob der Verkehr durch ein technisches Problem beeinträchtigt ist.

TLS-Reporting wird ähnlich wie DMARC-Reporting per TXT Resource Record im DNS konfiguriert. Das folgende Beispiel zeigt den TXT-Record für eine E-Mail-Domain example.com: 

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:reports@example.com"

Neben der Zustellung von Reports per E-Mail ist auch HTTPS als Zustellungsmethode spezifiziert. Die Reports verwenden das JSON-Textformat mit einem zu HPKP-Reports verwandten Schema. Im Report ist eine Statistik über erfolgreiche und fehlerhafte TLS-Verbindungen enthalten sowie welche DANE- oder MTA-STS-Policy angewandt wurde.

StartTLS bei weiteren Protokollen

[Bearbeiten | Quelltext bearbeiten]

Für HTTP gibt es mit RFC 2817[10] ein zu STARTTLS vergleichbares Verfahren, um TLS-Verbindungen aufzubauen. Üblicherweise wird hier aber implizites HTTPS nach RFC 2818[11] verwendet. Mit dem in RFC 9460[12] eingeführten HTTPS Resource Record gibt es die Möglichkeit, die Verwendung von HTTPS zu forcieren.

Auch bei LDAP (RFC 4511[13]), FTP (RFC 4217[14]) und XMPP (RFC 6120[15]) sowie NNTP (RFC 4642[16]) kann Mithilfe des STARTTLS-Kommandos die Verschlüsselung initiiert werden. Für Telnet existiert ein Entwurf.[17]

Normen und Standards

[Bearbeiten | Quelltext bearbeiten]
  • RFC: 2487 – SMTP Service Extension for Secure SMTP over TLS. 1999 (erste Version, veraltet, englisch).
  • RFC: 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security. 2002 (zweite Version, englisch).
  • RFC: 7817 – Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols. 2016 (Ergänzungen, englisch).
  • RFC: 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. 2018 (Empfehlung für SMTPS statt STARTTLS, englisch).
[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ a b c RFC: 2487 – SMTP Service Extension for Secure SMTP over TLS. 1999 (erste Version, veraltet, englisch).
  2. ↑ a b c RFC: 2595 – Using TLS with IMAP, POP3 and ACAP. Juni 1999 (englisch).
  3. ↑ a b c d RFC: 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. 2018 (Empfehlung für SMTPS statt STARTTLS, englisch).
  4. ↑ E-Mails (allgm.) – Thunderbird – SMTP, POP3, IMAP. In: Privacy-Handbuch. Abgerufen am 14. Mai 2020.
  5. ↑ Port Numbers. Internet Assigned Numbers Authority, 14. September 2009, abgerufen am 15. September 2009.
  6. ↑ RFC: 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. 2018, Abschnitt 7.3 (englisch).
  7. ↑ Eingriff in E-Mail-Verschlüsselung durch Mobilfunknetz von O2. In: Heise security. 17. September 2008, abgerufen am 22. August 2014.
  8. ↑ a b RFC: 8461 – SMTP MTA Strict Transport Security (MTA-STS). September 2018 (englisch).
  9. ↑ RFC: 8460 (englisch).
  10. ↑ RFC: 2817 – Upgrading to TLS Within HTTP/1.1. Mai 2000 (englisch).
  11. ↑ RFC: 2818 – HTTP Over TLS. Mai 2000 (englisch).
  12. ↑ RFC: 9460 – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023 (englisch).
  13. ↑ RFC: 4511 – Lightweight Directory Access Protocol (LDAP): The Protocol. Juni 2006 (englisch).
  14. ↑ RFC: 4217 – Securing FTP with TLS. Oktober 2005 (englisch).
  15. ↑ RFC: 6120 – Extensible Messaging and Presence Protocol (XMPP): Core. März 2011 (englisch).
  16. ↑ RFC: 4642 – Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). Oktober 2006 (englisch).
  17. ↑ Jeffrey Altman: DRAFT Telnet START-TLS Option. Internet Engineering Task Force, 15. Dezember 2006, abgerufen am 14. Oktober 2019.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=STARTTLS&oldid=250795754“