Knowledgebase: Perfect Forward Secrecy (PFS)

Seit den Enthüllungen Edward Snowdens steigt die Anzahl derer, die ihre Nachrichten verschlüsseln. Positiv, wie wir finden, mit einem Aber: Bei herkömmlichen Verbindungen über SSL-Zertifikate/TLS sind Man-in-the-middle-Angriffe wahrscheinlich. Ihre Kommunikation kann also belauscht und manipuliert werden. So gab es schon Fälle, in denen verschlüsselte Verbindungen dadurch verhindert wurden, dass Angreifer aus „TLS“ „T1S“ gemacht haben – darauf folgt ein Fallback auf unverschlüsselte Verbindungen, es sei denn, der Client schließt solche Verbindungen aus. Dann aber wird die Verbindung gänzlich abgebrochen.

Eine Lösung, um Man-in-the-middle-Attacken genauso auszuschließen wie das nachträgliche Entschlüsseln von Kommunikationen, nennt sich Perfect Forward Secrecy (PFS). Wir veröffentlichten kürzlich bereits einen Artikel, wie Sie PFS konfigurieren. Heute erhalten Sie wichtige Infos dazu übersichtlich zusammengestellt:

Perfect Forward Secrecy: Wo liegen die Unterschiede zu herkömmlichen verschlüsselten Verbindungen?

Perfect Forward Secrecy bietet Ihnen zwei wesentliche Vorteile: Ein kompromittierter Schlüssel wirkt sich nicht auf andere Sitzungen auf dem Server aus. PFS nutzt einen Session Key, durch den das nachträgliche Entschlüsseln Ihrer Kommunikation nicht mehr möglich ist. Schauen wir uns das genauer an:

Bei einer herkömmlich verschlüsselten Verbindung ohne PFS sendet der Client ein „Hello“ an den Server. Der Server weist sich durch das Zertifikat aus und der Client schlägt einen Sitzungsschlüssel vor. Er versendet den Schlüssel verschlüsselt an den Server, dieser wiederum dechiffriert diesen Schlüssel mithilfe des geheimen Schlüssels und bestätigt ihn. Anschließend erfolgt der verschlüsselte Datenaustausch. Ohne den geheimen Schlüssel (Private Key) lässt sich die Kommunikation nicht dekodieren. Wenn es aber jemanden gelingt, an den geheimen Schlüssel zu gelangen, kann nicht nur eine Kommunikation dechiffriert werden, sondern alle, die mit dem Server ausgetauscht wurden. Dieses Entschlüsseln von Nachrichten mithilfe des Private Keys ist nicht nur Geheimdiensten vorbehalten, sondern gelingt jedem, der ein bisschen Ahnung und den geheimen Schlüssel mitbringt.

Unter Verwendung von PFS tauschen Client und Server wieder ein „Hello“ aus. Der Schlüsselaustausch funktioniert via Diffie Hellman, also mithilfe elliptischer Kurven, und – das ist das Wesentliche: Der Schlüssel wird niemals, zu keinem Zeitpunkt über die Leitung übertragen. Client und Server einigen sich also auf einen Schlüssel, der nie durch die Leitung kommt. Es handelt sich um einen Sitzungsschlüssel (Session Key), der nach der Kommunikation vernichtet wird. Das bedeutet: Selbst wenn der geheime Schlüssel in die Hände von Geheimdiensten kommt, kann weder die bestimmte Kommunikation noch eine andere, die mit dem Server stattfand, entschlüsselt werden.

Wo liegen die Vor- und Nachteile von PFS?

Kryptographie-Experten haben die dahinterstehende Mathemetik ausreichend begutachtet und für sicher befunden. Hinzu kommt der Vorteil von verhältnismäßig kurzen Schlüssellängen, sodass Performanceeinbußen bei Verwendung von DHE nicht passieren. Um ein Sicherheitsniveau von 256 Bit zu erreichen, bräuchte RSA eine Schlüssellänge von 15.360 Bit, während DHE mit 512 Bit zurechtkommt. Man erreicht also das doppelte Sicherheitsniveau dadurch, dass DHE die doppelte Schlüssellänge verwendet.

Nachteilig zu erwähnen ist die Tatsache, dass elliptische Kurven auf eine hohe Zufallsrate setzen. Das kann bei Servern mit knappen Ressourcen zum Problem werden. Nicht zu verachten ist weiter die Tatsache, dass elliptische Kurven nach Standards von NIST/ NSA angetrieben wurden. Kritiker weisen auf diverse undurchsichtige Parameter hin, bei denen nicht ganz klar ist, warum es sie gibt: Um das Verfahren zu stärken oder das Abhören zu vereinfachen? Alternativen zu NIST-Kurven sind leider nicht standardisiert, sodass es abzuwägen gilt. Kryptologen auf der ganzen Welt, also sowohl in Europa als auch in den USA und anderswo, sind sich allerdings dahingehend einig, dass das Prinzip gut und wirksam ist.

