Wie Perfect Forward Secrecy vor der Entschlüsselung gehorteter Daten schützt

Perfect Forward Secrecy: Heute aufgezeichnet – morgen entschlüsselt?
Kommentare

Dieser Artikel war schon länger geplant. Eigentlich sollte er sich um die Frage drehen, wie die NSA SSL/TLS angreift und wie man über SSL/TLS übertragene Daten vor den Folgen des Datensammelwahns der NSA schützen kann. Und dann kam die Heartbleed-Schwachstelle in OpenSSL, und alles wurde schlimmer als zuvor angenommen.

Die NSA kann eventuell die schon seit Längerem als unsicher geltende RC4-Verschlüsselung brechen, man sollte sie also wenn immer möglich vermeiden. Außerdem kann die NSA sich zum Beispiel über gefälschte Zertifikate als Man-in-the-Middle in ausgewählte Verbindungen einklinken. Meist wird es für die NSA und auch alle anderen Geheimdienste aber einfacher sein, Spyware auf im Zielfernrohr stehende Rechner zu schleusen, um die Daten vor der Verschlüsselung auszuspähen. Zurzeit ist aber ein anderes Problem brisanter.

Die NSA – ein äußerst umtriebiger Sammler

Die NSA sammelt bekanntlich alles, was ihr irgendwie in die digitalen Finger gelangt. Auch die Daten von SSL/TLS-Verbindungen werden massenhaft auf Vorrat gespeichert, um sie möglicherweise später entschlüsseln zu können. Wie gelangt man an die Inhalte dieser irgendwann zuvor mitgeschnittenen SSL/TLS-Verbindungen? Sofern es nicht gelingt, die Verschlüsselung zu brechen (was bisher wenn überhaupt nur im Fall von RC4 möglich ist), gibt es nur noch eine Möglichkeit, an die begehrten Daten zu gelangen: Wer den vom Server verwendeten privaten Schlüssel kennt, kann die Daten auch nachträglich noch entschlüsseln. Oder genauer: Mit dem privaten Schlüssel den verwendeten Sitzungsschlüssel entschlüsseln und dann damit die restlichen Daten. Es sei denn, für die Verbindung wurde Perfect Forward Secrecy verwendet, mit dem genau dieser Angriff abgewehrt wird.

An den privaten Schlüssel der Server gelangt man normalerweise nicht so einfach. Es sei denn, man ist eine US-Behörde wie zum Beispiel die NSA und der Server steht in den USA oder wird von einem US-Unternehmen betrieben. Dann kann man den Betreiber einfach zur Herausgabe des Schlüssels und zum anschließenden Schweigen darüber verdonnern. An die Schlüssel im Ausland stehender Server ausländischer Betreiber gelangt man so aber nicht. Dafür muss man dann schon den Server kompromittieren oder den privaten Schlüssel anderweitig ausspähen. Was im Allgemeinen nicht unbedingt einfach und vor allem kaum spurenlos möglich ist.

Das war der Stand der Dinge bis zum 7. April 2014. An diesem Tag veröffentlichten die OpenSSL-Entwickler ein Security Advisory, das alles veränderte.

Die Heartbleed-Schwachstelle in OpenSSL

Die Heartbleed-Schwachstelle wurde unabhängig voneinander sowohl von Riku, Antti und Matti von Codenomicon (die auch den Namen geprägt und die Website Heartbleed.com gestartet haben) als auch von Neel Mehta von Google Security (der sie als erster an die OpenSSL-Entwickler gemeldet hat) entdeckt. Die Koordination der Reaktion auf die Schwachstelle hat das NCSC-FI übernommen. Die folgenden Informationen über die Schwachstelle stammen, sofern nichts anderes angegeben ist, aus diesen drei Quellen.

Heartbeat – Ein Herzschlag hält die TLS-Verbindung aufrecht

Die in RFC 6520 standardisierte Heartbeat-Funktion für mit TLS geschützte Verbindungen dient dazu, die Verbindung aufrechtzuerhalten, auch wenn sie gerade nicht benutzt wird. Dazu werden so genannte Heartbeat Requests an den Kommunikationspartner geschickt. Die bestehen aus zufälligen Daten (der Payload) und einem Feld, das die Länge dieser Daten enthält. Empfängt einer der Kommunikationspartner (egal ob Client oder Server) einen Heartbeat Request, muss er mit den gleichen zufälligen Daten antworten, die er empfangen hat.

