RFC 8314 - Der Name ist Programm

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.

Weiterlesen: RFC 8314 - Der Name ist Programm


Cyrus 3.0.1 behebt fiesen 3.0.0er Bug

Neben kleineren Bugs behebt der vor zwei Tagen veröffentlichte Cyrus 3.0.1 einen kuriosen Fehler der 3.0.0er Version, der Mailboxen mit Punkt(en) im Namen quasi zu Write-Only-Devices degradiert. Ein Update auf 3.0.1 dürfte für die meisten 3.0.0er Installationen erforderlich sein.

Zur Demonstration setzen wir unixhierarchysep auf yes — Default in Cyrus 3.0 und die Voraussetzung dafür, dass Mailbox-Namen überhaupt Punkte enthalten können — und legen mittels cyradm die Mailbox pop.3.0.0 sowie deren Unterordner Sent und Sent/2017 an.

Während sich der Admin wie üblich von der Existenz der neuen Mailboxen und der per Default vergebenen ACL überzeugen kann:

localhost> lam user/pop.3.0.0*
user/pop.3.0.0:
  pop.3.0.0 lrswipkxtecdan
user/pop.3.0.0/Sent:
  pop.3.0.0 lrswipkxtecdan
user/pop.3.0.0/Sent/2017:
  pop.3.0.0 lrswipkxtecda
. LOGIN admin xxx
. OK [CAPABILITY ...]
. LIST "" "*pop*"
* LIST (\HasChildren) "/" user/pop.3.0.0
* LIST (\HasChildren) "/" user/pop.3.0.0/Sent
* LIST (\HasNoChildren) "/" user/pop.3.0.0/Sent/2017
. OK Completed (0.000 secs 3 calls)

wird sie dem erfolgreich angemeldeten Benutzer nicht angezeigt. Sofern er seine Ordner kennt, kann er sie durchaus administrieren, z. B. Ordner anlegen, löschen oder Mails lesen, löschen, beantworten, verschieben etc.

. LOGIN pop.3.0.0 test123
. OK [CAPABILITY ...] unknown-unkown-RPM-3.0.0-1.elx server ready
. LIST "" "*"
. OK Completed (0.000 secs)
. SELECT Sent/2017
* [...]
. OK [READ-WRITE] Complete

Cyrus 3.0.1 korrigiert das Phänomen:

. LOGIN pop.3.0.0 test123
. OK [CAPABILITY ...] unknown-unknown-RPM-3.0.1-1.elx server ready
. LIST "" "*"
* LIST (\HasNoChildren) "/" INBOX
* LIST (\HasChildren) "/" Sent
* LIST (\HasNoChildren) "/" Sent/2017
. OK Completed (0.000 secs 3 calls)
. SELECT Sent/2017
* [...]
. OK [READ-WRITE] Completed

Referenzen:

1. http://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.1.html

2. https://github.com/cyrusimap/cyrus-imapd/issues/1875


Cyrus 3.0.0 stable

Letzten Monat wurde Cyrus 3.0.0 veröffentlicht und ist auch gleich die aktuelle stable-Version des beliebten E-Mail-Servers, dessen Entwicklung in den neunziger Jahren des letzten Jahrhunderts an der Carnegie Mellon University in Pittsburgh ihren Anfang nahm.

Cyrus 2.5 erhält vorerst weiterhin Bug und Security Fixes, nicht jedoch Version 2.4, die damit abgekündigt ist.

Auffälligste Neuheit ist das Archivierungssystem. In 3.0 kann man Archiv-Partitionen auf z. B. günstigerer Hardware anlegen, auf die Cyrus ältere Mails automatisch auslagert. Dies geschieht für die Benutzer vollkommen transparent.

Die IMAP Extension Special-Use (RFC 6154) wird von Cyrus 3.0 vollständig unterstützt. Bei Special-Use setzt der IMAP-Server spezielle Flags auf Ordner, die deren besondere Funktion als z. B. Sent- oder Drafs-Ordner kennzeichnen. Die Special-Use Flags können über die autocreate-Funktion von Cyrus automatisch erzeugt werden. Jeder den Standard ebenfalls beherrschende Client (z. B. Thunderbird, Outlook 2016 oder die Webmailer Open-Xchange und Roundcube) verwendet die serverseitigen Flags, um seine Ordner wie "Posteingang", "Entwürfe" oder "Gesendet" mit denen des Servers zu mappen, anstatt, wie in der Vergangenheit häufig der Fall, eigenmächtig neue anzulegen, weil er die vom Server oder anderen Clients bereits vergebenen Namen für Spezial-Ordner nicht verstand. Wer mit unterschiedlichen Clients per IMAP auf seine Mailbox zugriff, hatte früher nur die —nicht einmal immer vorhandene — Möglichkeit des händischen Ordner-Mappings, um nicht in unheilvollem Ordnerchaos zu versinken.

