tuxad blog

More than one week ago the world was shocked by the SSLv3 protocol vulnerability named "POODLE". Red Hat doesn't provide an updated postfix package for RHEL 5 but offers a "resolution" by showing how to disable SSLv3 on postfix. Actually the solution is nonsense. RH says that you must enable this configuration:

smtpd_tls_mandatory_protocols = TLSv1
smtp_tls_mandatory_protocols = TLSv1
smtpd_enforce_tls = yes
smtp_enforce_tls = yes

RH just adds a small note that "your servers may fail to receive data from certain delivery agents" - a nice understatement. Actually it breaks RFC 2487:

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.

If you run a public mailserver then you CAN'T use mandatory TLS because mailserver without TLS can't deliver to you. You SHOULD use opportunistic TLS. "Opportunistic" means that if a TLS connection to your mailserver fails then a fallback to plain SMTP will happen.

Postfix 2.3 only knows the _mandatory_ options which will only disable SSLv3 in mandatory TLS mode. To switch off SSLv3 you need i.e. a patch for the postfix package.

You can easily prove that Red Hat's config doesn't disable SSLv3 in opportunistic TLS mode:

$ openssl s_client -starttls smtp \
  -connect 127.0.0.1:25 -ssl3 </dev/null
...
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 3072 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
...

To disable SSLv2 and SSLv3 you need a small patch which you can easily apply to the SRPM package. After building and installling the package you won't get SSLv3 connections to your server anymore:

$ openssl s_client -starttls smtp \
  -connect 127.0.0.1:25 -ssl3 </dev/null
CONNECTED(00000003)
5319:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
handshake failure:s3_pkt.c:536:

Update 2015-08-09: The package is included in the tuxad repo.

Red Hat's poodle check script is FAULTY. It uses internally a script which isn't available on RHEL 5 (and other platforms). The script also doesn't distinguish between "SSLv3 disabled" and other errors. This is an enhanced version of Red Hat's script:

#!/bin/bash
ret=$(
 openssl s_client -connect "${1-`hostname`}:${2-443}" -ssl3\
 2>/dev/null </dev/null
)
if echo "${ret}" | grep -q 'CONNECTED'; then
  if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
    if echo "${ret}" | grep -q 'Cipher.*0000'; then
      echo "SSL 3.0 disabled"
    else
      echo "SSL 3.0 enabled"
    fi
  else
    echo "SSL 3.0 disabled"
  fi
else
  echo "unknown error"
fi

Dovecot on RHEL / Centos 5 has version 1.0.7. In this version it's not possible to use '%k' as a Dovecot variable for login_log_format_elements because that feature is only available since Dovecot 1.1.3.

If you want a special cipher suite for i.e. Forward Secrecy then you can't see it in the logs by appending '%k' to login_log_format_elements. You can use a small test script to check for supported ciphers but you can't "see" which ciphers other real world imap clients use on your Dovecot server.

To enable cipher logging in RHEL 5 Dovecot you must recompile / rebuild it. I made a backport of the commit 0177096cefe5 from Dovecot 1.1.3 to Dovecot 1.0.7. My patch does only minimum mods to the package source. You can also use my Source RPM package with the builtin patch to quickly rebuild Dovecot for yourself.

Update 2015-08-09: The package is included in the tuxad repo.

Dieser Blog-Eintrag beschreibt die Konfiguration von Postfix, um PFS zu nutzen. PFS steht für "Perfect Forward Secrecy", was nachträgliches Entschlüsseln von (aufgezeichneten) Verbindungen erschwert. Im deutschsprachigen Raum wird meist dieser Begriff verwendet, während im englischsprachigen Raum häufig nur FS / Forward Secrecy als Bezeichnung dafür verwendet wird.

