SSL-verschlüsselte Verbindungen

Thomas LENNE, 123RF

Perfect! Forward Secrecy

Durch der Enthüllungen über die weltweite Überwachung durch Geheimdienste gerät ein SSL/TLS-Feature in den Blickpunkt, das die Sicherheit SSL-verschlüsselter Verbindungen erhöht: Perfect Forward Secrecy.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Mit dem etwas unverbindlich klingenden Begriff der Folgenlosigkeit wird im Krypto-Jargon das englische Perfect Forward Secrecy (PFS) übersetzt. Gemeint ist damit, dass Angreifer aus einem aufgedeckten geheimen Langzeitschlüssel nicht auf damit ausgehandelte Sitzungsschlüssel eines Kommunikationskanals schließen und ihn so mithören können [1] . Die Folgen einer solchen Schwachstelle sind also eingrenzbar. Gerade bei der SSL-Verschlüsselung von HTTP-Verbindungen kann man diese Eigenschaft ausnutzen.

Zu Beginn einer SSL-Session handeln die Kommunikationspartner Session-Keys aus, mit der dann die gesammte Session verschlüsselt wird. Bei den gängigen Methoden (RSA) wird der Private-Key des Servers benutzt, um den Session-Key zu generieren – mit dem Seiteneffekt, dass sich aufgezeichnete SSL-Verbindungen mit dem Private-Key des Servers im Nachhinein entschlüsseln lassen oder aber Man-in-the-Middle-Angriffe möglich sind. Das Problem liegt darin, dass der Private-Key des Servers sowohl für Authentifizierung und Verschlüsselung benutzt wird. Authentizität ist aber nur für den Moment der Kommunikationsaufnahme wichtig, während die Verschlüsselung für Jahre sicher sein sollte.

Als Alternative dazu bietet sich der Diffie-Hellmann-Algorithmus an. Durch Einsatz dieses Verfahrens werden für jede SSL-Session Keys generiert, die sich nicht aus dem Private-Key des Servers herleiten lassen und somit eine spätere Entschlüsselung nur durch Brute-Force-Brechen des Session-Keys möglich ist. PFS ermöglicht, dass heutige SSL-verschlüsselte Kommunikation zukünftig sicher ist, auch wenn der Private-Key des Servers irgendwann kompromittiert werden sollte.

SSL und PFS

SSL unterstützt PFS über zwei Algorithmen: Diffie-Hellman (DHE) und Elliptic Curve Diffie-Hellmann (ECDHE). Eine genaue Beschreibung der beiden Methoden liefern die Artikel "SSL/TLS & Perfect Forward Secrecy" von Vincent Bernat [2] und "Deploying Forward Secrecy" von Ivan Ristic [3] .

Ob die Algorithmen in der installierten OpenSSL-Version verfügbar sind, zeigt Listing 1 exemplarisch für ECDHE, unter [4] gibt es eine Übersicht unterstützter Methoden für einzelne Linux-Distributionen. ECDHE ist erst mit der OpenSSL-Version 1.x verfügbar, DHE auch in älteren Versionen.

Listing 1

Algorithmen in OpenSSL

 

Werden die benötigten Algorithmen von der installierten OpenSSL-Version nicht unterstützt, muss man OpenSSL für die eigene Plattform kompilieren [5] . Nginx zum Beispiel bietet die Möglichkeit an, die OpenSSL-Quellen beim Kompilieren mit anzugeben und statisch einzubinden: »./configure ... --with-openssl=/pfad/zum/openssl_sourcecode« [6] , [7] .

Der höhere Aufwand beim Generieren der Session-Keys geht mit Performance-Einbußen einher: DHE-Algorithmen sind langsamer als ECDHE-Algorithmen, dafür steht ECDHE nicht überall zur Verfügung: in OpenSSL erst ab 1.x. In älteren Browsern und Clients kann die Unterstützung fehlen. Performance-Tests [2,8] belegen Einbrüche von 25 bis 50 Prozent bei DHE gegenüber ECDHE.

Wenn man also SSL-verschlüsselte Webseiten betreibt, eine möglichst große Anzahl unterschiedlicher Betriebssysteme und Browser unterstützen und für alle Besucher PFS aktivieren will, wirkt sich dies auf die Performance der SSL-Verbindungen aus.

Mit PFS kann jede SSL-fähige Kommunikation abgesichert werden, unter anderem für Webserver, Mailserver und Stunnel-Installationen. Webserver-Setups lassen sich via SSLLabs' SSL Server Test [9] überprüfen, ein im Sommer neu hinzugefügter Test überprüft die PFS-Fähigkeit des Servers. Eine Anmerkung dazu: Wird serverseitig nur ECDHE angeboten, erscheinen in der Handshake-Auswertung zwar Browser, die PFS beherrschen, da ältere Clients aber nur DHE-Algorithmen kennen, wird der Zusatz "PFS" in der Zusammenfassung nicht angezeigt. Unter Protocol Details erscheint der Zusatz: "Forward secrecy: With modern browsers".

Während für Web-Applikationen der Einsatz von PFS empfehlenswert ist, kann diese Maßnahme bei statischen Inhalten wie CSS, Javascript, Bildern und Icons unterbleiben. Dafür kann man performantere Algorithmen auswählen, wenn die Informationen nicht sonderlich schützenswert sind.

PFS hat im Web noch keine weite Verbreitung gefunden, mit Stand Oktober 2013 unterstützen gerade einmal 4,2 Prozent der populärsten Webseiten neuere PFS-Algorithmen (ECDHS), während 54 Prozent der untersuchten Webserver PFS nicht anboten [10] .

Konfiguration

Die Konfiguration von PFS ist für jeden Dienst verschieden und benötigt mindestens zwei Optionen: der Server muss die am meisten bevorzugte Cipher Suite auswählen können, einzelne Cipher Suites und deren Anordnung müssen konfigurierbar sein.

Für die Webserver Apache und Nginx gibt es mehrere Anleitungen http://11,7 , in Listing 2 und 3 sind die wesentlichen Optionen aufgeführt, die bei SSLLabs [9] zu einem perfekten Ergebnis führen ( Abbildung 1 ).

Abbildung 1: Gut gemacht: Ein perfektes Ergebnis bei den Test der SSLLabs.

Listing 2

Apache-Konfiguration

 

Listing 3

Nginx-Konfiguration

 

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Was von TLS übrig bleibt

Zahlreiche Angriffe haben die Sicherheit von SSL/TLS-Verschlüsselungen in den letzten Jahren erschüttert. Abhilfe schaffen würden neuere Standards, doch die sind kaum verbreitet.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023