Wenn im Folgenden vom Server die Rede ist, gilt das gleiche prinzipiell mit vertauschten Rollen auch für den Client. Auf dem sind aber im Allgemeinen weniger Daten auszuspähen und die Folgen eines Angriffs beschränken sich vor allem nur auf den betroffenen Benutzer. Bei einem Angriff auf einem Server sind dagegen potenziell alle seine Benutzer betroffen.

Heartbleed – OpenSSL war zu vertrauensselig

Die Heartbleed-Schwachstelle in OpenSSL besteht darin, dass die Längenangabe aus dem Heartbeat Request ungeprüft übernommen und verwendet wird. Empfängt ein Server einen Heartbeat Request, reserviert OpenSSL entsprechend dem Wert im Längenfeld einen Puffer. Danach werden die Daten entsprechend diesem Wert aus der Eingabe in den Puffer kopiert. Ohne zuvor zu prüfen, ob die empfangenen Daten überhaupt so lang sind, wie der Wert im Längenfeld behauptet. Gibt ein Angreifer eine größere Länge an als die von ihm gesendete Payload tatsächlich umfasst, werden die hinter der Payload liegenden Speicherbereiche in den Puffer kopiert.

Wird zum Beispiel die Payload-Länge mit 64 KB angegeben (das ist der Maximalwert), obwohl nur wenige Byte Payload gesendet werden, werden knapp 64 KB des vorhandenen Speichers in den Puffer kopiert. Samt der zuvor darin enthaltenen, möglicherweise sensitiven Daten. Nach dem Kopieren der Daten wird der gefüllte Puffer dann als Antwort auf den Heartbeat Request an den Client gesendet. Sehr schön wird das in einem xkcd-Cartoon illustriert.

Schlimmer geht immer

Verschlimmert wird die Schwachstelle dadurch, dass OpenSSL die Speicherverwaltung über einen Wrapper selbst durchführt, statt direkt die entsprechenden Systemfunktionen zu verwenden. Dadurch werden die Schutzfunktionen des Systems für die Speicherfunktionen unterlaufen. Außerdem reserviert sich OpenSSL dadurch größere Speicherblöcke am Stück und verteilt diese dann intern. Die über die Heartbleed-Lücke ausgespähten Speicherbereiche enthalten daher ausschließlich OpenSSL-Daten und nicht auch eventuell harmlosere Daten anderer Prozesse.

Was OpenSSL alles verraten kann

Ausgespäht werden kann zum Beispiel der private Schlüssel des Servers. Was im Grunde die größte Gefahr ist: Wer den privaten Schlüssel kennt, kann sich als der betreffende Server ausgeben und/oder aufgezeichnete TLS-Verbindungen entschlüsseln. Dass der private Schlüssel wirklich ausgespäht werden kann, haben zum Beispiel die Entdecker der Schwachstelle von Codenomicon, Tomas Rzepka und mehrere Teilnehmer der „CloudFlare Challenge“ erfolgreich getestet bzw. demonstriert.

Insbesondere die „CloudFlare Challenge“ ist dabei beachtenswert: Bei CloudFlare war man nach der Analyse der Schwachstelle der Ansicht, dass der private Schlüssel nicht ausgespäht werden kann und hat daraufhin eine Herausforderung ausgesprochen: Auf einem Testserver sollte über die Heartbleed-Schwachstelle der private Schlüssel ausgespäht werden. Was nicht nur einem, sondern gleich vier Forschern gelang.

Einer davon, Fedor Indutny, hat Details zu seinem Vorgehen veröffentlicht und beantwortet dabei auch die Frage, woran man denn den privaten Schlüssel erkennen kann: Er hat in den über die Heartbleed-Schwachstelle ausgespähten Daten nach den 128 Bytes langen Primfaktoren des Modulos des privaten Schlüssels gesucht und daraus die restlichen Parameter des privaten Schlüssels berechnet. Den verwendeten Code hat er auf GitHub veröffentlicht.

