Perfect Forward Secrecy – das ist ein SSL-Feature, das es erlaubt, sicher zu kommunizieren und Kommunikationen im Nachhinein nicht entschlüsseln zu lassen. Basierend auf dem Diffie-Hellman-Verfahren, senden sich zwei Kommunikationspartner (Client und Server) verschiedene Nachrichten, um einen gemeinsamen Schlüssel zu bekommen. Dieser Schlüssel wird nie über die Leitung übertragen, denn der öffentliche Schlüssel des Servers signiert lediglich den Austausch der Schlüssel. Der gemeinsame Schlüssel existiert nur während dieser einen Kommunikationsverbindung und wird anschließend von beiden Kommunikationspartnern gelöscht (Session Key). Somit schließt Perfect Forward Secrecy, kurz PFS, das nachträgliche Entschlüsseln der Kommunikation aus. Gut und schön. Aber wie wird PFS eingerichtet? Welche Systeme arbeiten mit PFS und wie lässt sich der sichere Weg der verschlüsselten Kommunikation einrichten? Das erfahren Sie in diesem Beitrag.
Cipher-Suiten: Starke Abweichungen in der Sicherheit
Bevor die Kommunikation zwischen zwei Partnern überhaupt verschlüsselt wird, handeln die Teilnehmer eine Chiffriermethode (= Cipher-Suite) aus. Der Client sendet eine Liste mit möglichen Methoden an den Server, der seinerseits eine Cipher-Suite selektiert, die er beherrscht. Aufs Wesentliche heruntergebrochen, besteht eine Cipher-Suite aus diesen Elementen:
• Mit der asymmetrischen Verschlüsselung wird das Schlüsselpaar gesichert.
• Das symmetrische Verfahren verschlüsselt die Kommunikation.
• Die Hashfunktion stellt die Integrität der Daten sicher.
Je nachdem, welche Cipher-Suite der Server ausgesucht hat, kann es extreme Abweichungen bezüglich der Sicherheit
geben. Schauen wir uns das in Beispielen an:
TLS_RSA_WITH_RC4_128_MD5 verwendet RSA als asymmetrische Verschlüsselung und RC4 für die Verschlüsselung der Kommunikation. MD5 soll dafür sorgen, die Datenintegritiät herzustellen. Das Problem dabei: Diese Elemente gelten nicht mehr als sicher. Dem entgegen verwendet die Cipher-Suite ECDHE-RSA-AES256-GCM-SHA384 als asymmetrische Verschlüsselung des Schlüsselpaars RSA, AEC mit GCM fürs Verschlüsseln der Kommunikation, SHA für die Integrität der Daten und zusätzlich das auf elliptischen Kurven basierende Diffie-Hellman- Schlüsselaustauschverfahren.
Oberstes Ziel innerhalb der sicheren Kommunikation muss es also sein, Algorhitmen zu verwenden, die dem aktuellen Stand der Technik entsprechen und als sicher gelten. Alle unsicheren Elemente müssen verbannt werden. Cipher-Suiten, die mit RC4 arbeiten, mussten in den vergangenen Jahren viele Angriffe über sich ergehen lassen: Oft wurden Schwachstellen in den Algorithmen gefunden, was die Berechnungszeit der Schlüssel reduzierte. Eine Cipher-Suite, die den verschiedenen Angriffsverfahren standhalten soll, muss folgende Eigenschaften aufweisen:
Das Verschlüsselungsverfahren muss schon ausreichend analysiert worden sein und die Cipher-Suite sollte größtenteils in gängigen Kryptobibliotheken implementiert sein (siehe OpenSSL). Es gilt, ein Verfahren zu nutzen, das von bekannten Institutionen (maßgeblich ist in aller Regel das Internet Engineering Task Force, IETF) bereits standardisiert ist. Basiert das Schlüsselaustauschverfahren auf Diffie-Hellman, verhindert man das nachträgliche Entschlüsseln vorher aufgezeichneter Kommunikationen durch das Bekanntwerden des geheimen Schlüssels.
Zusammenfassend bedeutet das: Eine sichere TLS-/SSL-Verbindung setzt eine Cipher-Suite ein, die sich aus diesen Elementen zusammensetzt: DHE oder ECDHE als Verfahren für den Schlüsselaustausch. DHE ist ECDHE vorzuziehen, da ECDHE Performanceeinbußen nach sich zieht. Als asymmetrische Verschlüsselung sind RSA oder ECDSA Mittel der Wahl. Die Kommunikation selbst wird mittels AES-GCM mit mindestens 128 Bit symmetrisch verschlüsselt. Mit extrem viel Aufwand, nämlich ca. 80 Milliarden US-Dollar und dem Strombedarf, der die komplette USA inklusive Lateinamerika und Kanada versorgt, soll sich die 128 Bit-Variante von AES berechnen lassen. Das ist unrealistisch, wer aber sichergehen will, entscheidet sich für die AES256 Bit-Variante. Die Datenintegrität stellt SHA als Hashfunktion sicher.
PFS: Empfehlung des IETF
Im September 2013 legte das IETF einen Entwurf vor, in dem das Nutzen von TLS 1.2 zusammen mit folgender Cipher-Suite empfohlen wird: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (s. Punkt 4. Recommendations). Das IETF legt diese Cipher-Suite für jeden Server als erste Wahl nahe, es sei denn, der Server kann nicht auf eine TLS 1.2 client_hello-Nachricht reagieren. Richten Sie bei Ihrem Server diese Cipher-Suite oder eine ähnliche, vielleicht noch stärkere wie TLS_DHE_RSA_WITH_AES_256_GCM_SHA256 ein. In den Profilen von TLS 1.2 existieren oft verschiedene Cipher Suites (beispielsweise TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 und/ oder TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384), die allerdings mit dem verlangsamendem ECDHE arbeiten. Da es häufig an der Browserunterstützung für ECDHE mangelt, kann es passieren, dass andere, unsichere Cipher-Suiten bevorzugt werden. Priorisieren Sie die vom IETF empfohlene Suite, wird diese bevorzugt, beachten Sie aber die Möglichkeit eines Fallbacks auf niedrigere Verschlüsselungsverfahren, wenn DHE nicht unterstützt wird. Das kann insbesondere dann der Fall sein, wenn Sie mit einer alten Browserversion surfen, die PFS noch nicht unterstützt oder sogar aussperrt, wie etwa der Internet Explorer 10 oder älter sowie unter Windows XP.
PFS ist in Webservern meist schon aktiviert
In aller Regel ist PFS in den Standardeinstellungen der Server schon aktiviert. Das kann den Anschein erwecken, dass Sie die aktuell sicherste Form der Verschlüsselung schon längst nutzen, allerdings gibt die Standardkonfiguration vor, dass der Browser die Verschlüsselung bestimmt. Überprüfen Sie also die Einstellungen Ihres Servers und Ihres Browsers, um dann gegebenenfalls wie oben beschrieben vorzugehen und die vom IETF empfohlene Cipher-Suite einzustellen. Beachten Sie, dass Sie zur Nutzung von TLS 1.2 eine aktuelle Browserversion benötigen. Konkret können Sie folgende Browser ab folgender Version problemlos nutzen:
• Mozilla Firefox ab Version 24
• Google Chrome ab Version 29
• Internet Explorer ab Version 11
• Opera Browser ab Version 16
• Apple Safari ab Version 7
In gängigen Webservern wie Apache oder nginx passen Sie den Konfigurationsblock der Variable ssl_protocols in der .conf-Datei wie folgt an:
nginx:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
SSLCompression Off
SSLHonorCipherOrder on
SSLCipherSuite „EECDH+AESGCM EDH+AESGCM !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4“
Apache:
SSLProtocol all -SSLv2 -SSLv3
ssl_prefer_server_ciphers on;
ssl_ciphers „EECDH+AESGCM EDH+AESGCM !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4“;
Damit unterstützen Sie die TLS-Version 1.2, geben aber älteren Browsern auch die Chance auf ein Fallback zu niedrigeren Versionen. Zudem grenzen Sie die Verschlüsselung darauf ein, dass unsichere Methoden wie RC4 ausgeschlossen werden.
So unterstützen Sie neben der IETF-Empfehlung auch folgende Verschlüsselungsmethoden:
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
AES256-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
AES128-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
DES-CBC3-SHA
Damit Ihr Browser diese Einstellungen auch nutzt, geben Sie die folgende Zeile in der Konfiguration an: ssl_prefer_server_ciphers on;
Starten Sie Ihren Server neu und Sie haben PFS erfolgreich eingerichtet. Wichtig: TLS 1.1 und 1.2 sind aktuell mit OpenSSL 1.0.1 verfügbar. Auf einem Linux-basierten System müssen diese Voraussetzungen erfüllt sein:
Apache 2.4.x+++
nginx 2.0.6+++
Wenn Sie diese Programmversionen installiert haben, bleibt nur noch, die PFS-Funktion wie oben beschrieben zu konfigurieren und die Cipher-Suiten korrekt anzuwenden.
PFS-Konfiguration: Drum prüfe, was sich ewig verschlüsselt …
Einrichten ist gut, prüfen noch besser. Was tun, wenn sich Client-Probleme ergeben? Sie finden heraus, welche der Cipher-Suiten mit der obigen Auswahl unterstützt werden, wenn Sie diesen Terminal-Befehl eingeben:
openssl ciphers -v ‚EECDH+AESGCM EDH+AESGCM !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4‘
Viele Browser beziehungsweise Clients unterstützten diese noch recht neuen Cipher-Suiten nicht – hoffentlich noch nicht und das ändert sich sehr bald. Ein typisches Problem in der Abwärtskompatiblität kann sich also ergeben, wenn der Client dem Server zu Beginn einer Kommunikation veraltete Cipher-Suiten auflistet, die der Server nicht unterstützt. Dann kann keine durch SSL-Zertifikate verschlüsselte Kommunikation stattfinden. Sie können testen, welche Cipher-Suiten von Ihrem Browser unterstützt werden: Die Website SSL Ciper Suite Details of your Browser der Uni Hannover hilft Ihnen dabei tatkräftig. Für Chrome in der Version 32 sieht das so aus:
Die Verbindung nutzt TLSv1.2 mit DHE-RSA-AES128-GCM-SHA256 und einen 128 Bit-Schlüssel zur Entschlüsselung und entspricht damit der Empfehlung des IETF.
Bei Firefox in der Version 26 wird der Galois/Counter-Mode (GCM) nicht unterstützt, sodass sich Client und Server nicht auf eine Cipher-Suite einigen werden können. Es kann aufgrund der Abwärtskompatibilität nötig sein, weitere Cipher-Suiten außerhalb der von TLS 1.2 zuzulassen. So sieht das Ganze in Firefox aus:
In der Version 19 nutzt Opera dieselben Parameter wie Google Chrome. Nutzen Sie Internet Explorer oder Safari? Dann teilen Sie Ihre Informationen gerne mit uns und unseren Lesern in den Kommentaren.
Zum abschließenden Prüfen Ihrer Konfiguration nutzen Sie idealerweise den SSL Server Test von ssllabs.com. Wir haben uns einmal die Seite bundestag.de angeschaut, die mit einem B-Rating davonkommt:
Der fehlende Support von TLS 1.2 wird bemängelt und das Handshake-Protocol zeigt, dass auch der Support von TLS 1.1 fehlt. Deshalb ist es, wie oben erwähnt, empfehlenswert, Probleme der Abwärtskompatibilität durch das Einschließen älterer TLS-Versionen zu vermeiden.
Haben Sie ergänzende Kommentare oder Tipps und Tricks, die unseren Lesern weiterhelfen? Dann freuen wir uns über Ihre Kommentare – auch Ihre Fragen sind selbstredend willkommen!