Weiterlesen: Cyrus 3.0.0 stable


Support für OpenSSL 1.0.1 ausgelaufen

Mit Ablauf des Jahres 2016 ist der Support für die OpenSSL-Reihe 1.0.1 abgelaufen. Es wird für 1.0.1 also ab sofort auch keine Security Fixes mehr geben. Nutzer sind aufgefordert, mit deren nächstem Buchstaben-Release auf OpenSSL 1.0.2 umzusteigen. Der Austausch ist transparent möglich. Eine Neukompilierung der gegen OpenSSL 1.0.1 gelinkten Applikationen ist nicht erforderlich, da die Versionen 1.0.x Binary-kompatibel sind.

Ende letzten Jahres wurde OpenSSL 1.0.2 zudem als Long Term Support (LTS) Release auserkoren und erhält damit Support in der Form von sinnvollen Fixes aller Art bis einschließlich 2018 und von ausschließlich Security Fixes bis Ende 2019, um anschließend von ihren eigenen Wählern in den verdienten Ruhestand versetzt zu werden.

Für die Statistiker sei berichtet, dass die 1.0.1er Reihe mit ihrem letzten Release auf u endet und damit die Vorgängerin 1.0.0, deren Tage mit t gezählt waren, mit dem denkbar knappsten Ergebnis - je nach Sichtweise - geschlagen hat oder unterlegen ist. Inwieweit Version 1.0.2 (aktueller Stand: j) diese Plätze angreifen kann, bleibt abzuwarten. In der ewigen Rangliste freilich bleibt die 0.9.8er Reihe unerreicht, deren letzte Versionnummer mit 0.9.8zh dokumentiert ist und uns mehr als zehn Jahre bis Ende 2015 ein verlässlicher Begleiter war.

Referenzen:

1. https://www.openssl.org/policies/releasestrat.html

2. https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/


Perdition Proxy mit Perfect Forward Secrecy

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/


`bcc', das verborgene Feature

Mit Version 8.15.x bietet Sendmail die Möglichkeit, ausgewählten E-Mails einen BCC-Empfänger auf MTA-Ebene hinzuzufügen.

Hierfür muss Sendmail im ersten Schritt mit der Option '_FFR_ADD_BCC' kompiliert werden:

[root@popc ~]# sendmail -d0.14 < /dev/null
Version 8.15.2
[...]
   FFR Defines: _FFR_ADD_BCC _FFR_MAIL_MACRO _FFR_TLS_EC
                _FFR_TLS_SE_OPTS

Anschließend lässt sich das Feature `bcc' wie folgt in sendmail.mc konfigurieren:

FEATURE(`bcc',`<map>’‚`[next hop]',`[default bcc address]'[‚`map for canonical recipients'])dnl