Genau so gefährlich wie das Ausspähen des privaten Schlüssels ist das Ausspähen der aus dem Schlüssel abgeleiteten so genannten CRTParameter. Die werden vom Server verwendet, um die späteren Berechnungen der Kryptofunktionen zu beschleunigen. Wer diese Parameter kennt, kann daraus den privaten Schlüssel berechnen. Wie es ja auch Fedor Indutny gemacht hat.

Etwas weniger kritisch ist das Ausspähen von über TLS empfangenen Benutzernamen und Passwörtern. Zum einen sind hier immer nur wenige Benutzer betroffen, zum anderen können nicht gezielt die Zugangsdaten ganz bestimmter Benutzer ausgespäht werden. Der Angreifer erhält die Zugangsdaten, die zufällig gerade im ausgespähten Speicherbereich abgelegt sind. Was für die betroffenen Benutzer natürlich katastrophal ist, denn wer die Zugangsdaten kennt, kann sich damit natürlich in deren Namen anmelden.

Das Ausspähen von Zugangsdaten wurde zum Beispiel für Yahoo! Mail demonstriert. In die gleiche Kategorie fällt das Ausspähen von Session-Cookies. Mit dem ausgespähten Session-Cookie kann der Angreifer dann eine laufende Sitzung eines Benutzers übernehmen. Aber auch hier gilt wie bei den Zugangsdaten: Der Angreifer muss nehmen, was kommt. Er hat keine Möglichkeit, gezielt bestimmte Benutzer bzw. deren Sitzungen anzugreifen. Dass das Ausspähen von Session-Cookies möglich ist, wurde zum Beispiel für Flickr demonstriert.

War da was?

Besonders unangenehm ist die Schwachstelle auch, weil der Angriff keine Spuren auf dem Server hinterlässt. Es werden keine Dateien angelegt oder verändert, der Angriff erfolgt komplett über das Netzwerk. Lediglich in Logfiles tauchen verräterische Heartbeat Requests auf – wenn diese denn ausführlich protokolliert werden, was eigentlich nicht üblich ist.

Immerhin gibt es zwei Möglichkeiten, Heartbleed-Angriffen durch die Auswertung der Logfiles oder des Netzwerkverkehrs auf die Spur zu kommen. Daniel Wesemann hat im InfoSec Handlers Diary Blog beschrieben, wie die Angriffe durch den Vergleich von Firewall- und Webserver-Logfile erkannt werden können. Enthält das Firewall-Logfile eine Reihe von tcp/443-(HTTPS-)Verbindungen zum Webserver, die im Webserver-Logfile nicht auftauchen, handelt es sich sehr wahrscheinlich um Heartbeat bzw. Heartbleed Requests. Bei der Untersuchung eines Servers eines „Community College“ wurden entsprechende Requests von einer IP-Adresse in Malaysia gefunden, gefolgt von Requests, die sowohl im Firewall- als auch im Webserver-Logfile auftauchten. Vermutlich hat jemand zuerst Session-Cookies ausgespäht, die dann getestet wurden. Der Nachteil dieser Methode: Man kann ohne zusätzliche Informationen nicht zwischen legitimen Heartbeat und bösartigen Heartbleed Requests unterscheiden. Nur wenn die Heartbleed Requests vollständig protokolliert wurden, verrät sie ihr Aufbau: Stimmen tatsächliche Payloadlänge und die Angabe im Längenfeld nicht überein, handelt es sich sehr wahrscheinlich um einen Angriff. Insbesondere, wenn die Payload sehr klein und ihre angebliche Größe sehr groß ist.

Von Forschern des Lawrence Berkeley National Laboratory wurde eine andere Erkennungsmethode entwickelt: Sie erkennen die Heartbleed-Angriffe daran, dass die Antwort auf einen Heartbeat Request größer als der Request ist. Bei der Analyse des seit Ende Januar aufgezeichneten Netzwerkverkehrs des Berkeley National Laboratory und des National Energy Research Scientific Computing Centers wurden keine Angriffe festgestellt.

Beide Methoden setzen natürlich voraus, dass man etwas zum Auswerten zur Verfügung hat. Der Fehler und damit die Schwachstelle war seit der Einführung der Heartbeat Extension in OpenSSL enthalten. Und die erfolgte am 1. Januar 2012. Die erste finale Version von OpenSSL 1.0.1 wurde am 14. März 2012 veröffentlicht. Die Server derjenigen, die die neue Version sofort installiert und die Heartbeat-Erweiterung aktiviert haben, waren also mehr als zwei Jahre lang angreifbar. Wer hat schon aus diesem Zeitraum noch alle Logfiles, vom kompletten Netzwerkverkehr ganz zu schweigen? Und nein, „die NSA“ lasse ich nicht als zulässige Antwort zu. Die ist höchstens die Ausnahme, um die Regel zu bestätigen.

