- Details
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.
- Details
Am 1. November wurde Perdition 2.2 veröffentlicht. Perdition ist ein Proxy Server für die Mail Access Protokolle IMAP(S) und POP3(S) sowie für Managesieve. Er verbindet für die Benutzer transparent deren Zugriffe mit ihrem tatsächlichen Mailbox Server, wobei deren Software und Version keine Rolle spielt, so dass er nicht nur in großen Umgebungen, sondern auch in heterogenen Server-Landschaften verwendet werden kann.
Die neue Version bietet in erster Linie Verbesserungen im Bereich TLS. So kann Perdition 2.2 erstmals Cipher aushandeln, die Perfect Forward Secrecy unterstützen. Die elliptische Kurve der EC-DHE und EC-DH Cipher ist im Code fest vorgegeben. Für die DHE und DH Cipher müssen die benötigten Diffie-Hellman-Parameter erzeugt und Perdition im PEM-Format zur Verfügung gestellt werden.
[root@popc ~]# openssl s_client -connect 10.2.2.2:995
[...]
Server Temp Key: ECDH, prime256v1, 256 bits
[...]
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
[...]
Mit Hilfe der Option ssl_listen_min_proto_version für eingehende Verbindungen und der Option ssl_outgoing_min_proto_version für ausgehende können die TLS-Protokoll-Versionen eingeschränkt werden. Standardmäßig ist SSLV3 bereits abgeschaltet.
Neu ist ebenfalls, dass Perdition bei eingehenden Verbindungen den eigenen in ssl_listen_ciphers festgelegten Prioritäten der Cipher für die Aushandlung folgt und nicht mehr denen des Clients. (Dies kann mittels der Option ssl_no_cipher_server_preference abgeschaltet werden.)
Musste man auf Perfect Forward Secrecy bei Perdition im Production Release zugegebenermaßen etwas warten, lässt sich 2.2 dafür nicht nur gegen OpenSSL 1.0, sondern auch bereits gegen die neue OpenSSL-Version 1.1 kompilieren.
Referenzen:
1. http://horms.net/projects/perdition/