- Details
Sendmail 8.16.1 (veröffentlicht am 5. Juli 2020) bringt in erster Linie Erweiterungen im Bereich TLS.
TLS
Die in Sendmail 8.15.2 bereits als FFR (For Future Release) vorhandenen session-basiert einstellbaren TLS Features sind jetzt offiziell unterstützter Bestandteil. Eingestellt werden können durch Semikolon getrennt folgende key=value Paare:
- ServerSSLOptions, ClientSSLOptions z.B. zur Einschränkung der erlaubten SSL-Versionen (siehe SSL_set_options(3))
- CipherList
- Cert- und KeyFile geben Zertifikats- und Schlüssel-Datei für diese Session an
- Flags (bisher 2)
- R für CRL (Certificate Revocation List) benötigt
- c, C zum Aus- bzw. Einschalten der neuen Option TLSFallbacktoClear (siehe unten)
Beispiel für Access-DB bei aktiviertem FEATURE `tls_session_features':
TLS_Clt_features:192.168.2.2 Options=SSL_OP_NO_TLSv1_2; CipherList=ALL:-EXPORT; Flags=C
Interoperabilitätsprobleme bei TLS kann Sendmail jetzt automatisch umschiffen, indem er nach gescheitertem Handshake die Verbindung zur Gegenstelle erneut aufbaut, dieses Mal ohne Verwendung von STARTTLS. Dieses Verhalten wird global durch die Konfiguration von TLSFallbacktoClear erreicht oder per Session durch Setzen des C-Flags der TLS_Clt_Features (siehe oben). Vor 8.16 konnte man lediglich für bekannte inkompatible Server statische TLS-Ausnahmen (Try_TLS:broken.server NO) einrichten.
- Details
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/
- 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/
- Details
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
- Details
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
- Details
Mit Veröffentlichung der neuen OpenSSL-Versionen 1.0.1n und 1.0.2b integrieren die Entwickler einen Client-Schutz vor dem im Mai bekannt gewordenen Logjam-Angriff, der insb. dadurch ermöglicht wird, dass sich Clients auf Diffie-Hellman Parameter geringer Länge (dort 512-Bit) einlassen, auch wenn sie aufgrund der von ihnen vorgeschlagenen Cipher Anderes im Sinn hatten.
OpenSSL-Clients lehnen nun TLS Handshakes mit DH Parametern geringerer Länge als 768 Bit ab, in zukünftigen Versionen soll diese Grenze auf 1024 Bit angehoben werden.
Zu beachten ist dabei, dass die meist verwendeten Browser wie IE (Microsoft hat die Lücke bereits geschlossen, Minimallänge 1024 Bit), Firefox, Chrome nicht auf OpenSSL basieren. Für MTAs im Open Source Bereich ist die Meldung aber interessant, weil die Clients vorher den 512-Bit Primzahlen eines Man-In-The-Middle evtl. schutzlos ausgeliefert waren.
Referenzen:
1. https://weakdh.org/imperfect-forward-secrecy.pdf
2. https://www.openssl.org/news/secadv_20150611.txt
3. https://technet.microsoft.com/en-us/library/security/ms15-055.aspx
- 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
- Details
Perfect Forward Secrecy (PFS) in der Kryptographie meint, dass durch das Erlangen von geheimen Masterschlüsseln, die zur Erstellung der Sitzungsschlüssel verwendet wurden, nicht auf den Inhalt zukünftig oder bereits aufgezeichneter Kommunikation der Schlüsselverwender geschlossen werden kann. Ein gestohlener Masterschlüssel ist damit nicht mehr wert als ein gestohlender Sitzungsschlüssel, beide erlauben jeweils nur die Entschlüsselung "ihrer" Session.
TLS bietet dafür zwei Verfahren:
- Ephemeral Diffie-Hellman (DHE)
- Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
Das Diffie-Hellman-Verfahren bedient sich zur Ermittlung eines gemeinsamen Sitzungsschlüssels einer einfach zu berechnenden mathematischen Funktion, deren Umkehr bei ausreichender Länge der gewählten Parameter bislang als nicht lösbar gilt. Neben anderen erzeugen die Kommunikationspartner dabei jeweils zwei zufällige Parameter, von denen sie einen dem Partner während des TLS Handshakes unverschlüsselt zusenden. Mit den öffentlich übertragenen Parametern und dem eigenen geheimen berechnen beide den gemeinsamen Schlüssel für die eigentliche verschlüsselte Verbindung.
Perfect Forward Secrecy wird bei TLS mittels Ephemeral (flüchtig) Diffie-Hellman erreicht. Hierbei dürfen die Parameter nicht wiederverwendet, sondern müssen für jede Session absolut zufällig neu generiert werden. Wichtig ist, dass dies von beiden Teilnehmern gemacht wird, weil aus jedem der Geheimnisse plus den im Klartext übertragenen öffentlichen Parametern der Sitzungsschlüssel errechnet werden kann.
Der Schlüsselaustausch im RSA-Verfahren bietet keine Perfect Forward Secrecy, weil die damit generierten Sitzungsschlüssel vom Private Key des Servers abhängen. Bei Diffie-Hellman dient der Server-Schlüssel lediglich dazu, den öffentlich übertragenen Diffie-Hellman Public Key zu signieren, um Man-in-the-Middle-Attacken zu unterbinden.
OpenSSL Cipherlist
Sendmail verwendet die Cipherlist Syntax von OpenSSL, so dass sie sich mit Hilfe des Kommandos 'openssl ciphers -v [cipherlist]' gut testen lässt. Ab OpenSSL-Version 1.0.0 kann man alternativ den Parameter '-V' nutzen, wodurch zusätzlich die Cipher ID ausgegeben wird. Das kann sehr hilfreich sein, weil OpenSSL nicht immer die RFC-Namen verwendet und man die Cipher anhand ihrer ID identifizieren muss.
Wir beginnen mit den Ciphern, die wir ausschließen wollen:
!kECDH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!SEED
Die Keywords für die Konfiguration der Cipherlist sind prinzipiell hier dokumentiert. Leider ist die Seite nie ganz aktuell; welche Keywords eine OpenSSL-Version genau unterstützt, kann man im jeweiligen Source nachlesen.
Wir wollen unsere 'ECDHE' (vorrangig, weil schneller) und 'DHE' Suites voranstellen:
EECDH:EDH:!kECDH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!SEED
- Details
Auch wenn der POODLE es nicht direkt auf SMTP-Verbindungen abgesehen hat, erinnert er doch nochmal daran, SSLv3 (und *hüstel* SSLv2) auch in MTAs abzuschalten.
Sendmail muss dafür mit _FFR_TLS_1 kompiliert sein, wodurch u. a. die Optionen 'CipherList' sowie 'ServerSSLOptions' und 'ClientSSLOptions' aktiviert werden. Das ist, obwohl FFR ("For Future Release"), auch bei Standardpaketen fast immer der Fall, prüfen:
[root@popc ~]# sendmail -d0.13 < /dev/null
[...]
FFR Defines: _FFR_TLS_1
[...]
Mit Hilfe von 'ServerSSLOptions' und 'ClientSSLOptionen' können unsichere Protokolle abgeschaltet werden ('+SSL_OP_NO_SSLv2', '+SSL_OP_NO_SSLv3'). Wer etwas mehr Kontrolle über die verwendeten Cipher erlangen möchte, kann zusätzlich '+SSL_OP_CIPHER_SERVER_PREFERENCE' setzen. Damit kann man zwar bestimmte Cipher nicht erzwingen, gibt aber für "normale" Verbindungen die bevorzugten Cipher auf der eigenen Server-Seite vor. Die überhaupt verfügbaren Cipher werden über die 'CipherList' gemäß OpenSSL cipherlist eingestellt.
Die Optionen stehen in der sendmail.mc unter 'LOCAL_CONFIG':
LOCAL_CONFIG
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
O CipherList=HIGH:MEDIUM:!aNULL:!eNULL@STRENGTH
Update: Konfiguration in sendmail.mc ab Sendmail 8.15.1:
define(`confSERVER_SSL_OPTIONS', `+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE')dnl
define(`confCLIENT_SSL_OPTIONS', `+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3')dnl
define(`confCIPHER_LIST', `HIGH:MEDIUM:!aNULL:!eNULL@STRENGTH')dnl
Welche OpenSSL-Optionen eine Sendmail-Version unterstützt, ist im entsprechenden Source Code "dokumentiert".