Da war was!

Die Electronic Frontier Foundation (EFF) hat Hinweise darauf, dass die Schwachstelle bereits im November 2013 ausgenutzt wurde. In einem Logfile wurden Einträge gefunden, die mit denen eines aktuellen Proof of Concept Exploits für die Heartbleed-Schwachstelle identisch sind. Die Requests kamen von IP-Adressen, die zu einem Botnet gehören. Und zwar zu einem, dass systematisch versucht hat, die IRC-Kommunikation auf Freenode und einer Reihe weiterer IRC-Netzwerke zu sammeln. Was dafür spricht, dass ein Geheimdienst hinter den Angriffen steckt. Was sollten Cyberkriminelle mit Chatprotokollen? Die nutzen zwar mitunter IRC zur Steuerung für Bots, aber dann holt sich der Bot seine Anweisungen aus genau einer Quelle und sammelt nicht alles, was er unter die virtuellen Finger bekommt.

Der Zeitraum „November 2013“ ist dabei nur ein Hinweis darauf, wann die Angriffe spätestens begannen. Sie können durchaus auch schon noch länger laufen, zufällig liegen Logfiles mit verdächtigen Einträgen aus dem November 2013 vor. Weitere Angriffe wurden nach der Veröffentlichung der Patches gemeldet, die sind hier aber nicht wirklich wichtig.

[ header = Seite 2: Hat die NSA die Heartbleed-Schwachstelle ausgenutzt? ]

Hat die NSA die Heartbleed-Schwachstelle ausgenutzt?

Die Nachrichtenagentur Blomberg hat kurz nach Bekanntwerden der Heartbleed-Schwachstelle mit Verweis auf zwei damit befasste Personen („two people familiar with the matter“) gemeldet, dass die NSA die Schwachstelle seit mindestens zwei Jahren kennt und auch ausnutzt, was von der NSA sofort bestritten wurde. Wer Recht hat, lässt sich schwer feststellen.

Gesammelte verschlüsselte Daten + privater Schlüssel = eine gefährliche Kombination

Jeder, der SSL/TLS-verschlüsselte Daten gesammelt hat, kann diese jederzeit entschlüsseln, wenn er an den verwendeten privaten Schlüssel gelangt. Sofern die Verschlüsselung nicht entsprechend abgesichert ist. Was inzwischen dringend angeraten ist. Zum Glück gibt es ein Verfahren, um die Entschlüsselung der Datenströme nach Abschluss der Kommunikation zu verhindern: Perfect Forward Secrecy. Das schützt zwar nicht vor einem laufenden Man-in-the-Middle-Angriff, dafür aber vor der nachträglichen Auswertung gesammelter Datenberge.

SSL/TLS im Einsatz

Perfect Forward Secrecy (das mitunter auch einfach Forward Secrecy genannt wird, kurz PFS oder FS) ist im Grunde ein recht einfaches Verfahren. Man muss nur die passenden Cipher Suiten verwenden. Aber bevor ich Perfect Forward Secrecy beschreiben kann, müssen Sie wissen, wie die SSL-Verschlüsselung generell funktioniert. Das ist eigentlich ganz einfach: Wenn Sie im Webbrowser durch den Aufruf eines HTTPS-Links eine sichere Verbindung zum Beispiel zum Webserver Ihrer Bank aufbauen, werden mehrere kryptografische Verfahren eingesetzt:

  • Eine Public-Key-Infrastruktur wird verwendet, um die Identität des Servers zu prüfen und dessen öffentlichen Schlüssel zu erhalten. Das verwendete Zertifizierungssystem ist auch nicht der Weisheit letzter Schluss, hier aber ausnahmsweise mal nicht das Problem.
  • Ein asymmetrisches Kryptosystem dient dazu, den vom Webbrowser erzeugten Sitzungsschlüssel sicher an den Server zu senden.
  • Ein symmetrisches Kryptosystem wird verwendet, um alle danach übertragenen Daten mit dem Sitzungsschlüssel zu verschlüsseln.