Seit Beginn des NSA-Skandals 2013 ist das Interesse an Verschlüsselung stark gewachsen. So gibt es seitdem auch viele Anleitungen und Tipps. Dieser Blogpost gehört zu einer kleinen Serie von Posts zu dem Thema. Ein Anlass dazu waren unter anderem viele unkorrekte Aussagen rund um FS und die Konfiguration diverser Software dafür. Um es hoffentlich besser zu machen, werde ich anhand von konkreten Beispielen meine Konfigurationsvorschläge prüfen und auch Belege und Referenzen zu einigen Aussagen liefern. Als Testumgebungen dienen zwei Server mit RHEL / Centos 5 und 6 (postfix-2.3.3/openssl-0.9.8e bzw. postfix-2.6.6/openssl-1.0.1e). Weiterhin setzt dieser Artikel Grundlagen der Systemadministration voraus. Es ist auch keine Anleitung / Konfiguration, die per Copy & Paste übernommen werden kann. Anleitungen aus dem Netz sollte man generell nicht unter Ausschaltung der grauen Zellen übernehmen. ;-)

Der Server mit RHEL 6 dient als SMTP-Server und -Client und der RHEL-5-Server nur als Client zum Testen. Auch Postfix auf RHEL 5 kann für Forward Secrecy konfiguriert werden. Hier dient der Server aber jedoch als "veralteter" Client mit OpenSSL 0.98, um speziell die Abwärtskompatibilität zu prüfen. Der Server ist zu Beginn vorbereitend konfiguriert. Neben einer Standardkonfiguration sind bereits Zertifikate erstellt und eingebunden (für smtp und smtpd).

Zum Testen der Verbindung kann man ein kleines Testscript nutzen, das TLS-Verbindungen anhand einer Liste von Ciphers prüft. Dazu müssen wir erst einmal wissen, was bei Postfix der Default für die Liste von Ciphers ist:

[postfix-2.3.3]$ grep -rh DEF.*D_CIPH src/global/*params.h
#define DEF_SMTPD_TLS_MAND_CIPH "medium"
#define DEF_SMTP_TLS_MAND_CIPH  "medium"
#define DEF_LMTP_TLS_MAND_CIPH  "medium"

[postfix-2.3.3]$ grep -r DEF.*CLIS src/global/*params.h \
  |cut -d" " -f2-
DEF_TLS_HIGH_CLIST      "!EXPORT:!LOW:!MEDIUM:ALL:+RC4:...
DEF_TLS_MEDIUM_CLIST    "!EXPORT:!LOW:ALL:+RC4:@STRENGTH"
DEF_TLS_LOW_CLIST       "!EXPORT:ALL:+RC4:@STRENGTH"
DEF_TLS_EXPORT_CLIST    "ALL:+RC4:@STRENGTH"
DEF_TLS_NULL_CLIST      "!aNULL:eNULL+kRSA"

"medium" ist also für smtp und smtpd der Default und es bedeutet "!EXPORT:!LOW:ALL:+RC4:@STRENGTH" als String zur Erzeugung der Cipher List mit OpenSSL. Bei RHEL 6 / postfix 2.6 finden wir ähnliche Defaults (auf dem laufenden System kurz und schmutzig geprüft):

# strings /usr/sbin/postconf|grep EXPORT
ALL:!EXPORT:+RC4:@STRENGTH
ALL:!EXPORT:!LOW:+RC4:@STRENGTH
ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH

Als erstes "erlauben" wir auf dem Server TLS durch Setzen von smtpd_tls_security_level und smtp_tls_security_level auf "may". Mit der CipherSuite rufen wir dann ssltest.sh auf dem Client auf und erhalten:

$ SSLCipherSuite=$(
> openssl ciphers '!EXPORT:!LOW:ALL:+RC4:@STRENGTH'|tr ":" " "
> ) ./ssltest.sh 127.0.0.1 8025 smtp
ADH-AES256-SHA: YES
DHE-RSA-AES256-SHA: YES
DHE-DSS-AES256-SHA: NO (ssl handshake failure)
AES256-SHA: YES
KRB5-DES-CBC3-MD5: NO (no ciphers available)
KRB5-DES-CBC3-SHA: NO (no ciphers available)
ADH-DES-CBC3-SHA: YES
EDH-RSA-DES-CBC3-SHA: YES
EDH-DSS-DES-CBC3-SHA: NO (ssl handshake failure)
DES-CBC3-SHA: YES
DES-CBC3-MD5: NO (ssl handshake failure)
ADH-AES128-SHA: YES
DHE-RSA-AES128-SHA: YES
DHE-DSS-AES128-SHA: NO (ssl handshake failure)
AES128-SHA: YES
RC2-CBC-MD5: NO (ssl handshake failure)
KRB5-RC4-MD5: NO (no ciphers available)
KRB5-RC4-SHA: NO (no ciphers available)
ADH-RC4-MD5: YES
RC4-SHA: YES
RC4-MD5: YES
RC4-MD5: YES

(Auf Port 8025 ist ein Tunnelendpunkt zu Port 25 des RHEL-6-Servers.)

Damit stellen wir folgende Punkte fest:

1. Verschlüsselung ist möglich (siehe oben, "may")
2. Client und Server handeln ADH-AES256-SHA aus
3. diese Cipher bietet kein FS
4. bereits die zweite Cipher bietet FS
5. unsichere Verschlüsselung bieten beide an (RC4-MD5)

Laut Wietse Venema bzw. postfix.org unterstützt Postfix schon out-of-the-box Forward Secrecy:

The Postfix >= 2.2 SMTP server supports forward secrecy in its default configuration. If the remote SMTP client prefers cipher suites with forward secrecy, then the traffic between the server and client will resist decryption even if the server's long-term authentication keys are later compromised.

Anleitungen und Tipps, die etwas anderes behaupten, sind daher mit Vorsicht zu genießen. Jetzt schauen wir mal kurz, welche Cipher der Server mit sich selbst aushandeln würde:

# SSLCipherSuite=$(
> openssl ciphers '!EXPORT:!LOW:ALL:+RC4:@STRENGTH'|tr ":" " "
> ) ./ssltest.sh 127.0.0.1 25 smtp
ECDHE-RSA-AES256-GCM-SHA384: NO (ssl handshake failure)
ECDHE-ECDSA-AES256-GCM-SHA384: NO (ssl handshake failure)
ECDHE-RSA-AES256-SHA384: NO (ssl handshake failure)
ECDHE-ECDSA-AES256-SHA384: NO (ssl handshake failure)
ECDHE-RSA-AES256-SHA: NO (ssl handshake failure)
ECDHE-ECDSA-AES256-SHA: NO (ssl handshake failure)
DHE-DSS-AES256-GCM-SHA384: NO (ssl handshake failure)
DHE-RSA-AES256-GCM-SHA384: YES
DHE-RSA-AES256-SHA256: YES
DHE-DSS-AES256-SHA256: NO (ssl handshake failure)
DHE-RSA-AES256-SHA: YES
...
RC4-SHA: YES
RC4-MD5: YES
RC4-MD5: YES
PSK-RC4-SHA: NO (no ciphers available)
KRB5-RC4-SHA: NO (no ciphers available)
KRB5-RC4-MD5: NO (no ciphers available)

Hier einigt sich der Server "mit sich selbst" auf DHE-RSA-AES256-GCM-SHA384 und somit auf eine "ephemeral" Cipher mit Forward Secrecy. Aber wir haben ja einen Client mit RHEL 5. Für den nächsten Test setzen wir smtpd_tls_eecdh_grade auf "strong", so wie es teilweise vorgeschlagen wird. Damit erhalten wir...

ADH-AES256-SHA: YES
DHE-RSA-AES256-SHA: YES
DHE-DSS-AES256-SHA: NO (ssl handshake failure)
AES256-SHA: YES
KRB5-DES-CBC3-MD5: NO (no ciphers available)
KRB5-DES-CBC3-SHA: NO (no ciphers available)
ADH-DES-CBC3-SHA: YES
EDH-RSA-DES-CBC3-SHA: YES
EDH-DSS-DES-CBC3-SHA: NO (ssl handshake failure)
DES-CBC3-SHA: YES
DES-CBC3-MD5: NO (ssl handshake failure)
ADH-AES128-SHA: YES
DHE-RSA-AES128-SHA: YES
DHE-DSS-AES128-SHA: NO (ssl handshake failure)
AES128-SHA: YES
RC2-CBC-MD5: NO (ssl handshake failure)
KRB5-RC4-MD5: NO (no ciphers available)
KRB5-RC4-SHA: NO (no ciphers available)
ADH-RC4-MD5: YES
RC4-SHA: YES
RC4-MD5: YES
RC4-MD5: YES

... genau das gleiche Ergebnis wie vorher. Allein damit haben wir noch nichts erreicht.

Ideal wäre eigentlich eine Vorgabe der Cipher List. Dafür gibt es den Parameter smtpd_tls_ciphers. Bei diesem gibt es nur einen kleinen Haken: Es gibt ihn erst ab Postfix 2.6. Das haben wir zwar auf dem Server, aber eine kompatible Konfiguration für sowohl RHEL 6 als auch 5 wäre natürlich ideal. Bei Postfix 2.3, wo das noch nicht konfigurierbar ist, wird intern "export" genutzt. Indem wir den Trick verwenden, eben diese Export-List zu konfigurieren (statt "medium", "high" etc.), würde das auch unverändert auf älteren Postfix-Releases laufen.

Deshalb setzen wir smtp_tls_mandatory_ciphers, smtpd_tls_mandatory_ciphers, smtp_tls_ciphers und smtpd_tls_ciphers auf "export" und zu "export" passend die Option tls_export_cipherlist. Als Wert für tls_export_cipherlist nehmen wir den unter OpenSSL cipher suite for forward secrecy beschriebenen String. Das Ergebnis kann sich sehen lassen:

ADH-AES256-SHA: NO (ssl handshake failure)
DHE-RSA-AES256-SHA: YES
DHE-DSS-AES256-SHA: NO (ssl handshake failure)
AES256-SHA: NO (ssl handshake failure)
KRB5-DES-CBC3-MD5: NO (no ciphers available)
KRB5-DES-CBC3-SHA: NO (no ciphers available)
ADH-DES-CBC3-SHA: NO (ssl handshake failure)
EDH-RSA-DES-CBC3-SHA: NO (ssl handshake failure)
EDH-DSS-DES-CBC3-SHA: NO (ssl handshake failure)
DES-CBC3-SHA: NO (ssl handshake failure)
DES-CBC3-MD5: NO (ssl handshake failure)
ADH-AES128-SHA: NO (ssl handshake failure)
DHE-RSA-AES128-SHA: YES
DHE-DSS-AES128-SHA: NO (ssl handshake failure)
AES128-SHA: NO (ssl handshake failure)
RC2-CBC-MD5: NO (ssl handshake failure)
KRB5-RC4-MD5: NO (no ciphers available)
KRB5-RC4-SHA: NO (no ciphers available)
ADH-RC4-MD5: NO (ssl handshake failure)
RC4-SHA: NO (ssl handshake failure)
RC4-MD5: NO (ssl handshake failure)
RC4-MD5: NO (ssl handshake failure)

Der Client mit RHEL 5 kann eine TLS-Verbindung mit dem Server nur mittels zweier Ciphers herstellen. Beide bieten FS. Und geeinigt haben sich beide auf "DHE-RSA-AES256-SHA". Wir schauen nochmal kurz, wie sich der Server mit sich selbst "unterhält", weiterhin mit dem Postfix-Default "medium" als Client:

# SSLCipherSuite=$(
> openssl ciphers '!EXPORT:!LOW:ALL:+RC4:@STRENGTH'|tr ":" " "
> ) ./ssltest.sh 127.0.0.1 25 smtp
ECDHE-RSA-AES256-GCM-SHA384: YES
ECDHE-ECDSA-AES256-GCM-SHA384: NO (ssl handshake failure)
ECDHE-RSA-AES256-SHA384: YES
ECDHE-ECDSA-AES256-SHA384: NO (ssl handshake failure)
ECDHE-RSA-AES256-SHA: YES
ECDHE-ECDSA-AES256-SHA: NO (ssl handshake failure)
DHE-DSS-AES256-GCM-SHA384: NO (ssl handshake failure)
DHE-RSA-AES256-GCM-SHA384: YES
DHE-RSA-AES256-SHA256: YES
DHE-DSS-AES256-SHA256: NO (ssl handshake failure)
DHE-RSA-AES256-SHA: YES
DHE-DSS-AES256-SHA: NO (ssl handshake failure)
DHE-RSA-CAMELLIA256-SHA: YES
DHE-DSS-CAMELLIA256-SHA: NO (ssl handshake failure)
AECDH-AES256-SHA: NO (ssl handshake failure)
ADH-AES256-GCM-SHA384: NO (ssl handshake failure)
ADH-AES256-SHA256: NO (ssl handshake failure)
ADH-AES256-SHA: NO (ssl handshake failure)
ADH-CAMELLIA256-SHA: NO (ssl handshake failure)
ECDH-RSA-AES256-GCM-SHA384: NO (ssl handshake failure)
ECDH-ECDSA-AES256-GCM-SHA384: NO (ssl handshake failure)
ECDH-RSA-AES256-SHA384: NO (ssl handshake failure)
ECDH-ECDSA-AES256-SHA384: NO (ssl handshake failure)
ECDH-RSA-AES256-SHA: NO (ssl handshake failure)
ECDH-ECDSA-AES256-SHA: NO (ssl handshake failure)
AES256-GCM-SHA384: NO (ssl handshake failure)
AES256-SHA256: NO (ssl handshake failure)
AES256-SHA: NO (ssl handshake failure)
CAMELLIA256-SHA: NO (ssl handshake failure)
PSK-AES256-CBC-SHA: NO (no ciphers available)
ECDHE-RSA-DES-CBC3-SHA: NO (ssl handshake failure)
ECDHE-ECDSA-DES-CBC3-SHA: NO (ssl handshake failure)
EDH-RSA-DES-CBC3-SHA: NO (ssl handshake failure)
EDH-DSS-DES-CBC3-SHA: NO (ssl handshake failure)
AECDH-DES-CBC3-SHA: NO (ssl handshake failure)
ADH-DES-CBC3-SHA: NO (ssl handshake failure)
ECDH-RSA-DES-CBC3-SHA: NO (ssl handshake failure)
ECDH-ECDSA-DES-CBC3-SHA: NO (ssl handshake failure)
DES-CBC3-SHA: NO (ssl handshake failure)
DES-CBC3-MD5: NO (ssl handshake failure)
PSK-3DES-EDE-CBC-SHA: NO (no ciphers available)
KRB5-DES-CBC3-SHA: NO (no ciphers available)
KRB5-DES-CBC3-MD5: NO (no ciphers available)
ECDHE-RSA-AES128-GCM-SHA256: YES
ECDHE-ECDSA-AES128-GCM-SHA256: NO (ssl handshake failure)
ECDHE-RSA-AES128-SHA256: YES
ECDHE-ECDSA-AES128-SHA256: NO (ssl handshake failure)
ECDHE-RSA-AES128-SHA: YES
ECDHE-ECDSA-AES128-SHA: NO (ssl handshake failure)
DHE-DSS-AES128-GCM-SHA256: NO (ssl handshake failure)
DHE-RSA-AES128-GCM-SHA256: YES
DHE-RSA-AES128-SHA256: YES
DHE-DSS-AES128-SHA256: NO (ssl handshake failure)
DHE-RSA-AES128-SHA: YES
DHE-DSS-AES128-SHA: NO (ssl handshake failure)
DHE-RSA-SEED-SHA: YES
DHE-DSS-SEED-SHA: NO (ssl handshake failure)
DHE-RSA-CAMELLIA128-SHA: YES
DHE-DSS-CAMELLIA128-SHA: NO (ssl handshake failure)
AECDH-AES128-SHA: NO (ssl handshake failure)
ADH-AES128-GCM-SHA256: NO (ssl handshake failure)
ADH-AES128-SHA256: NO (ssl handshake failure)
ADH-AES128-SHA: NO (ssl handshake failure)
ADH-SEED-SHA: NO (ssl handshake failure)
ADH-CAMELLIA128-SHA: NO (ssl handshake failure)
ECDH-RSA-AES128-GCM-SHA256: NO (ssl handshake failure)
ECDH-ECDSA-AES128-GCM-SHA256: NO (ssl handshake failure)
ECDH-RSA-AES128-SHA256: NO (ssl handshake failure)
ECDH-ECDSA-AES128-SHA256: NO (ssl handshake failure)
ECDH-RSA-AES128-SHA: NO (ssl handshake failure)
ECDH-ECDSA-AES128-SHA: NO (ssl handshake failure)
AES128-GCM-SHA256: NO (ssl handshake failure)
AES128-SHA256: NO (ssl handshake failure)
AES128-SHA: NO (ssl handshake failure)
SEED-SHA: NO (ssl handshake failure)
CAMELLIA128-SHA: NO (ssl handshake failure)
IDEA-CBC-SHA: NO (ssl handshake failure)
IDEA-CBC-MD5: NO (ssl handshake failure)
RC2-CBC-MD5: NO (ssl handshake failure)
PSK-AES128-CBC-SHA: NO (no ciphers available)
KRB5-IDEA-CBC-SHA: NO (no ciphers available)
KRB5-IDEA-CBC-MD5: NO (no ciphers available)
ECDHE-RSA-RC4-SHA: NO (ssl handshake failure)
ECDHE-ECDSA-RC4-SHA: NO (ssl handshake failure)
AECDH-RC4-SHA: NO (ssl handshake failure)
ADH-RC4-MD5: NO (ssl handshake failure)
ECDH-RSA-RC4-SHA: NO (ssl handshake failure)
ECDH-ECDSA-RC4-SHA: NO (ssl handshake failure)
RC4-SHA: NO (ssl handshake failure)
RC4-MD5: NO (ssl handshake failure)
RC4-MD5: NO (ssl handshake failure)
PSK-RC4-SHA: NO (no ciphers available)
KRB5-RC4-SHA: NO (no ciphers available)
KRB5-RC4-MD5: NO (no ciphers available)

Hier wird sich auf ECDHE-RSA-AES256-GCM-SHA384 geeinigt und die restlichen möglichen Ciphers bieten auch alle FS.

Jetzt bleiben noch diese geheimnisvollen "dh"-Dateien, die man laut diverser Anleitungen erzeugen muss, um Forward Secrecy zu erhalten. Auf postfix.org steht hierzu:

Postfix >= 2.2 support 1024-bit-prime EDH out of the box, with no additional configuration, but you may want to override the default prime to be 2048 bits long, and you may want to regenerate your primes periodically.

Es ist also nicht notwendig, diese zu erzeugen. Auf dieser Seite steht auch, wie man das konfiguriert. Für die erwähnte periodische Neuerzeugung der DH-Parameter kann man ja einen wöchentlichen Cronjob nutzen und somit die Sicherheit erhöhen. Diese Dateien werden fälschlicherweise oft "Schlüssel" genannt. Es sind aber keine Schlüssel sondern Parameter für das DH-Verfahren (man könnte sie sich eher wie einen "Pool" mit Zahlen vorstellen). Wenn man sie ändert, wird im Gegensatz zu einer "Schlüsseländerung" weiterhin Verschlüsselung möglich sein.

Weitere interessante Konfigurationsoptionen in dem Zusammenhang sind smtpd_tls_loglevel, smtp_tls_loglevel und smtpd_tls_received_header, die für Logging und Infos im Mailheader zu aktivieren sind.

Fazit: Mit Postfix >= 2.2 ist Forward Secrecy möglich. Getestet haben wir mit 2.6 auf dem Server und 2.3 auf dem Client. Mittels eines kleinen Tricks ist es auch mit Postfix 2.2 möglich, genaue Vorgaben für die gewünschten Ciphers zu machen und damit sichere Verschlüsselung mit Forward Secrecy zu erhalten.

Summary: Postfix >= 2.2 provides support for Forward Secrecy out of the box. To enable TLS you must configure your certificate(s) and activate smtpd_tls_security_level and smtp_tls_security_level by setting it to "may". To set a specific cipher list you may use smtpd_tls_ciphers but this is only available since Postfix 2.6. Older releases have a fixed default of "export" for this option. This can be used as a "trick" to use the same config for 2.2 and 2.6: Set smtp_tls_mandatory_ciphers, smtpd_tls_mandatory_ciphers, smtp_tls_ciphers und smtpd_tls_ciphers to "export" and configure your desired cipher list as value of tls_export_cipherlist. For a strong and compatible cipher list with only FS ciphers please take a look at: OpenSSL cipher suite for forward secrecy.

As already written in the blog entry "Script to test supported ssl ciphers" many things have happened since the NSA spying scandal started in 2013. Many articles have been written since then about cryptography and forward secrecy and OpenSSL and securing servers (i.e. web and mail). This is my approach and recommendation for a well balanced OpenSSL cipher suite as of October 2014.

I've made many tests with different OS (RHEL / Centos 5 to 7, MacOS and more) and the online server check of Qualys SSL Labs (thank you for this tool, guys!). This is the list of my criteria (with light explanations):

• use ordered list with custom order following all of these criteria
• use only ephemeral ciphers to provide forward secrecy
• disable weak ciphers and ciphers to be known vulnerable
• prefer ciphers with GCM to prevent some attacks
• prefer AES128 over AES256 due to possible timing attacks and compatibility
• prefer elliptic curve ciphers due to better performance
• don't allow anonymous ciphers like ADH
• remaining and not preferred ciphers should be appended to the list of preferred ciphers

For better readability I broke my list up into lines, here it is:

$ echo '
> ECDHE-ECDSA-AES128-GCM-SHA256
> ECDHE-ECDSA-AES256-GCM-SHA384
> ECDHE-RSA-AES128-GCM-SHA256
> ECDHE-RSA-AES256-GCM-SHA384
> DHE-RSA-AES128-GCM-SHA256
> DHE-RSA-AES256-GCM-SHA384
> ECDHE-ECDSA-AES128-SHA256
> ECDHE-ECDSA-AES256-SHA384
> ECDHE-RSA-AES128-SHA256
> ECDHE-RSA-AES256-SHA384
> DHE-RSA-AES128-SHA256
> DHE-RSA-AES256-SHA256
> ECDHE-ECDSA-AES128-SHA
> ECDHE-RSA-AES128-SHA
> ECDHE-ECDSA-AES256-SHA
> ECDHE-RSA-AES256-SHA
> DHE-RSA-AES128-SHA
> DHE-RSA-AES256-SHA
> ALL
> !aNULL
> !ADH
> !3DES
> !EXP
> !RC4
> !kRSA
> !kKRB5
> !aDSS
> !DES
> !aPSK
> !kECDH
> '|tr \\n ':'|xargs openssl ciphers -v
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH ...
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH ...
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH ...
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH ...
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH ...
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH ...
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH ...
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH ...
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH ...
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH ...
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH ...
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH ...
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH ...
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH ...
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH ...
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH ...
DHE-RSA-AES128-SHA      SSLv3 Kx=DH ...
DHE-RSA-AES256-SHA      SSLv3 Kx=DH ...
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH ...
DHE-RSA-SEED-SHA        SSLv3 Kx=DH ...
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH ...

Due to preferring GCM ciphers and AES128 over AES256 you will get an GCM cipher when using "IE 11 / Win 8.1" as shown by the SSL labs tool: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. With the widely used recommendation of Ristic as explained by Heise et al. you'll get "only" TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 which is vulnerable to the Lucky 13 attack - which is in fact very unlikely to be happen.

This cipher suite can be used on OS using OpenSSL 0.98 (i.e. RHEL / Centos 5) and also on OS with newer versions of OpenSSL (i.e. RHEL / Centos 6 and 7). To include it into your ssl.conf just insert ssl.conf.txt.

Deutsche Zusammenfassung: Die oben gezeigt Cipher Suite entstand nach folgenden Kriterien:

• Liste sortiert nach diesen Kriterien
• nur "ephemeral" Ciphers für PFS (Perfect Forward Secrey)
• keine schwachen / verwundbaren Ciphers
• Ciphers mit GCM (Galois / Counter Mode) bevorzugen
• AES128 gegenüber AES256 wegen möglicher Timing-Angriffe und wegen Kompatibilität bevorzugen
• Ciphers mit elliptischen Kurven (EC) wegen Performance bevorzugen
• keine anonymen Ciphers wie ADH
• restliche und nicht bevorzugte Ciphers werden an das Ende der Liste gehängt

Mit dieser Liste (einfügen in Apache ssl.conf) ist auch im Gegensatz zur Empfehlung von Ristic (siehe Heise) mit "IE 11 / Win 8.1" eine GCM-Cipher möglich.

In the last months there was a lot of work done in the field of encryption due to our spying friends at the NSA. Keywords like "forward secrecy" jumped to the top places in search engines. Then we got the heartbleed bug in OpenSSL. It's harder to keep his stuff up to date. One important task is to actually test (and not just believe) that your protection is sufficient. You can't just update OpenSSL and Bash and more software and think you are well protected. Many software packages out in the wild use SSL/OpenSSL but just do some "basic" configuration to show "It Works!".

One important task is to check the ciphers or the cipher suite actually used by services like http or smtp (i.e. with starttls). You must use the best balance between using secure communiation with forward secrecy and current key exchange, authorization and hash methods, and compatibility to other software (mainly clients) on the other side. If you want a secure communication between i.e. a RHEL/Centos 5 host and a RHEL/Centos 6 host there will be only two ciphers left.

To have a simple and easily configurable tool for checking ssl ciphers between to peers I wrote a very small script:

#!/bin/ash
# shell shock all-clear: compatible to
# ash dash ksh93 lksh mksh pdksh shish zsh

# Frank Bergmann, www.tuxad.com, 2014-10
# Test peer with openssl for supporting ssl ciphers

[ $# -lt 2 ] && {
  echo 'usage: '$0' ip-address port [protocol]'
  echo 'protocol is i.e. smtp for STARTTLS'
  exit 1
}

SERVER=$1
PORT=$2
if [ "$3" ]
then
  STARTTLS=-starttls
  PROT=$3
fi
CIPHER_SUITE="\
`openssl ciphers 'ALL:eNULL' | sed 's,:, ,g'`"

for CIPHER in $CIPHER_SUITE
do
  IFS=""
  echo -n "$CIPHER: "
  OUTPUT="`openssl s_client -cipher $CIPHER $STARTTLS \
$PROT -connect $SERVER:$PORT 2>&1 </dev/null`"
  ACT_CIPHER=`echo $OUTPUT|grep "Cipher is"|sed \
's,.*Cipher is ,,'|tr -d '()'`
  if [ "$ACT_CIPHER" = "$CIPHER" ]
  then
    SUPPORT=YES
  else
    SUPPORT=NO
  fi
  if [ "$SUPPORT" = "NO" ]
  then
    SUPPORT=$SUPPORT" ("`echo $OUTPUT|grep \
:error:|cut -d: -f6`")"
  fi
  echo $SUPPORT
  sleep 1
done

Arguments are IP address and port. The optional third argument for protocol is only needed for starttls. Latest version of this script can be downloaded at ssltest.sh. Here's an example run of a RHEL 5 host connecting to a RHEL 6 host with https and smtp/starttls:

$ ./ssltest.sh 80.153.x.x 443|grep -C2 YES
ADH-AES256-SHA: NO (sslv3 alert handshake failure)
DHE-RSA-AES256-SHA: YES
DHE-DSS-AES256-SHA: NO (sslv3 alert handshake failure)
AES256-SHA: NO (sslv3 alert handshake failure)
ADH-AES128-SHA: NO (sslv3 alert handshake failure)
DHE-RSA-AES128-SHA: YES
DHE-DSS-AES128-SHA: NO (sslv3 alert handshake failure)
AES128-SHA: NO (sslv3 alert handshake failure)
--
ADH-RC4-MD5: NO (sslv3 alert handshake failure)
EXP-ADH-RC4-MD5: NO (sslv3 alert handshake failure)
EDH-RSA-DES-CBC3-SHA: YES
EDH-RSA-DES-CBC-SHA: NO (sslv3 alert handshake failure)
EXP-EDH-RSA-DES-CBC-SHA: NO (sslv3 alert handshake failure)

$ ./ssltest.sh 80.153.x.x 25 smtp|grep -C2 YES
ADH-AES256-SHA: NO (ssl handshake failure)
DHE-RSA-AES256-SHA: YES
DHE-DSS-AES256-SHA: NO (ssl handshake failure)
AES256-SHA: NO (ssl handshake failure)
ADH-AES128-SHA: NO (ssl handshake failure)
DHE-RSA-AES128-SHA: YES
DHE-DSS-AES128-SHA: NO (ssl handshake failure)
AES128-SHA: NO (ssl handshake failure)

This blog entry is the start of some blog entries regarding this topic.

(As noted after the shebang this script is compatible with maybe all bourne shells. RPM packages for shish and heirloom shell may be downloaded at www.tuxad.com/shells.)