STARTTLS

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 14. Januar 2020 um 10:33 Uhr durch Matthäus Wander (Diskussion | Beiträge) (MTA-STS ergänzt). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen
Eine gesichtete Version dieser Seite, die am 14. Januar 2020 freigegeben wurde, basiert auf dieser Version.

STARTTLS bezeichnet ein Verfahren zum Einleiten der Verschlüsselung einer 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.

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.

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.

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. Bei einer Neubewertung im Jahr 2018 bevorzugen die STARTTLS-Entwickler nunmehr implizites TLS. Von einer Klartextübertragung wird gänzlich abgeraten.[3]

E-Mail

STARTTLS ist seit 1999 als Erweiterung für das Simple Mail Transfer Protocol (SMTP) spezifiert. 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

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 empfiehlt die Nutzung von implizitem TLS für sämtliche Kommunikation zwischen dem Mail User Agent und dem Mail-Service-Provider. Im Fall von SMTP bezieht sich diese Empfehlung ausschließlich auf Mail Submission (User 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.[4] Einen Erklärung dazu gibt der Abschnitt 7.3 des RFC 8314.[3]

Downgrade-Angriff

Ein 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.[5] 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 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

Bei Mail Transfer kann TLS nicht ohne weiteres erzwungen werden, da es für einen 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 an definierter Stelle im Domain Name System abzulegen, sowie den Einsatz von DNSSEC. Dies stellt Hürden für den Server-Betreiber dar.

MTA-STS

Um den Mail-Providern ein 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.[6]

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

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.[6]

Weitere Protokolle

Für HTTP gibt es mit RFC 2817 ein zu STARTTLS vergleichbares Verfahren, um TLS-Verbindungen aufzubauen. Üblicherweise wird hier aber implizites HTTPS nach RFC 2818 verwendet.

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

Normen und Standards

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

Einzelnachweise

  1. ↑ a b https://tools.ietf.org/html/rfc2487
  2. ↑ a b https://tools.ietf.org/html/rfc2595
  3. ↑ a b c https://tools.ietf.org/html/rfc8314
  4. ↑ Port Numbers. Internet Assigned Numbers Authority, 14. September 2009, abgerufen am 15. September 2009.
  5. ↑ Eingriff in E-Mail-Verschlüsselung durch Mobilfunknetz von O2. Heise Verlag, 17. September 2008, abgerufen am 22. August 2014.
  6. ↑ a b https://tools.ietf.org/html/rfc8461
  7. ↑ DRAFT Telnet START-TLS Option. Internet Engineering Task Force - Jeffrey Altman, 15. Dezember 2006, abgerufen am 14. Oktober 2019.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=STARTTLS&oldid=195816076“