Aufgeteilt in die einzelnen Schritte sieht das folgendermaßen aus (siehe auch Abb. 1):

  1. Sie geben im Browser https://w ww.ihre-bank.example ein.
  2. Ihr Browser baut eine Verbindung zum Webserver w ww.ihre-bank.example auf.
  3. Der Webserver sendet sein Zertifikat mit seinem öffentlichen Schlüssel an Ihren Browser.
  4. Ihr Browser prüft das Zertifikat.
  5. Verläuft die Prüfung erfolgreich, weiß der Browser, dass der im Zertifikat enthaltene öffentliche Schlüssel dem Server w ww.ihre-bank.example gehört. Nun erzeugt er einen symmetrischen Schlüssel, der nur für die aktuelle Sitzung verwendet wird, den Sitzungsschlüssel oder Session Key.
  6. Der Sitzungsschlüssel wird mit dem öffentlichen Schlüssel des Webservers verschlüsselt und an den Webserver übertragen.
  7. Der Webserver entschlüsselt den Sitzungsschlüssel mit seinem privaten Schlüssel. Wenn ihm das möglich ist, kann der Browser sicher sein, wirklich mit dem Server w ww.ihre-bank.example verbunden zu sein. Denn nur der kennt den privaten Schlüssel (jedenfalls normalerweise, Angriffe mal außen vorgelassen).
  8. Jetzt besitzen sowohl Webbrowser als auch Webserver einen gemeinsamen Schlüssel für das symmetrische Kryptosystem, mit dem sie alle weiteren zu übertragenen Daten verschlüsseln können.
  9. Der Webserver baut seine Startseite auf, verschlüsselt sie mit dem Sitzungsschlüssel und sendet sie an den Browser.
  10. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
  11. Alle weiteren übertragenen Daten werden ebenso mit dem Sitzungsschlüssel verschlüsselt.

Abb. 1: SSL/TLS-Verbindungsaufbau

Das Problem ist in diesem Fall der Austausch des Sitzungsschlüssels. 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 danach übertragenen Daten.

Perfect Forward Secrecy – der Sitzungsschlüssel bleibt geheim

Genau an diesem Punkt setzt PFS an: Statt den Schlüssel komplett vom Client erzeugen zu lassen und ihn dann an den Server zu senden, wird der 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.

Der Diffie-Hellman-Schlüsselaustausch in der Theorie …

Der Diffie-Hellman-Schlüsselaustausch wurde von Whitfield Diffie und Martin E. Hellman 1976 in ihrem Paper „New Directions in Cryptography“ vorgestellt, der ersten Arbeit über asymmetrische Kryptografie.

Das Prinzip des Verfahrens besteht darin, das sich die Kommunikationspartner über eine unsichere Verbindung je eine Nachricht zusenden, aus denen sie dann einen gemeinsamen Schlüssel berechnen können. Ein Dritter, der die Nachrichten belauscht, ist dazu nicht in der Lage. Das Verfahren ist nur unsicher, wenn der Dritte als Man-in-the-Middle die Nachrichten manipulieren kann. Der Man-in-the-Middle tauscht dann mit jedem der Kommunikationspartner einen eigenen Schlüssel aus und kodiert die Daten später passend um. Die Abwehr dieses Angriffs ist sehr einfach: Werden die Diffie-Hellman-Nachrichten signiert oder mit einem Message Authentication Code gesichert, ist eine unbemerkte Manipulation nicht möglich und der MitM-Angriff scheitert. Die mathematische Beschreibung des Verfahrens finden Sie im Infokasten „Mathematische Beschreibung des Diffie-Hellmann-Schlüsselaustauschs“.

