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


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