Skip to content

Verfahren der Kryptographie, Teil 13: Perfect Forward Secrecy

Ein großer Schwachpunkt des bisher beschriebenen Einsatzes von SSL/TLS ist der Austausch des Sitzungsschlüssels bzw. des für seine Berechnung verwendeten Pre-Master-Secrets.

Zeichnet ein Angreifer die gesamte Kommunikation einschließlich des Verbindungsaufbaus auf und gelangt er irgendwann in der Zukunft an den privaten Schlüssel des Webservers, kann er damit den Sitzungsschlüssel entschlüsseln. Und damit dann alle weiteren während der Sitzung übertragenen Daten.

Dass das keine theoretische Gefahr ist wissen wir ja inzwischen: Die NSA (und sicher auch andere Geheimdienste) sammeln bereits alles, was sie unter ihre virtuellen Finger bekommen. Und der private Schlüssel lässt sich zum Beispiel durch Ausnutzung einer Schwachstelle wie zum Beispiel dem Heartbleed-Bug in OpenSSL ausspähen. Was zumindest die NSA getan haben soll. Die außerdem auch noch die Möglichkeit hat, US-Unternehmen zur Herausgabe des Schlüssels und anschließenden Stillschweigen darüber zu zwingen.

Zum Glück gibt es ein Verfahren, um die Entschlüsselung der Datenströme nach Abschluss der Kommunikation zu verhindern: Perfect Forward Secrecy (das mitunter auch einfach Forward Secrecy genannt wird, kurz PFS oder FS). Statt den Schlüssel komplett vom Client erzeugen zu lassen und ihn dann an den Server zu senden, wird der in der vorherigen Folge vorgestellte Diffie-Hellman-Schlüsselaustausch verwendet. Der sorgt dafür, dass der Sitzungsschlüssel niemals übertragen wird und daher auch nicht aus den aufgezeichneten Daten extrahiert werden kann. Nachdem der Sitzungsschlüssel am Ende der Sitzung gelöscht wurde, können möglicherweise aufgezeichnete Daten nicht mehr entschlüsselt werden.

Die NSA (oder wer auch immer) steht dann vor dem gleichen Problem wie die lauschende Eve im ersten Beispiel zum Diffie-Hellman-Schlüsselaustausch: Die aus dem Schlüsselaustausch bekannten Werte erlauben es nicht, den Schlüssel zu berechnen. Das können nur Client und Server.

Perfect Forward Secrecy in der Praxis: Im Web...

Die SSL/TLS-Spezifikationen (zum Beispiel RFC 5246 für TLS 1.2) enthalten mehrere auf Diffie-Hellman basierende Schlüsselaustauschverfahren, die Perfect Forward Secrecy sicher stellen: DHE_* für herkömmliche Verfahren, ECDHE_* für auf elliptischen Kurven basierende Verfahren. Das "E" hinter dem "DH" steht dabei für "ephemeral", also flüchtige/kurzlebige Schlüssel.

Die Nutzung von Perfect Forward Secrecy ist sehr einfach. Auf dem Client müssen Sie gar nichts machen, die aktuellen Webbrowser unterstützen die Chiphersuiten mit Perfect Forward Secrecy bereits und verwenden sie, wenn sie ihnen vom Server angeboten werden.

Auf dem Server müssen Sie lediglich dafür sorgen, dass die passenden Cipher-Suiten (also die mit DHE_* bzw. ECDHE_* im Namen) verwendet werden. Anleitungen für Apache, nginx und OpenSSL hat Ivan Ristic bereits 2013 im Qualys Blog veröffentlicht.

Stark vereinfacht müssen Sie im Allgemeinen nichts weiter machen, als die gewünschten Cipher-Suiten in der Liste der unterstützten Cipher-Suiten in der Konfiguration des Webservers möglichst weit nach oben zu befördern. Ivan Ristic empfiehlt, die folgenden Suiten zu bevorzugen:

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Die Diffie-Hellman-Verfahren haben jedoch einen Nachteil: Während zum Beispiel bei einem RSA-Verfahren lediglich eine Zufallszahl (das Pre-Master-Secret) erzeugt und eine Nachricht damit ausgetauscht werden muss, sind bei den DH-Verfahren mehrere Berechnungen und Nachrichten nötig. Der zusätzliche Overhead beträgt bei den performanteren Verfahren auf Basis elliptischer Kurven ca. 15-30 Prozent. Bei herkömmlichen Verfahren ist der Overhead noch größer. Aber dieser zusätzliche Aufwand sollte jedem die Sicherheit der übertragenen Daten Wert sein.

Ob ein Webserver Perfect Forward Secrecy unterstützt verrät Ihnen der SSL Server Test der Qualys SSL Labs. Dabei wird auch getestet, was verschiedene Browser bei der Verbindung mit dem getesteten Server aushandeln würden, und ob der Server vor bekannten Angriffen geschützt ist.

... und für Mail

Auch die Kommunikation mit dem Mailserver kann mit Hilfe von Perfect Forward Secrecy vor einer nachträglichen Entschlüsselung aufgezeichneter Datenströme geschützt werden. Besser wäre es natürlich, die Mails selbst durch eine Ende-zu-Ende-Verschlüsselung zu schützen, aber so lange das nicht passiert ist ihr Schutz während des Transports besser als gar kein Schutz.

Die meisten Mailserver unterstützen ebenso wie die Webserver die benötigten Cipher-Suiten mit DHE_* bzw. ECDHE_* im Namen bereits. Grob vereinfacht müssen Sie also wie im Fall der Webserver im Allgemeinen nichts weiter machen, als diese Cipher-Suiten in der Konfiguration des Mailservers möglichst weit nach oben zu befördern. Ob die Mail-Clients Perfect Forward Secrecy nutzen, ist dann eine andere Frage.

Ab der nächsten Folge werden die schon mehrmals erwähnten Hashfunktionen vorgestellt.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Kryptographie - Ein Überblick

Vorschau anzeigen
Die Kryptographie ist ein ein sehr umfangreiches Themengebiet, und obwohl ich mich jetzt seit 30 Artikeln damit befasst habe sind längst nicht alle Themen vorgestellt worden. Aber zumindest die wichtigsten habe ich beschrieben, und damit soll e