Das im Januar 2018 veröffentlichte RFC 8314 "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access" beschreibt die Verwendung von TLS bei E-Mail-Abruf und -Einlieferung in modernen E-Mail-Systemen. E-Mail-Abruf und -Einlieferung durch Mail User Agents (MUAs) bei Mail Access Servern und Mail Submission Servern sollen demnach nur noch über TLS-verschlüsselte Verbindungen (TLS Version 1.2 oder höher) erfolgen.
Neu, beachtens- und begrüßenswert ist, dass jetzt "Implicit TLS" die favorisierte Methode für die Transport-Verschlüsselung bei Abruf und Einlieferung von Mails durch MUAs ist, während vorhergehende Regelungen noch STARTTLS empfahlen. Folgerichtig wurde der bereits vielerorts für Secure Submission verwendete Port 465 im Dezember 2017 auf den Dienst Submissions offiziell registriert. RFC 8314 ist auch ein Update für die Spezifikationen von POP3 (RFC 1939), IMAP (RFC 3501) und Submission (RFCs 6409 und 5068).
Mit STARTTLS stellt ein Client zunächst eine unverschlüsselte Verbindung auf dem (in der Regel Standard-)Klartext-Port des gewünschten Dienstes mit einem Server her und kann anschließend durch das Kommando STARTTLS (STLS bei POP3) eine TLS-Session initiieren ("Explicit TLS"). Im Unterschied dazu wird bei "Implicit TLS" direkt nach dem TCP Handshake ein TLS-verschlüsselter Kanal zwischen Client und Server aufgebaut.
Authentifizierungs-Daten sollen bei beiden Methoden erst dann über die Leitung gehen, wenn die Verbindung verschlüsselt ist. Für SMTP, IMAP und POP3 sind denn auch jeweils Methoden (siehe unten) definiert, genau dies vom Client zu fordern, will man keinen Klartext-Verkehr erlauben. Doch sind diese natürlich im Gegensatz zur impliziten TLS-Verschlüsselung auf dedizierten TLS Ports bereits protokollbedingt anfällig für Implementierungs-Schwächen auf Client-Seite und Man-in-the-middle-Angriffe.
STARTTLS bei Submission via SMTP
Bei "Explicit TLS" besteht für den Server das Problem, dass er dem geneigten Client die Notwendigkeit der Verschlüsselung irgendwie anzeigen und sie erzwingen muss. Dazu bleibt ihm nur die Möglichkeit, Authentifizierungen und Kommandos im Authorization State auf Klartext-Kanälen abzulehnen. Erreichen ihn in dem Fall trotzdem Login-Daten im Klartext, darf er gemäß RFC keine Hinweise auf deren Gültigkeit geben.
Bei Submission via SMTP erfolgt dies über das Schlüsselwort STARTTLS bei gleichzeitiger Nicht-Angabe von Authentifizierungs-Methoden nach dem EHLO-Komando.
C: <opens connection on port 587> S: 250-mailserver.intern Hello pop.intern [10.2.2.2], pleased to meet you C: EHLO pop.intern S: 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-STARTTLS C: AUTH PLAIN S: 503 5.3.3 AUTH not available C: STARTTLS S: 220 2.0.0 Ready to start TLS C & S: <TLS negotiation> C: EHLO pop S: 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN S: 250-AUTH PLAIN LOGIN C: AUTH PLAIN S: 334 C: <Authentication Data>
S: 235 2.0.0 OK Authenticated
Die entprechende M4-Konfiguration von Sendmail lautet in /etc/mail/sendmail.mc wie so oft kurz und knapp:
define(`confAUTH_OPTIONS', `p y')dnl
p steht dabei für die Notwendigkeit eines TLS Layers für Authentifizierung via PLAIN und LOGIN, y deaktiviert Anonymous Login-Mechanismen.
STARTTLS bei IMAP und POP3
Bei IMAP kann die Capability LOGINDISABLED gesetzt werden, solange kein TLS Layer besteht.
C: <opens connection on port 143> S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED] Cyrus IMAP server ready
C: a01 CAPABILITY S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED a01 OK Completed
C: a02 LOGIN <authentication data> S: a02 NO Login only available under a layer C: a03 STARTTLS S: a03 OK Begin TLS negotiation now C & S: <TLS negotiation>
C: a04 CAPABILITY
S: a04 IMAP4rev1 AUTH=PLAIN AUTH=LOGIN C: a05 LOGIN <Authentication Data> S: a05 OK LOGIN completed
Bei POP3 müssen Server und Client das POP3 Extension Mechanism (RFC 2449) implementieren, über dessen CAPA-Kommando der Server angeben kann, dass STLS (STARTTLS-Kommando von POP3) zur Verfügung steht, das USER-Kommando aber nicht.
C: <opens connection on port 110> S: +OK mailserver Cyrus POP3 server ready C: CAPA S: +OK List of capabilities follows S: STLS UIDL .
C: USER <authentication data> S: -ERR [AUTH] USER command only available under a layer C: STLS S: +OK Begin TLS negotiation now
C & S: <TLS negotiation>
C: CAPA
S: UIDL
SASL PLAIN LOGIN
USER
.
C: USER <authentication data> S: +OK Name is a valid mailbox
Cyrus kennt ab Version 2.5.6 die Einstellung tls_required, in /etc/imapd.conf:
tls_required: 1
Damit erzwingt Cyrus für alle angebotenen Authentifizierung-Mechanismen einen TLS Layer.
Beim Perdition Proxy erreicht man dies server-seitig durch Setzen von tls_listen_force als ssl_mode in der Konfiguration des IMAP4 und POP3 Daemons, z. B. server- und client-seitig:
ssl_mode tls_listen_force tls_outgoing_force
oder kürzer:
ssl_mode tls_all_force
Clients sind immer angehalten, Authentifizierungs-Daten nur TLS-verschlüsselt zu übertragen und mit den vorgenannten Methoden verhindert ein Server zumindest, dass mit allen Regeln konform gehende Clients Login-Daten auf unverschlüsselten Kanälen herausblasen. Kompromittiert werden können alle guten Absichten aber durch gezielte Man-in-the-middle-Angriffe, z. B. das Heraussägen von LOGINDISABLED aus den IMAP Capabilities.
Referenzen:
1. https://tools.ietf.org/html/rfc8314
2. https://tools.ietf.org/html/rfc2595
3. https://tools.ietf.org/html/rfc2449
4. https://www.cyrusimap.org/2.5/imap/release-notes/2.5/x/2.5.6.html