Mathematische Beschreibung des Diffie-Hellman-Schlüsselaustauschs Im Folgenden wird von zwei Kommunikationspartnern ausgegangen, die in der Kryptografie traditionell Alice und Bob genannt werden. Der Schlüsselaustausch läuft folgendermaßen ab: 1. Alice und Bob einigen sich auf eine Primzahl p und eine Primitivwurzel (*) g mod p mit 1 < g < p-1. p und g müssen nicht geheim bleiben, können also über eine unsichere Verbindung übertragen werden. Außerdem können sie vorab vereinbart und immer wieder verwendet werden. 2. Alice wählt eine geheime Zahl a < p und sendet Bob A = ga mod p. 3. Bob wählt eine geheime Zahl b < p und sendet Alice B = gb mod p. A und B müssen nicht geheim bleiben, können also über eine unsichere Verbindung übertragen werden. 4. Alice berechnet k = Ba mod p (und kann danach a löschen). 5. Bob berechnet k’ = Ab mod p (und kann danach b löschen). (*) g ist eine Primitivwurzel von p, wenn sich alle Zahlen von 1 bis p-1 als Reste der Form gi mod p darstellen lassen. k und k' sind identisch, denn es gilt k = Ba mod p = gba mod p = gab mod p = Ab mod p = k’ , und können als Sitzungsschlüssel für ein symmetrisches Verfahren verwendet werden. Ein lauschender Angreifer Ein lauschender Angreifer (üblicherweise Eve genannt) kennt zwar p, g, A und B, aber um den Schlüssel k zu ermitteln, muss er das so genannte Diffie-Hellman-Problem lösen: Bekannt sind g, gx und gy. Welchen Wert hat gxy? Dazu muss er diskrete Logarithmen berechnen können: Er benötigt das x aus gx mod p (oder das y aus gy mod p). Dies ist ein mathematisch hartes Problem und ähnlich schwer wie die Faktorisierung. Im Mai 2014 wurde ein Teilproblem in polynomieller Zeit gelöst, insgesamt sind die darauf basierenden Verfahren aber noch sicher. Die Sicherheit des Verfahrens hängt entscheidend von der Größe von p ab. Außerdem sollte (p-1)/2 ebenfalls eine Primzahl sein. g kann beliebig groß gewählt werden, es muss nur eine Primitivwurzel modulo p sein. Es spricht nichts dagegen, das kleinstmögliche g zu wählen. Ein Zahlenbeispiel für den Diffie-Hellman-Schlüsselaustausch mit einem Lauscher sehen Sie in Tabelle 1. Tabelle 1: Der Diffie-Hellman-Schlüsselaustausch mit Lauscher als ZahlenbeispielEin Man-in-the-Middle-Angriff Kann der Angreifer Mallory als Man-in-the-Middle die ausgetauschten Nachrichten manipulieren, kann er den Schlüsselaustausch unterlaufen: Er fängt die Nachrichten ab und sendet seinen eigenen Wert M = gm mod p mit einem beliebigen m statt A und B. Es findet also je ein Schlüsselaustausch zwischen Alice und Mallory und zwischen Mallory und Bob statt – ohne dass Alice und Bob etwas von Mallory wissen. Mallory fängt danach die symmetrisch verschlüsselten Daten ab, entschlüsselt sie mit dem zum jeweiligen Absender gehörenden Schlüssel und verschlüsselt sie vor dem Weiterleiten mit dem zum Empfänger gehörenden Schlüssel. Dabei kann er die entschlüsselten Daten beliebig manipulieren. Um diesen Angriff zu verhindern, müssen die ausgetauschten Nachrichten durch eine digitale Signatur oder einen Message Authentication Code authentisiert werden. Ein Zahlenbeispiel für den Diffie-Hellman-Schlüsselaustausch mit einem Man-in-the-Middle sehen Sie in Tabelle 2. Tabelle 2: Der Diffie-Hellman-Schlüsselaustausch mit Man-in-the-Middle als Zahlenbeispiel

… und in der Praxis

Die SSL/TLS-Spezifikationen (zum Beispiel hier und hier) enthalten mehrere auf Diffie-Hellman basierende Schlüsselaustauschverfahren, die PFS sicherstellen: 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 Diffie-Hellman-Verfahren haben jedoch einen Nachteil: Während zum Beispiel bei einem RSA-Verfahren lediglich ein Schlüssel als Zufallszahl erzeugt und eine Nachricht mit dem Schlüssel ausgetauscht werden muss (Schritt 5 und 6), sind bei den DH-Verfahren mehrere Berechnungen und Nachrichten nötig (siehe Tabelle 1, die an Stelle von Schritt 5 und 6 tritt). Der zusätzliche Overhead beträgt bei den performanteren Verfahren auf Basis elliptischer Kurven ca. 15 bis 30 Prozent. Beim herkömmlichen Verfahren ist der Overhead natürlich noch deutlich größer.

