Verschlüsselung mit Perfect Forward Secrecy Geheimhaltung auf Kosten der Rechenleistung?
30. Januar 2018
In der IT-Sicherheit ist Verschlüsselung nichts Neues mehr. Heute sind vor allem Datenübertragungen per HTTPS-Verschlüsselung gängig. Aktuelle Untersuchungen zeigen, dass beinahe 70 Prozent des Traffics bereits verschlüsselt sind. Davon nutzen wiederum 86 Prozent fortschrittlichere Verschlüsselungsverfahren wie Elliptische Kurven-Kryptografie (Elliptical Curve Cryptography, ECC) oder Perfect Forward Secrecy (PFS). Im Gegensatz zu den aktuell gängigen Varianten bietet die PFS-Verschlüsselung einen zusätzlichen Schutz vor einer nachträglichen Entschlüsselung von Cyber-Kriminellen oder auch Behörden wie der NSA.
Schlüsselaustausch
Einzigartig macht die PFS-Lösung der Schlüsselaustausch zwischen Browser und Server. Bei anderen Verfahren werden die geheimen Sitzungsschlüssel in einer codierten Form bei der Datenübertragung mitgesendet. Wenn diese Codes von Kriminellen abgegriffen werden, können sie auch im Nachhinein entschlüsselt werden.
Bei PFS läuft der Schlüsselaustausch anders ab. Im sogenannten Diffie-Hellmann-Verfahren (DH) werden bei jedem neuen Verbindungsaufbau neue Zufallszahlen genutzt. Der Schlüssel wird nach der Datenübertragung direkt gelöscht. So ist also keine Entschlüsselung mehr möglich, selbst, wenn man den Code zur Entschlüsselung kennt. Nur ein aktiver Man-in-the-Middle, der die Kommunikation live manipuliert und etwa beiden Endpunkten seinen eigenen Sitzungsschlüssel aufzwingt, könnte alle Daten nach wie vor mitlesen.
Für den Einsatz von PFS müssen sowohl Server als auch Client diese Art der SSL-Verschlüsselung unterstützen. Dies ist bei den aktuellen Versionen der gängigen Browser und Mail-Programme Client-seitig bereits der Fall. Serverseitig bieten ebenfalls alle gängigen SSL-Libraries wie Microsofts SChannel, OpenSSL oder GnuTLS Unterstützung für PFS an. Voraussetzung hierfür ist allerdings ein aktuelles Betriebssystem. Die Library OpenSSL unterstützt beispielsweise PFS erst ab Version 1.0, welche nicht auf älteren Betriebssystemen verfügbar ist.
PFS kann in der Konfiguration des entsprechenden Dienstes aktiviert werden, sofern der Server über eine passende SSL-Library verfügt. Mit Hilfe des flexiblen Verbindungsaufbaus von SSL ist es außerdem möglich, den Dienst auch weiterhin für ältere Clients, die PFS nicht nutzen können, anzubieten. Zu Beginn der Verbindung handeln Server und Client bei korrekter Konfiguration dann die stärksten Verschlüsselungsalgorithmen selbstständig aus.
Der große Vorteil des PFS-Verfahrens ist, dass eigentlich zwei Verschlüsselungsverfahren zum Einsatz kommen. Erst wird eine asymmetrische Verschlüsselung mit einem Schlüsselpaar aus geheimem und öffentlichem Schlüssel und im Anschluss eine symmetrische Verschlüsselung mit einem geheimen Sitzungsschlüssel durchgeführt. Aktuell bieten mehrere Schlüsselaustauschverfahren eine Perfect Forward Secrecy-Verschlüsselung. Erkennbar ist die Verschlüsselung an den Kürzeln DHE_* und ECDHE_* (Elliptic Curve Diffie-Hellman Exchange). Das Kürzel RSA dagegen bezeichnet beispielsweise ein HTTPS-Verfahren ohne PFS.
Was spricht gegen PFS?
Bisher gibt es noch nicht sehr viele Unternehmen, die eine PFS-Verschlüsselung im Einsatz haben, weil diese mehr Zeit und mehr Ressourcen benötigt. PFS ist sehr aufwendig und rechenintensiv für Server oder Application Delivery Controllers (ADCs), da es für die ständige Erneuerung der SSL-Schlüssel entwickelt wurde. Aufgrund der notwendigen zusätzlichen Kommunikation dauert das Verfahren aber deutlich länger als beispielsweise RSA. Server-Betreiber müssen mit etwa 15 bis 30 Prozent Overhead rechnen, teilweise sogar noch deutlich mehr.
Immer größere Schlüssel (1k, 2k, 4k …) erhöhen zusätzlich den Rechenaufwand. Vor allem bei Online-Shopping-Seiten kann dies zu längeren Ladezeiten führen. Auch wenn dies nur der Bruchteil einer Sekunde wäre, könnte die Verzögerung bereits zu einem negativen Einkaufserlebnis führen. Ein Dilemma zwischen Sicherheit und Performance zeichnet sich also ab, bei dem eigentlich keiner der beiden Faktoren einem Kompromiss unterworfen werden darf.
Für einen ersten Schutz des Datenverkehrs greifen daher viele zunächst zur SSL-Verschlüsselung, sodass auch sensible Daten privat ausgetauscht werden können. Allerdings ist auch SSL rechenintensiv und Server bzw. ADCs brauchen mehr Kapazitäten pro Verbindung. Zusätzlich steigt der verschlüsselte Datenverkehr immer weiter an. Standard SSL-Chips, die in den meisten Geräten verbaut sind, berechnen lediglich RSA-Ciphers, jedoch keine ECDHE.
Diese rechenintensiven Verschlüsselungen müssen dann von nicht optimierten internen CPUs bewältigt werden. Nur wenige Hersteller reagieren bislang zeitgerecht auf das Thema SSL mit besseren SSL-Beschleunigerkarten. Da SSL-Lösungen nur selten als Hardware bereitgestellt werden, kann man das Problem auch selten mit dem einfachen Austausch einer SSL-Karte lösen, um den schnell wachsenden Anforderungen gerecht zu werden.
Das SSL-Protokoll sichert die Übertragung zwischen einer Domain auf einem Webserver und dem Besucher dieser Domain. Das heißt, dass sich der Kunde eines Online-Shops zwar sicher sein kann, dass seine Kontodaten auf dem Weg von seinem Rechner zum Server des Online-Händlers geschützt sind – was allerdings danach mit den übertragenen Daten passiert, ist ungewiss. Denn jenseits des SSL-Protokolls sind diese Daten nicht mehr automatisch gesichert, es sei denn, der Online-Händler hat entsprechende Vorkehrungen getroffen. Es ist bereits wiederholt vorgekommen, dass Online-Händler die übertragenen Daten auf ungesicherten Servern gespeichert haben. Diese sind für Hacker ein einfaches Ziel.
Cyber-Angriffe trotz SSL
Cyber-Angriffe können allerdings auch durch eine SSL-Verschlüsselung unentdeckt bleiben. Denn versteckt im verschlüsselten Datenverkehr können sich Schadprogramme unbemerkt an Firewalls, Intrusion-Prevention-Systemen (IPS) oder UTM-Gateways vorbeischleichen. Hacker binden den Schadcode in völlig vertrauenswürdige Webseiten ein und umgehen die Sicherheitsfunktionen moderner Browser. Sie nutzen außerdem SSL-Verschlüsselung, um die Infektion von Endgeräten und das Abgreifen von Daten oder auch die Command-and-Control-Kommunikation von Botnets zu verschleiern.
Um diese Angriffe und Malware zu entdecken, gibt es verschiedene Möglichkeiten der Ver- und Entschlüsselung. Ähnlich wie beim Einsatz von PFS-Zertifikaten beansprucht die Untersuchung von SSL-verschlüsseltem Datenverkehr sehr viel Rechenleistung, was häufig die Performance ausbremst. Aus diesem Grund missachten viele Unternehmen die SSL-Inspektion und setzen Anwender somit möglichen Gefahren aus.
Neben der vermehrten Einsicht der Notwendigkeit von Verschlüsselung wird auch die freiwillige Nutzung aktiv vorangetrieben. So erhalten verschlüsselte Webseiten beispielsweise bessere Page-Rankings bei der Google-Suche. Auch Apple hat bekanntgegeben, ab 2017 nur noch Apps im Apple Store zuzulassen, die eine Kommunikation über TLS 1.2 in Verbindung mit PFS in Apple Transport Security (ATS) unterstützen.
Wenn sich Unternehmen also überhaupt nicht mit den Chancen und Herausforderungen von verschlüsseltem Traffic befassen, kann sich das ebenso direkt auf deren Umsatz auswirken. Das Bundesamt für Sicherheit der Informationstechnik (BSI) hatte bereits im Oktober 2013 eine TLS 1.2 in Verbindung mit PFS als Mindeststandard für Behörden empfohlen.
IT-Entscheidungsträger müssen umdenken. Der Anteil an verschlüsseltem Datenverkehr hat sich in den letzten drei Jahren verdoppelt und damit nehmen auch die Risiken zu, über verschlüsselte Kommunikation angegriffen zu werden. Es ist viel effektiver, strategisch vorzugehen und die vorhandenen Sicherheitslösungen um Produkte zu erweitern, die diese verschlüsselte Kommunikation wieder sichtbar und damit auch untersuch- und regelbar machen. Vor Cyber-Angriffen kann man sich nie hundertprozentig schützen, aber man kann vorbereitet sein und seinen Schutz regelmäßig mit dem Stand der Zeit modernisieren, um es den Angreifern so schwer wie möglich zu machen.
Heiko Frank
ist Senior System Engineer bei A10 Networks.
