Dieser Beitrag handelt von Forward Secrecy, einer Methode, um verschlüsselte Kommunikation direkt nach Ende der Session unbrauchbar zu machen und damit vor späterer Entschlüsselung zu schützen.
Wenn über Sicherheit von Websites gesprochen wird, betrachten wir vor allem das Hier und Heute. Aber das ist nicht alles. Es wird befürchtet, dass in exorbitant großen Mengen verschlüsselte Kommunikation auf den Servern der Geheimdienste der Welt gespeichert wird. Diese kann zwar (hoffentlich) heute noch nicht entschlüsselt werden. Doch ganz sicher arbeiten diverse legale und, vor allem, illegale Organisationen daran, den heute vorhandenen Schutz durch Verschlüsselung zu knacken.
Der Weg dahin ist die Art, wie SSL/TLS-Verbindungen sich verschlüsseln. Jede Internet-SSL-Verbindung beginnt mit einem sogenannten handshake (Händedruck), bei dem beide Seiten – der Web-Browser des Nutzers und der Webserver der angewählten Website – Ihre Fähigkeit zur Verschlüsselung bekannt geben und, wenn das festgestellt ist, sich auf einen (kurzlebigen) Session-Schlüssel einigen . Dabei authentifiziert sich der Server gegenüber dem anfragenden Web-Browser. Neben der Authentifizierung dient der Schlüsseltausch auch zur Verschlüsselung der Kommunikation während der gesamten Session. Die Schlüssel werden anschließend gelöscht. Das Ziel der Schlüsselaustauschphase ist also, beiden Seiten zu ermöglichen, andere zu hindern, an der Session teilzunehmen, also mitzuhören oder ggf. auch zu manipulieren.
Sitzungsschlüssel: Generierung und Austausch
Es gibt mehrere Verfahren zum Schlüsseltausch. Das traditionell verwendete Verfahren nutzt den RSA-Schlüssel des Servers, um den Session-Schlüssel sicher vom Client zum Server zu übertragen. Das ist ein äußerst effizientes Verfahren.
Allerdings kann damit jeder, der eine Kopie des privaten Schlüssels des Servers besitzt, die Session-Schlüssel aufdecken und damit die Session entschlüsseln. Das ist durchaus für einige Sicherheits-Techniken wünschenswert, weil sie ohne das nicht arbeiten könnten.
Mögliche Angreifer verfügen vielleicht heute nicht über den privaten Schlüssel vieler Server. Aber vielleicht verfügen sie später über Techniken, an den privaten Schlüssel zu gelangen und damit im Nachhinein jede gespeicherte, verschlüsselte Kommunikation des Webservers mit allen Beteiligten zu entschlüsseln.
Der Diffie-Hellmann-Schlüsseltausch
Eine Alternative zu dem RSA-basierte Schlüsselaustausch besteht darin, den vergänglichen Diffie-Hellman-Algorithmus zu verwenden. Dieser erzeugt den Session-Schlüssel so, dass nur die an der Kommunikation Beteiligten ihn erhalten. Niemand, auch niemand, der den privaten Schlüssel des Servers besitzt, kann ihn bekommen. Nachdem sie Sitzung beendet ist, zerstören beide Seiten den Session-Schlüssel. Auf diese Weise kann die Session nur noch entschlüsselt werden, wenn der Session -Schlüssel bekannt ist. Diese Funktion wird Forward Secrecy genannt.
Einen Session-Schlüssel zu knacken ist eindeutig viel schwieriger als an den privaten Schlüssel eines Servers zu kommen. Darüber hinaus können Sie mit einem Sitzungsschlüssel nur die eine Session entschlüsseln, mit dem privaten Schlüssel des Servers aber alle Sessions, die auf dem Server laufen.
SSL und Forward Secrecy
SSL unterstützt Forward Secrecy mit zwei Algorithmen, die der Standard-Diffie-Hellman-Methode (DHE) und die angepasste Version zur Verwendung mit Elliptic Curve Cryptography (ECDHE).
Forward Secrecy dargestellt auf ssllabs.com
DHE ist deutlich langsamer als RSA, weshalb Website-Betreiber dazu neigen, die DHE-Suiten zugunsten der Serverleistung zu deaktivieren. Außerdem unterstützen nicht alle Browser alle notwendigen Suiten.
ECDHE ist fast so schnell wie RSA und damit derzeit die Methode der Wahl.
In der Praxis kann man, um sicher zu sein, sämtliche Kommunikation durchführen zu können, die Server so konfigurieren, dass zunächst ein handshake nach ECDHE erfolgt, wenn das nicht funktioniert, einer nach DHE und wenn der Kommunikationspartner (die anfragende Website) das auch nicht beherrscht, RSA. Sicherheitsbewusste Webmaster verzichten allerdings darauf, auch RSA zu akzeptieren. Da nur veraltete Systeme weder DHE- noch ECDHE-Verfahren unterstützen, sollte hier Konsequenz walten.
