Perfect Forward Secrecy schützt Ihren Server vor Lauschangriffen

10.06.2016 | Petra Alm

Hinter dem Begriff Perfect Forward Secrecy verbirgt sich eine Sicherheitsfunktion des SSL/TLS Protokolls. Ihr Ziel besteht darin, der Rück-Entschlüsselung von der Kommunikation mit dem Server vorzubeugen, zum Beispiel im Fall der Bearbeitung von abgehörten Daten. In der folgenden Anleitung erfahren Sie, wie Sie Perfect Forward Secrecy auch auf Ihrem Server ausnutzen können.

Protokolle für den Schlüsselaustausch

Bevor zwischen dem Server und Browser die verschlüsselte Kommunikation eingeleitet wird, müssen sich beide Seiten auf die Verschlüsselung verständigen. Einen Teil dieser Absprache stellt auch die Auswahl von Protokollen dar, die von den beiden Seiten unterstützt werden. Zu diesen Protokollen gehört auch das Protokoll für den Schlüsselaustausch.

Bei der Kommunikation können für den Schlüsselaustausch drei Protokolle verwendet werden – RSA, DHE und ECDHE (elliptische Kurven – Elliptic Curve Diffie-Hellman Exchange). Das erste von den erwähnten Protokollen unterstützt die in diesem Artikel besprochene Funktion Forward Secrecy nicht und auch aus Sicherheitsgründen ist es besser, es zu umgehen. Die übrigen zwei Protokolle sind sicherer und empfehlenswerter.

Wozu dient Perfect Forward Secrecy?

Wie aus dem englischen Namen zu folgen ist, handelt es sich um eine Absicherung „vorwärts“, für den Fall, dass jemand den Inhalt der verschlüsselten Kommunikation erwirbt. Zu einem solchen Szenario könnte es bei einem Lauschangriff kommen, bei dem in der ersten Phase die Daten gesammelt und aufgenommen und nachfolgend von dem Angreifer entschlüsselt und bearbeitet werden.

Die SSL-Sitzungen sind mit einem Paar von vorübergehenden Schlüsseln verschlüsselt. Die verschlüsselte Kommunikation kann zwar gespeichert werden, aber der Angreifer braucht noch die Schlüssel, um ihren Inhalt lesen zu können. Sollte er jedoch den privaten RSA Schlüssel erwerben, kann er mit ihm auch die ursprünglichen Schlüssel der Sitzung aufmachen und dadurch die aufgenommene Kommunikation rückwärts entschlüsseln. Das Eintreffen einer solchen Situation ist nicht unwahrscheinlich, denn die Zertifikatsinhaber ändern ihre privaten Schlüssel nur selten.

Damit ein solches Vorkommnis verhindert werden kann, muss für den Schlüsselaustausch ein anderer Key-exchange Algorithmus als RSA verwendet werden.

Dieses Problem wird für uns der sogenannte Diffie-Hellman Algorithmus lösen. Mit ihm unterscheiden sich die Sitzungsschlüssel von dem privaten Schlüssel und werden außerdem nach Beendigung der Kommunikation gelöscht. Dieser Algorithmus stellt einen von den zwei dar, die bei Forward Secrecy genutzt werden. Im Unterschied zu dem zweiten Algorithmus, dem bereits erwähnten ECDHE, ist er jedoch wesentlich langsamer. Aus Sicht der Leistung ist also der ECDHE eine bessere Wahl, der DH Algorithmus wird außerdem vom Internet Explorer 9 und 10 ungenügend unterstützt - außer in Kombination mit DSA Schlüsseln, die normalerweise nicht verwendet werden.

Wie mit Forward Secrecy anfangen

Die folgenden Zeilen helfen Ihnen mit der Einstellung von Perfect Forward Secrecy auf den populärsten Webservern Apache und IIS.

Apache und OpenSSL

Falls Sie den Webserver Apache (und OpenSSL) verwenden, ist die Einstellung einfach. Sie brauchen jedoch solche Software-Versionen, die die Kryptografie von elliptischen Kurven unterstützen. Genauer gesagt benötigen Sie Apache in der Version 2.4.x und OpenSSL 1.0.1c+.

Apache speichert seine Einstellungen in einer globalen Konfigurationsdatei und die einzelnen Teile der Einstellung werden Direktiven genannt.

Die Direktive für die Einstellung der Verschlüsselungsalgorithmen heißt SSLCipherSuite. In ihr werden Verschlüsselungen eingestellt, die der Server vorrangig verwenden soll. Experten von SSLlabs empfehlen, die folgenden Kombinationen zu verwenden:

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Die Reihenfolge der Verschlüsselungen in der Konfiguration bestimmt ihre Präferenz - je höher eine Verschlüsselung aufgeführt wird, desto mehr wird sie von dem Server bevorzugt. Alle drei SSL-Direktiven sehen dann zum Beispiel folgendermaßen aus:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder off
SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
SSLSessionTickets off

Mehr Informationen über die Einstellung, inklusive der Installierung für Nginx, finden Sie in dem Artikel Configuring Apache, Nginx, and OpenSSL for Forward Secrecy.

IIS (Internet Information Services)

Die Einstellung von Perfect Forward Secrecy auf IIS ist zwar komplizierter, aber der Artikel Setup your IIS for SSL Perfect Forward Secrecy and TLS 1.2 bietet Ihnen z. B. ein PowerShell-Skript,  mit dem Sie Perfect Forward Secrecy unter Verwendung von TLS 1.2. einstellen können. Das Skript können Sie sowohl im IIS 7.5 als auch in der letzten Version 8 nutzen. Eine andere Lösung finden Sie in dem Artikel Perfect Secrecy in an imperfect world, in dem mit dem Tool IIS Crypto gearbeitet wird.

Falls Sie die Installierung traditionell durchführen möchten, also manuell, hilft Ihnen dabei das Programm gpedit.msc (Local Group Policy Editor). Im Menü gehen Sie folgendermaßen vor: Computer Configuration > Administrative Templates > Network > SSL Configuration Settings. Danach klicken Sie SSL Cipher Suite Order an und passen die Reihenfolge von Verschlüsselungen an (ECDHE empfehlen wir Ihnen an erster Stelle aufzuführen).

Editor für lokale Gruppenrichtlinien

Editor für lokale Gruppenrichtlinien

Test der Servereinstellung

Ihre neue Einstellung, Aktivierung von Forward Secrecy und das gesamte Niveau der Absicherung können Sie im SSL Server Test von Qualys überprüfen. Falls auf dem Server nichts fehlerhaft eingestellt worden ist und kein Sicherheitsrisiko besteht, werden Sie in dem Test mit der Note A belohnt.

Ein sicherer und korrekt eingestellter Server bekommt vom SSLlabs die Note A.

Ein sicherer und korrekt eingestellter Server bekommt vom SSLlabs die Note A.

Ein Vorteil von SSLLabs besteht darin, dass Sie zugleich auch eine Anleitung für eine korrekte Einstellung erhalten, sollte ein Fehler entdeckt werden.

 

 


Petra Alm
Spezialistin für TLS-Zertifikate
DigiCert TLS/SSL Professional
e-mail: info(at)sslmarket.de