Wie teste ich meinen Server?

Nutzen Sie SSLLabs zum Testen Ihres Servers. Geben Sie Ihre Domain ein, um sich anzuschauen, wie Ihr Server abschneidet. Um Ihren Server zu testen, kommen Sie an OpenSSL nicht vorbei. Nutzen Sie dafür das Kommando s_client -host www.ihredomain.com -port 443. Sie erhalten als Ausgabe Cipher-Suiten, die Sie allerdings selbstständig interpretieren müssen. Als Beispiel: DHE-RSA-AES256-SHA bedeutet, dass der Schlüsselaustausch via DHE vonstattengeht, die Authentifizierung via RSA, die Verschlüsselung via AES mit 256 Bit, die Integrationsprüfung via SHA.

Sie können mit OpenSSL auch bestimmte Sachen abfragen, beispielsweise können Sie nur eine bestimmte TLS-Version erlauben. Ihre Cipher-Suiten können Sie auf DH einschränken. Beachten Sie aber der Fallback bei älteren Browsern, ansonsten kann keine verschlüsselte Verbindung aufgebaut werden.

Ein Problem mit OpenSSL können Sie mit Ubuntu bekommen: Die Entwickler haben TLS 1.2 deaktiviert. Verwenden Sie als Alternative Debian oder RedHat.

Ihre IPv6-Server testen Sie idealerweise mittels GnuTLS – einer Gnu-Implementierung, die dasselbe kann wie OpenSSL.

Beachten Sie bitte generell, dass Ihre Tests immer nur auf den v on Ihnen verwendeten Client ausgelegt sind. Testen Sie auch mit anderen Clients, die Sie üblicherweise nicht verwenden. Daneben ist es sinnvoll, Verbindungen auf dem Server zu protokollieren, damit Sie sich einen Überblick darüber verschaffen können, welche Features eingesetzt wurden. Wenn beispielsweise selten bis gar nicht mit RC4 gearbeitet wird, können Sie auch darauf verzichten.

Zu welchen Problemen kann es kommen?

OpenSSL in der Version 1.0.1. versteht zwar TLS 1.2, allerdings können einzelne Server auf Debian Stable problematisch werden. So ist Apache 2.2 etwa fühig, TLS 1.2 zu verstehen, aber kein ECDH. Mit dem Internet Explorer funktioniert PFS nicht. Sie können aber zu Apache 2.4 wechseln und haben das IE-Problem ausgeräumt. Exim 4.8 versteht ebenfalls TLS 1.2, aber auch kein ECDH. Dovecot 2.1 kann zwar DH, aber kein ECDH. Dieses Problem lösen Sie, indem Sie auf die Version 2.2 umsteigen. Dieselben Probleme finden Sie auch in RedHat. BetterCrypto.org bietet Ihnen in diesem PDF Konfigurationen, die Sie via Copy&Paste einfach anwenden können. Passen Sie diese gegebenenfalls an, denn RC4 ignoriert das Dokument aufgrund der fehlenden Sicherheit. Wenn Sie RC4 auch ignorieren, schließen Sie Windows XP aus. Daneben schließt dieses Dokument SSL in der Version 3 aus („-sslv3“), was gleichbedeutend damit ist, dass Sie den IE6 ausschließen.

PFS-Konfiguration auf Windows-Servern

Auf Windows-Servern ist Schannel für die Verschlüsselung zuständig. Für die Einrichtung via Group Policies finden Sie auf msdn.microsoft.com eine Anleitung, fürs Einrichten via Registry Keys in Microsofts Support-Seiten. Nun sind diese nicht unbedingt anwenderfreundlich formuliert. Einfacher machen Sie es sich mit dem Tool IIS Crypto, das Sie kostenfrei herunterladen können. Erstellen Sie darin die Konfiguration und spielen Sie diese auf dem Server ein. Das Tool stammt von einer kanadischen Firma, die den Quelltext leider noch nicht offengelegt hat. Wenn Sie sich dabei sicherer fühlen, arbeiten Sie zunächst auf einem Testserver und übertragen Sie dann erst Ihre Konfiguration nach dem Testen auf Ihren Server.

Wo finde ich weiterführende Informationen?

In unserem Blogbeitrag „Perfect Forward Secrecy konfigurieren“ sind wir sehr ausführlich geworden. Auch BetterCrypto.org bietet zahlreiche Informationen und das OpenSSL Cookbook wird Ihnen ebenfalls eine große Hilfe sein.