- 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
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
- Details
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.
- Details
Adrian et al zeigen in ihrem spannenden Paper nicht nur den von ihnen Logjam genannten Angriff, der auf einem Downgrade auf nur 512-Bit Diffie-Hellman Parameter des unsicheren Ciphers DHE_EXPORT (abschalten!) basiert, sondern haben in HTTPs Scans auch beobachtet, dass in TLS vielfach quasi Standard-Gruppen sowohl für 512 als auch für 768 und 1024 Bit verwendet werden, dies sind entweder die Built-ins (dh512_p, dh1024_p) des weit verbreiteten Apache Webservers oder die in RFC 2409 definierten Oakley Gruppen 1 (768 Bit) und 2 (1024 Bit).
Auch wenn sich die Wissenschaftler selbst mit ihren Ressourcen außerstande sehen, 1024-Bit Diffie-Hellman Gruppen zu knacken, muss dies ihren Ausführungen zufolge nicht für Institutionen gelten, die weitaus mehr Geld für derlei Berechnungen ausgeben können. Da zudem die für Logjam verwendete Methode mit weitestgehenden Vorausberechnungen für die 512-Bit Built-in DH Parameter von Apache, die von den Kryptologen in nur einer Woche vorgenommen werden konnten, arbeitet, empfehlen sie den Einsatz eigens erzeugter Diffie-Hellman 2048-Bit Parameter.
Open Source Software arbeitet i.d.R. mit OpenSSL, das die notwendige Sicherheit bzgl. der Diffie-Hellman Parameter bietet. Ein genauer Blick auf die Dokumention und letztlich die Sourcen der eingesetzten Software lohnt sich jedoch und wer selbst bereits 2048-Bit DH Parameter mittels 'openssl dhparam' produziert hat, kann nachvollziehen, dass kein Server diese, nicht einmal 1024-Bit, beim Start erzeugen und trotzdem binnen einer Sekunde für TLS-Verbindungen bereitstehen kann. Wenn man selbst also keine Parameter zum simplen Einlesen für den Server produziert hat, muss er eigene "Tricks" anwenden, z.B. mittels Built-ins, dem Erzeugen geeigneter Primzahlen beim Kompilieren, "einfacheren" DH-Gruppen etc.
Weiterlesen: Sichere Diffie-Hellman Parameter vor und nach Logjam