Aber dieser zusätzliche Aufwand sollte jedem Serverbetreiber die Sicherheit der übertragenen Daten wert sein. Wird PFS genutzt, sind aufgezeichnete Kommunikationsvorgänge quasi nutzlos. Nachdem der temporäre Sitzungsschlüssel gelöscht wurde, ist eine Entschlüsselung nicht mehr möglich.

Perfect Forward Secrecy einrichten

Wie Sie PFS für Apache, nginx und OpenSSL einrichten, beschreibt zum Beispiel Ivan Ristic im Qualys-Blog sehr ausführlich. Einfach formuliert müssen Sie lediglich dafür sorgen, dass die passenden Cipher Suiten (also die mit DHE_* bzw. ECDHE_* im Namen) verwendet werden. Ivan Ristic empfiehlt, die folgenden Suiten zu bevorzugen:

  • TLS_ECDHE_RSA_WITH_RC4_128_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Auf der Clientseite ist das Ganze noch einfacher: Die aktuellen Versionen von Firefox, Chrome und Opera bevorzugen PFS, wenn es ihnen angeboten wird. Der Internet Explorer und Safari verwenden es, wenn der Server darauf besteht.

Mit dem SSL-Server-Test der Qualys SSL Labs können Sie testen, ob ein Server PFS unterstützt. Dabei wird auch getestet, was verschiedene Browser bei der Verbindung mit dem getesteten Server aushandeln würden. Die entsprechende Ausgabe für mail.google.com sehen Sie in Abbildung 2. Google hat PFS bereits im November 2011 für Google Mail und weitere Server aktiviert.

Abb. 2: Die Handshake-Simulation des SSL-Server-Test für mail.google.com

Denkt denn keiner an die E-Mails?

Oben habe ich das ganze zwar mehr oder weniger am Beispiel eines Webservers beschrieben, noch viel wichtiger ist meines Erachtens aber die Verwendung von PFS für E-Mail-Server. E-Mails werden noch viel zu selten Ende-zu-Ende-verschlüsselt, sodass die Verschlüsselung während der Übertragung ihr einziger Schutz vor neugierigen Mitlesern ist. Und der sollte möglichst lange wirksam sein. Grob vereinfacht müssen Sie dazu wie im Fall der Webserver im Allgemeinen nichts weiter machen, als die Cipher Suiten mit DHE_* bzw. ECDHE_* im Namen in der Konfiguration möglichst weit nach oben zu befördern. Ob die E-Mail-Clients PFS nutzen, ist dann eine andere Frage.

Fazit

„Heute aufgezeichnet, morgen entschlüsselt“ ist ein handfestes Problem der IT-Sicherheit. Die NSA sammelt die verschlüsselten Daten ja nicht, weil sie gerade nichts Besseres zu tun hat. Man weiß dort sehr genau, dass jede Verschlüsselung nur ein Zeitschloss ist – irgendwann gelangt man schon an den für die Entschlüsselung benötigten privaten Schlüssel, oder die wachsende Rechenleistung und neue Verfahren zur Kryptoanalyse erlauben das Brechen der Verschlüsselung.

Perfect Forward Secrecy sorgt sehr effektiv dafür, dass aufgezeichnete SSL/TLS-Kommunikation nach deren Abschluss selbst bei Kenntnis des privaten Schlüssels des Servers nicht mehr entschlüsselt werden kann. Und falls es jemandem gelingt, die Verschlüsselung einer Sitzung zu brechen und den verwendeten Schlüssel zu ermitteln (was äußerst unwahrscheinlich ist), bringt ihn das nicht viel weiter. Er kann dann zwar die eine Sitzung entschlüsseln, aber keine andere. Denn dafür wurden ja jeweils andere Sitzungsschlüssel verwendet.

Dass der für PFS notwendige Diffie-Hellman-Schlüsselaustausch deutlich aufwändiger als das einfache Erzeugen und Senden eines Sitzungsschlüssels ist, ist ein geringer Preis für die dadurch erreichte Sicherheit. Der zusätzliche Aufwand sollte jedem Serverbetreiber der Schutz der übertragenen Daten wert sein.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -