Forward Secrecy testen und einrichten

Bei Forward Secrecy – oft auch als Perfect Forward Secrecy – bezeichnet, geht es darum, zu verhindern, dass ein kompromittierter Schlüssel auch in der Vergangenheit geführte und verschlüsselt aufgezeichnete Kommunikation betrifft. Das Angriffsszenario ist also: "Gestern aufgezeichnet, heute entschlüsselt". Das kann man verhindern, indem man den Schlüsselaustausch zwischen Client und Server nach dem Diffie-Hellman-Verfahren bewerkstelligt. Mehr Details liefert Zukunftssicher verschlüsseln mit Perfect Forward Secrecy.

Bei einem Web-Server kann man diese Eigenschaft über den SSL-Tests der SSL Labs checken, der einen Verbindungsaufbau mit vielen verschiedenen Browsern durchführt und jeweils angibt, ob Forward Secrecy erreicht wurde. Das funktioniert jedoch nur mit Web-Servern (also https auf Port 443); interessant ist Forward Secrecy aber auch und vor allem bei Mail-Servern.

Das Standard-Tool für die Analyse von SSL-Funktionen ist das Kommandozeilenprogramm von OpenSSL. Einen IMAP-Server mit SSL testet man damit via:

openssl s_client -connect imap.1und1.de:993

Kommt als Ergebnis eine Ciphersuite heraus, die mit DH oder ECDH beginnt, haben sich die beiden Kommunikationspartner auf Forward Secrecy geeinigt. Ob ein Server überhaupt Forward Secrecy beherrscht, verrät:

openssl s_client -cipher 'ECDH:DH' -connect login.live.com:443

Dieses Beispiel zeigt, dass auch Microsofts Server durchaus DH-Verfahren im Repertoire haben. Ob ein Server Diffie-Hellman erzwingt, auch wenn der Client RSA bevorzugt, verrät die cipher-Spezifikation 'RSA:ECDH:DH'.

OpenSSL unterstützt auch Verbindungen, bei denen man die Verschlüsselung über den starttls anfordern muss, wie es etwa im Mail-Versandprotokoll SMTP üblich ist:

openssl s_client -starttls smtp -connect smtp.gmx.net:587

Das funktioniert mit den Protokollen "smtp", "pop3", "imap" und "ftp", bei denen man dann jeweils den dafür zuständigen Standard-Port wählt. Alternativ kann man auch das Tool SSLScan nutzen; für Windows gibt es eine Portierung namens sslscan-win. Praktisch ist auch das Perl-Skript CryptoNark, das ebenfalls diverse Infos über die SSL-Fähigkeiten eines Servers ausspuckt; es erfordert allerdings die Installation diverser Perl-Module via CPAN. Das Tool gnutls-cli beherrscht auch IPv6.

Letztlich will man jedoch den Aufbau einer Verbindung mit Forward Secrecy zumindest einmal mit echten Clients testen – schon um zu vermeiden, dass wegen deren Eigenheiten die ganze Mühe umsonst war. Dummerweise ist der Chrome-Browser der einzige echte SSL-Client, der das aktuell verwendete Schlüsselaustauschverfahren anzeigt. Also muss man diese Information entweder den Log-Dateien entnehmen oder den jeweiligen Verbindungsaufbau mitschneiden und analysieren – etwa mit Wireshark. In dessen Analysefenster kann man sich die einzelnen Schritte des SSL-Verbindungsaufbaus en Detail ansehen.

1. Client Hello
2. Server Hello, Certificate, Server Key Exchange, Server Hello Done
3. Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
4. Encrypted Handshake Message, Change Cipher Spec, Encrypted Handshake Message

Im Analysefenster unter "Secure Sockets Layer" kann man die einzelnen Protokollfelder einsehen. Im "Client Hello" erklärt zunächst der Client, was er so alles kann. Daraus wählt dann der Server die im Protokoll des "Server Hello" aufgeführte Cipher Suite aus. Etwas wie Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)signalisiert Forward Secrecy.

Konfigurieren

Die einfachste Option auf einem Apache-Web-Server Forward Secrecy anzubieten, ist, bei der Voreinstellung zu bleiben, und sich an den Wünschen des Clients zu orientieren. Denn bei Browsern wie Firefox und Chrome stehen die Diffie-Hellman-Suiten ganz oben auf der Liste. Es gibt jedoch eine Reihe von Gründen, warum Admins die präferierte Cipher Suite selbst bestimmen wollen (in Apache mit SSLHonorCipherOrder). Die gibt man dann je nach Server anders an:

Apache: SSLCipherSuite
NGinx: ssl_ciphers
Exim: tls_require_ciphers
Postfix: smtpd_tls_ciphers und smtp_tls_ciphers bzw tls_export_cipherlist (vor 2.6)
Dovecot: ssl_cipher_list

Entwickler, die in eigenen Programmen die OpenSSL-Bibliothek nutzen, können deren Präferenzen via SSL_OP_CIPHER_SERVER_PREFERENCE justieren. Darüber hinaus muss man bei manchen Servern noch Diffie-Hellman-Parameter angeben beziehungsweise selbst eine Datei erstellen, in der diese enthalten sind. Dies geschieht dann in der Regel mit dem Befehl openssl dhparam. Details dazu findet man schnell über die oben verlinkte SSL-Dokumentation des Dienstes.

Die zentrale Herausforderung für den Admin ist es, eine passende Liste von sicheren Suiten zusammenzustellen. Wichtig ist, dass in der Liste auch für alle denkbaren Gegenstellen was passendes dabei ist. Es wird dadurch erschwert, dass diese mit einer recht komplexen Syntax anzugeben ist, die sich meist an der von openssl orientiert. Der SSL-Experte Ivan Ristic schlägt folgende vor:

EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM \
 EECDH+ECDSA+SHA256 EECDH+aRSA+RC4 EDH+aRSA EECDH RC4 \
 !aNULL !eNULL !LOW !3DES !MD5 \ !EXP !PSK !SRP !DSS

Wenn man die testweise mit

openssl ciphers -V 'EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA256 EECDH+aRSA+RC4 EDH+aRSA EECDH RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS'

expandiert, sieht man, dass sie mit einer Reihe von ECDH-Suiten aus TLSv1.2 beginnt und als letzten Fallback "RC4-SHA" ohne Forward Secrecy ergibt. RC4 gilt zwar als theoretisch geknackt, wegen der BEAST-Angriffe zieht es Ristic trotzdem AES im anfälligen CBC-Modus vor. Wer sich eine eigene Liste zusammenstellen will, kann die ebenfalls mit openssl ciphers testen.

Probleme bereitet vor allem der Internet Explorer. Wer noch IE8 auf Windows XP einsetzt, hat ohnehin verloren – dieses Paar unterstützt generell keine Forward Secrecy. Für Internet Explorer 10 kann man mit dem unter anderen bei Debian Stable eingesetzten Apache 2.2 keine Forward Secrecy anbieten, da Apache die erforderlichen ECDHE-Suiten erst ab Version 2.4 beherrscht. Wie es um die Forward-Secrecy-Fähigkeiten der üblichen Mail-Clients bestellt ist, haben wir bislang nicht untersucht – da könnte noch die ein oder andere Überraschung lauern.

Wer auf einem Windows-Server mit Microsofts IIS oder Exchange Forward Secrecy einrichten möchte, kann die Reihenfolge der unterstützten Cipher Suites über den Gruppenrichtlinien-Editor konfigurieren. Auch hier gilt es, die Suiten mit ECDHE und DHE so weit wie möglich nach oben zu befördern. Sehr hilfreich ist das Tool IIS Crypto von Nartac Software, mit dem sich viele Einstellungen, wie etwa eine BEAST-resistente Konfiguration, mit einem Mausklick erstellen lassen.

Update 14.10.2014: Die relevanten Postfix-Optionen korrigiert; das zuvor aufgeführte smtpd_tls_mandatory_ciphers betrifft nur die zwingende Verschlüsselung (mandatory TLS), die bei SMTP nicht sinnvoll ist. Danke an Frank Bergmann für den Hinweis. (ju)