Weiterlesen: `bcc', das verborgene Feature


OpenSSL 1.1.0 veröffentlicht

Seit dem 25. August ist die erste Stable Version von OpenSSL 1.1.0 verfügbar.

Neu hinzugekommene Algorithmen sind u. a. der moderne Stream Cipher ChaCha20 mit Poly1305 Authentisierung, der Message Authentication Mode CCM (Counter with CBC-MAC) für AES Cipher und die elliptische Kurve X25519 für den Diffie-Hellman-Schlüsselaustausch.

Große Teile des Codes wurden für die Version neu geschrieben. Die API ist inkompatibel zu allen Vorgängerversionen, so dass alle Anwendungen, die OpenSSL nutzen, für 1.1.x weitgehend und sorgfältig angepasst werden müssen. Daher dürfte es noch eine Weile dauern, bis die gängigen Linux-Distributionen mit der neuen OpenSSL-Version ausgeliefert werden.

Schutz vor Sweet32

Zugleich mit der Veröffentlichung der Version 1.1.0 reagieren die OpenSSL-Entwickler auf den unter dem Namen Sweet32 bekanntgewordenen Angriff auf 3DES (CVE-2016-2183):

  • In den Versionen der Branches 1.0.2 und 1.0.1 werden die 3DES Cipher aus der Kategorie 'HIGH' nach 'MEDIUM' verschoben. In den 'DEFAULT' Ciphern sind sich nach wie vor enthalten.
  • In der neuen Version 1.1.0 sind die 3DES Cipher, wie RC4, standardmäßig deaktiviert. Sowohl 3DES als auch RC4 können durch Setzen der Option '--enable-weak-ssl-ciphers' mit einkompiliert werden. Ihre Kategorie ist 'MEDIUM', im 'DEFAULT' fehlen sie.

Nicht reanimierbar abgeschaltet wurden in 1.1.0 das veraltete SSLv2-Protokoll (SSLv3 bleibt erhalten) sowie sämtliche 40- und 56-Bit Cipher.

Referenzen:

1. https://www.openssl.org/news/openssl-1.1.0-notes.html

2. https://www.openssl.org/blog/blog/2016/08/24/sweet32

3. https://sweet32.info/SWEET32_CCS16.pdf


Sweet32 beendet eine Ära

Bislang galten Kollisionsangriffe auf Block Cipher ohne Kenntnis des verwendeten Keys als theoretisch möglich, aber für reale Angriffe unattraktiv, weil für deren Erfolg Plaintext teilweise vorausgeahnt werden muss und Gigabytes mitgeschnittener Daten nur wenige Bits Ertrag verheißen. Was jedoch, wenn Teile des Plaintexts vom Angreifer selbst leicht vorgegeben und über den Browser des Opfers die benötigten Datenmengen unauffällig versendet werden können und am Ende die Authentifizierung einer HTTPS oder VPN Session herausspringt? Karhikeyan Bhargavan und Gaëtan Leurent, Forscher des französischen Inria Instituts, demonstrieren in ihrem letzte Woche veröffentlichten Paper nun erstmals die Durchführbarkeit eines Angriffs (den sie auf den Namen Sweet32 getauft haben) auf ältere, aber durchaus noch gebräuchliche 64-Bit Block Cipher wie 3DES und Blowfish (AES dagegen arbeitet mit einer Blockgröße von 128 Bit) mit lohnenswerten Ergebnissen. In weniger als zwei Tagen gelang es ihnen, den Session Cookie einer HTTPS Session und die BasicAuth Credentials einer OpenVPN-Verbindung zu rekonstruieren.

Block Cipher

Im Gegensatz zu Stream Ciphern, bei denen die Verschlüsselung Bit- oder Byte-weise erfolgt, verschlüsseln Block Cipher ihrem Namen entsprechend ganze Blöcke von Plaintext in Blöcke von Ciphertext. Bei Verwendung desselben Keys überführt ein Block Cipher dabei denselben Block Plaintext immer in denselben Block Ciphertext. Um trotzdem eine zufällige, nicht dem Plaintext-Muster entsprechende, Verteilung von Ciphertext-Blöcken zu erreichen, arbeiten Block Cipher in sogenannten Betriebsarten, TLS z. B. zumeist im Cipher Block Chaining (CBC) Mode, wie bei Wikipedia dargestellt:

(Quelle: Wikipedia) 

Weiterlesen: Sweet32 beendet eine Ära


Am 6. Juli angekündigter OpenSSL Patch verfügbar (CVE-2015-1793)

Wie angekündigt sind auf openssl.org die neuen Versionen 1.0.2d und 1.0.1p seit heute verfügbar. Sie beheben einen als High eingestuften Security Bug (CVE-2015-1793) in OpenSSL 1.0.2c, 1.0.2b, 1.0.1n und 1.0.1o. Andere Versionen, insb. auch 0.9.8 und 1.0.0 sind davon nicht betroffen.

Der hier beschriebene Bug gibt Angreifern die Mögichkeit eines Man-In-The-Middle-Angriffs, indem bei der Prüfung einer Zertifikats-Kette bestimmte Checks umgangen werden können. Als fatal wird in dem Zusammenhang das CA-Flag genannt, was dazu führen kann, dass irgendwelche Zertifikate sich als CA ausgeben und unbemerkt gültige Zertifikate für Applikationen ausstellen können.

Betroffen von dem Bug sind OpenSSL-verwendende Applikationen, die Zertifikate prüfen, in erster Linie Clients, aber auch Server, die Clients aufgrund ihrer Zertifikate authentifizieren.

In ihrem Security Advisory erinnern die Entwickler nochmal daran, dass der Support für die Versionen 0.9.8 und 1.0.0 am 31. Dezember 2015 endet. Danach wird es keine Security Fixes mehr für diese Versionen geben.

Referenzen:

1. https://mta.openssl.org/pipermail/openssl-announce/2015-July/000037.html

2. https://www.openssl.org/news/secadv_20150709.txt