Sendmail 8.15.2 glänzt mit Session-basierten TLS-Features

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


Hier irrt die Fledermaus

In ungewohnt nebulösen Worten fabuliert das beliebte Batbook um das in Sendmail 8.14 neu eingeführte Feature 'badmx' herum. Es werden Windows PCs angeführt, die per DHCP ihre IP-Adresse beziehen und deshalb oder weil sie gekapert wurden keinen MX-Record publizieren. Öh...?

Die Funktionsweise wird so erklärt, dass ein Sendmail Server für den sich verbindenden Client den Hostnamen per Reverse Lookup ermittelt, auf den Domain-Anteil reduziert und daran MX Lookups vornimmt. Das ist natürlich Quatsch für 'badmx'. Die Prüfungen des Features beziehen sich auf die Domain der Absender-Adresse. (Die IP der Gegenstelle benutzt das in Sendmail 8.14 ebenfalls neu eingeführte Feature 'require_rdns'.)

Die Release Notes von Sendmail 8.14.0 bringen es auf den Punkt:

CONFIG: New FEATURE(`badmx') to reject envelope sender addresses 
(MAIL) whose domain part resolves to a "bad" MX record.
Based on contribution from William Dell Wisner

 Der Aufruf des Rulesets 'BadMX' erfolgt am Ende von 'check_mail'. Zunächst ermittelt Sendmail darin die MX-Records für die Domain des Absenders mit Hilfe der Map 'bestmx' und führt den ersten Check auf Basis einer 'regex' Map durch:

1. Zeigt einer der MX-Records nicht auf einen Full Qualified Domainname, sondern auf eine IP-Adresse, ist er "bad" und die Mail wird abgelehnt mit der Meldung:

550 5.1.2 <user@domain>... Illegal MX record for host <domain>

Im zweiten Schritt werden die A-Records zu allen MX-Records ermittelt und mit Hilfe einer weiteren 'regex' Map geprüft:

2. Ist eine der IPs Loopback (beginnt mit 127.), nicht route-fähig (beginnt mit 10.) oder die 0.0.0.0, wird die Mail abgelehnt mit der Meldung:

550 5.1.2 <user@domain>... Invalid MX record for host <domain>

Referenzen:

1. Costales, Jansen, Aßmann with Shapiro. sendmail 4th Edition. a.k.a. "bat book", S. 291-292


OpenSSL schützt Clients vor Logjam

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


Zusammenspiel der Sendmail Connection Timeouts

Seit gefühlt ewigen Zeiten (seit V8) kennt Sendmail einzelne Timeouts für jede erdenkliche Situation des SMTP-Dialogs, drei ('iconnect', 'connect' und 'aconnect') davon alleine für den Verbindungsaufbau als Client zu einem SMTP-Server.

Die Default-Werte der Timeouts können in der laufenden sendmail.cf nachgeschlagen werden:

[root@popc mail]# grep "O Timeout" sendmail.cf
#O Timeout.initial=5m
#O Timeout.connect=5m
#O Timeout.aconnect=0s
#O Timeout.iconnect=5m
#O Timeout.helo=5m
O Timeout.mail=5m
#O Timeout.rcpt=1h
[...]

Alle mit dem Kommentarzeichen "#" versehenen Timeouts sind Defaults, die in Sendmail deutlich großzügiger sind, als die in RFC 5321 (siehe Abschnitt 4.5.3.2) empfohlenen Minimalwerte. Auffällig ist bspw. der Timeout für die Bestätigung jedes einzelnen Empfängers durch die Gegenstelle ('Timeout.rcpt'), auf die Sendmail geduldig eine Stunde wartet. Verständlich also, dass insb. bei Outgoing MTAs an den Timeouts gedreht wird.

Wer die Connection Timeouts heruntersetzen will, muss das spezielle Verhältnis zwischen 'connect' und 'aconnect' beachten!

'Timeout.connect' ist die Zeit, die Sendmail versucht, die Verbindung zu einer Gegenstelle herzustellen, während 'Timeout.aconnect' die Zeit bezeichnet, die Sendmail für den gesamten Zustellversuch zur Verfügung hat, z.B., um mehrere MX Hosts zu probieren, wenn die höher priorisierten nicht erreichbar sind. Ist dieser Timeout abgelaufen, wird der Zustellversuch abgebrochen und der nächste für die Mail erst im folgenden Queuerun wieder unternommen. 'Timeout.initial' verhält sich wie 'Timeout.connect', bezieht sich aber nur auf den allersten Versuch, eine Mail zuzustellen. Für alle weiteren Versuche kommt 'Timeout.connect' zum Einsatz.

Wird nun 'Timeout.aconnect' gleich 'Timeout.connect' gesetzt, kann Sendmail bei jedem Zustellversuch immer nur den ersten MX Server nehmen, so dass betroffene Mails bis zu dessen Wiedererreichbarkeit in der Queue verbleiben. Im Log ist das Phänomen daran zu erkennen, dass nicht der MX Server mit der niedrigsten Priorität in der Fehlermeldung steht, sondern in diesem Fall der mit der höchsten, nämlich der, den Sendmail aufgrund seiner Timeouts gerade noch versuchen durfte.

Weiterlesen: Zusammenspiel der Sendmail Connection Timeouts


Sichere Diffie-Hellman Parameter vor und nach Logjam

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


Sendmail 8.15.1

Die neue Sendmail-Version 8.15.1 bringt, obwohl das erste Major Release seit mehr als 7 Jahren, keine dramatischen Änderungen, erleichtert jedoch mit ihren vielen kleinen Verbesserungen an der einen oder anderen Stelle die Arbeit.

Die komplette Liste der Änderungen ist hier zu finden.

Zu beachten ist die Entscheidung der Entwickler, IPv6-Adressen defaultmäßig nur noch in ihrer unkomprimierten Form zu verarbeiten. IPv6-Nutzer müssen ihre Maps, Klassen oder selbstgeschriebenen Rulesets also eventuell anpassen. Das alte Verhalten kann mittels der Compile Option '-DIPV6_FULL=0' in der 'devtools/Site/site.config.m4' wieder hergestellt werden. Welche Addressform der eigene Sendmail spricht, erkennt man an den 'Compiled with:' Optionen:

[root@popc ~]# sendmail -d0.1 < /dev/null
Version 8.15.1
[...]
Compiled with: DNSMAP IPV6_FULL LOG MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETUNIX NEWDB PIPELINING SASLv2 SCANF
STARTTLS USERDB XDEBUG
[...]

Fehlt hier 'IPV6_FULL', wird die alte, komprimierte Form verwendet. 

Die Compile Option '_FFR_TLS_1' wurde entsorgt, so dass die früher erst duch sie hervorgezauberten SSL-Optionen ('ServerSSLOptions', 'ClientSSLOptions' und 'CipherList') jetzt standardmäßig zur Verfügung stehen und damit auch in mc-Notation (und nicht mehr nur als Optionen unterhalb von 'LOCAL_CONFIG') konfiguriert werden können:

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

 '_FFR_TLS_EC' für die Verwendung der Elliptic Curve Varianten des Diffie-Hellman-Verfahrens muss auch in 8.15.1 beim Kompilieren gesetzt werden.

Schön ist auch, dass 8.15.1 'SSL_get_version' anstatt von 'SSL_CIPHER_get_version' zu Rate zieht, weil es einfach abwechslungsreicher ist, die richtige SSL-Protokoll-Version im Log zu sehen und nicht immer nur 'TLSv1/SSLv3'.

Referenzen:

1. http://compgroups.net/comp.mail.sendmail/sendmail-8.15.1-available/3007787


Perfect Forward Secrecy in Sendmail einrichten

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

Weiterlesen: Perfect Forward Secrecy in Sendmail einrichten


SSLv3 in Sendmail abschalten

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".

Weiterlesen: SSLv3 in Sendmail abschalten


IPJ is back

"The Internet Protocol Journal" ist wieder da, juhu!

Seit seinem Start 1998 bis zu seiner Einstellung letztes Jahr überzeugte das Journal mit detailreichen Artikeln rund um Internet Technologien. Nun wird es unter dem Dach der Internet Society (ISOC) wieder herausgegeben.

Die neue Ausgabe ist lesenswert wie immer. Der erste Artikel gibt einen Überblick über Gigabit Wi-Fi (IEEE 802.11ac und 802.11ad) und die für diese Geschwindigkeiten notwendigen Technologien. Ausgehend vom DNS Amplification Attack als einem der gleichermaßen unangenehmsten wie wirkungsvollsten DDoS-Angriffe, möglich erst durch eine Unzahl sog. Open Resolver (gemäß dem "Open Resolver Project" beantworten >20 Mio Resolver brav die Anfragen fremder Clients), berichtet Geoff Huston im zweiten Artikel von einem Experiment aus dem letzten Jahr, in dem Resolver "gezwungen" wurden, TCP Queries zu verwenden, um größere Antwort-Pakete zu erhalten.

Die alten Ausgaben stehen derzeit noch unter http://www.cisco.com/ipj zum Download bereit.

Referenzen:

1. http://www.internetsociety.org/ipj

2. http://www.internetsociety.org/sites/default/files/ipj17.1_0.pdf 

3. http://openresolverproject.org/