- 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
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 3. Juli wurde Sendmail 8.15.2 veröffentlicht.
Der heimliche Star unter den Neuheiten ist das Feature 'tls_session_features', welches für TLS die Möglichkeit eröffnet, Optionen (z. B. das Abschalten best. Protokolle), Cipher Lists und Zertifikate/Keys in Abhängigkeit der Gegenstelle zu setzen.
Für den Einsatz von 'tls_session_features' muss Sendmail mit '_FFR_TLS_SE_OPTS' kompiliert werden:
[root@popc ~]# sendmail -d0.14
Version 8.15.2
[...]
FFR Defines: _FFR_TLS_EC _FFR_TLS_SE_OPTS
Mit der Konfiguration in sendmail.mc:
FEATURE(`tls_session_features')dnl
werden die Rulesets 'tls_srv_features' und 'tls_clt_features' in sendmail.cf aktiviert. Die Konfiguration erfolgt bequem in der Access-DB, z.B. wenn die Kommunikation seit dem letzten OpenSSL-Update aufgrund zu kurzer Diffie-Hellmann-Primzahlen mit einem bestimmten Server mit DHE-Ciphern nicht möglich ist (In vorherigen Versionen gab es, sofern sich der Server für einen DHE-Cipher entschied, nur die Möglichkeit, keine Mails mehr oder, weil es die meisten MTAs zulassen, unverschlüsselt zu versenden.):
TLS_Clt_features:10.2.2.2 Cipherlist=HIGH:MEDIUM:!aNULL:!eNULL:!DH
Ab Loglevel 14 lässt sich der Effekt gut beobachten:
Jul 10 17:41:03 popc sendmail[7302]: STARTTLS=client, init=1
Jul 10 17:41:03 popc sendmail[7302]: STARTTLS=client, start=ok
Jul 10 17:41:03 popc sendmail[7302]: tls_clt_features=Cipherlist=HIGH:MEDIUM:!aNULL:!eNULL:!DH, relay=test.sendmaid.org [10.2.2.2]
Jul 10 17:41:03 popc sendmail[7302]: tls_clt_features=parsed, Cipherlist=HIGH:MEDIUM:!aNULL:!eNULL:!DH, relay=test.sendmaid.org [10.2.2.2]
[...]
Jul 10 17:41:03 popc sendmail[7302]: STARTTLS=client, relay=test.sendmaid.org., version=TLSv1.2, verify=FAIL, cipher=AES256-GCM-SHA384, bits=256/256
Weiterlesen: Sendmail 8.15.2 glänzt mit Session-basierten TLS-Features
- 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