Wie funktioniert Keyless SSL? | Forward Secrecy

Was ist Keyless SSL?

Keyless SSL ist ein Dienst für Unternehmen, die einen Cloud-Anbieter für die SSL-Verschlüsselung nutzen. Normalerweise würde dies bedeuten, dass der Cloud-Anbieter den privaten Schlüssel des Unternehmens kennen muss, aber Keyless SSL ist eine Möglichkeit, dies zu umgehen. Aus rechtlichen Gründen können viele Organisationen ihre privaten Schlüssel nicht mit anderen teilen. Mit Keyless SSL können diese Organisationen weiterhin TLS verwenden und die Cloud nutzen, während der Schlüssel sicher bleibt.

Bei SSL – genauer gesagt TLS – handelt es sich um ein Protokoll zur Authentifizierung und Verschlüsselung der Kommunikation über ein Netzwerk. SSL/TLS erfordert die Verwendung eines sogenannten öffentlichen Schlüssels und eines privaten Schlüssels. Im Falle eines Unternehmens, das das Protokoll zur Sicherung des Traffics zu und von seiner Website verwendet (siehe HTTPS), bleibt der private Schlüssel normalerweise im Besitz des Unternehmens. Wenn ein Unternehmen jedoch in die Cloud wechselt und ein Anbieter TLS-Verschlüsselung bereitstellt, verfügt der Anbieter stattdessen über den privaten Schlüssel.

Wenn der Teil des Handshakes, der den privaten Schlüssel beinhaltet, nicht mehr auf dem Server des Anbieters stattfindet, kann der private Schlüssel sicher im Besitz des Unternehmens bleiben. Anstatt den privaten Schlüssel direkt zur Generierung von Sitzungsschlüsseln zu verwenden, erhält der Cloud-Anbieter die Sitzungsschlüssel vom Unternehmen über einen sicheren Kanal und verwendet diese Schlüssel zur Aufrechterhaltung der Verschlüsselung. Ein privater Schlüssel wird also nach wie vor verwendet, er wird jedoch nicht mit Dritten außerhalb des Unternehmens geteilt.

Nehmen wir zum Beispiel an, dass Acme Co. SSL implementiert. Acme Co. speichert seinen privaten Schlüssel sicher auf einem Server, den es besitzt und kontrolliert. Wenn Acme Co. in die Cloud wechselt und einen Cloud-Anbieter für das Web-Hosting verwendet, erhält dieser Anbieter den privaten Schlüssel. Wenn Acme Co. jedoch mit einem Anbieter in die Cloud wechselt, der stattdessen Keyless SSL implementiert, kann der private Schlüssel auf dem Server verbleiben, den Acme Co. besitzt und kontrolliert – wie bei der Nicht-Cloud-SSL-Implementierung.

Wie funktioniert Keyless SSL?

Keyless SSL basiert auf der Tatsache, dass der private Schlüssel nur einmal während des TLS-Handshakes verwendet wird, nämlich zu Beginn einer TLS-Kommunikationssitzung. Bei Keyless SSL werden die Schritte des TLS-Handshakes aufgeteilt. Ein Cloud-Anbieter, der Keyless SSL anbietet, verschiebt den Teil des Prozesses mit dem privaten Schlüssel auf einen anderen Server, in der Regel einen Server, den der Kunde bei sich vor Ort betreibt.

Wenn der private Schlüssel während des Handshakes zum Entschlüsseln oder Verschlüsseln von Daten erforderlich wird, leitet der Server des Anbieters die erforderlichen Daten an den Server mit dem privaten Schlüssel des Kunden weiter. Der private Schlüssel verschlüsselt oder entschlüsselt die Daten auf dem Server des Kunden und sendet die Daten zurück an den Server des Anbieters, woraufhin der TLS-Handshake wie üblich fortgesetzt wird.

Keyless SSL ist nur aus der Sicht des Cloud-Anbieters „schlüssellos“: Er sieht den privaten Schlüssel seines Kunden nie, aber der Kunde hat und benutzt ihn trotzdem. Gleichzeitig wird der öffentliche Schlüssel auf der Client-Seite wie gewohnt verwendet.

Was ist ein Sitzungsschlüssel?

Ein Sitzungsschlüssel ist ein symmetrischer Schlüssel, der von beiden Seiten bei einer sicheren Kommunikation über TLS verwendet wird, nachdem der TLS-Handshake abgeschlossen ist. Sobald sich die beiden Seiten auf einen Satz von Sitzungsschlüsseln geeinigt haben, besteht keine Notwendigkeit mehr, die öffentlichen und privaten Schlüssel zu verwenden. TLS generiert für jede einzelne Sitzung unterschiedliche Sitzungsschlüssel.

Was sind die Schritte zur Generierung von Sitzungsschlüsseln?

Es hängt davon ab, welche Art von Schlüsselaustausch-Algorithmus beim TLS-Handshake verwendet wird. Die beiden wichtigsten sind der RSA-Schlüsselaustausch-Algorithmus und der Ephemeral Diffie-Hellman-Schlüsselaustausch-Algorithmus.

Der RSA-Schlüsselaustausch

Bei einem RSA-Handshake sind die Schritte zur Erstellung von Sitzungsschlüsseln bei einem TLS-Handshake wie folgt:

1. Der Client sendet dem Server eine „Hello“-Klartextnachricht, die die gewünschte Protokollversion, eine Liste der unterstützten Verschlüsselungs-Suites und eine kurze Folge von Zufallsdaten, die als „Client-Random“ bezeichnet wird, enthält.
2. Der Server antwortet (in Klartext) mit seinem SSL-Zertifikat, seiner bevorzugten Verschlüsselungs-Suite und einer anderen kurzen Folge von Zufallsdaten, dem sogenannten „Server-Random“.
3. Der Client erstellt einen weiteren zufälligen Datensatz, das sogenannte „Premaster-Secret“. Der Client verschlüsselt das Premaster-Secret mit dem öffentlichen Schlüssel aus dem SSL-Zertifikat des Servers und sendet es an den Server. Nur jemand, der den privaten Schlüssel besitzt, kann das Premaster-Secret entschlüsseln.
4. Der Server entschlüsselt das Premaster-Secret. Beachten Sie, dass dies das einzige Mal ist, dass der private Schlüssel verwendet wird!
5. Nun besitzen sowohl Client als auch Server das Client-Random, das Server-Random und das Premaster-Secret. Unabhängig voneinander kombinieren sie diese drei Eingaben, um die Sitzungsschlüssel zu erstellen. Sie sollten beide zum gleichen Ergebnis kommen, und alle nachfolgenden Kommunikationen während der Sitzung werden mit diesen neuen Schlüsseln verschlüsselt.

Keyless SSL kommt in Schritt 4 ins Spiel. Bei Keyless SSL entschlüsselt der Cloud-Anbieter das Premaster-Secret nicht selbst, sondern sendet es in verschlüsselter Form über einen sicheren Kanal an einen Server, den der Kunde hostet oder kontrolliert. Der private Schlüssel des Kunden entschlüsselt das Premaster-Secret, woraufhin das entschlüsselte Premaster-Secret an den Cloud-Anbieter zurückgeschickt wird. Der Server des Cloud-Anbieters leitet daraus die Sitzungsschlüssel ab, und die TLS-Kommunikation wird wie gewohnt fortgesetzt.

Der Ephemeral Diffie-Hellman-Schlüsselaustausch

Ein Ephemeral Diffie-Hellman-Handshake (DHE-Handshake) („ephemeral“/„kurzlebig“, weil ein und derselbe Schlüssel nie zweimal verwendet wird) erzeugt Sitzungsschlüssel unter Verwendung des Diffie-Hellman-Algorithmus, einer Methode zum Austausch von Schlüsseln über einen unsicheren Kanal. Bei dieser Art von TLS-Handshake ist die Authentifizierung mit privatem Schlüssel ein von der Generierung der Sitzungsschlüssel getrennter Prozess.

Der Hauptunterschied zwischen dem DHE-Handshake und einem RSA-Handshake besteht, abgesehen von den verwendeten Algorithmen, darin, wie das Premaster-Secret erzeugt wird. Bei einem RSA-Handshake besteht das Premaster-Secret aus zufälligen Daten, die vom Client generiert werden; bei einem DHE-Handshake verwenden der Client und der Server vereinbarte Parameter, um dasselbe Premaster-Secret getrennt zu berechnen.

1. Wie bei einem RSA-Handshake sendet der Client die gewünschte Protokollversion, eine Liste der unterstützten Verschlüsselungs-Suiten und das Client-Random.
2. Der Server antwortet mit der von ihm gewählten Verschlüsselungs-Suite, einem Server-Random und seinem SSL-Zertifikat. Hier beginnt sich der DHE-Handshake von einem RSA-Handshake zu unterscheiden: Der Server sendet auch seinen Diffie-Hellman-Parameter (DH-Parameter), der zur Berechnung des Premaster-Secrets verwendet wird. Er verschlüsselt auch das Client-Random, das Server-Random und den DH-Parameter mit dem privaten Schlüssel des Servers. Dies ist das einzige Mal, dass der private Schlüssel verwendet wird, und er authentifiziert, dass der Server derjenige ist, der er vorgibt zu sein.
3. Der Client entschlüsselt die Nachricht des Servers mit dem öffentlichen Schlüssel und authentifiziert das SSL-Zertifikat. Der Client antwortet dann mit seinem DH-Parameter.
4. Unter Verwendung des DH-Parameters des Clients und des DH-Parameters des Servers berechnen beide Parteien das Premaster-Secret getrennt voneinander.
5. Sie kombinieren dann dieses Premaster-Secret mit dem Client-Random und dem Server-Random, um die Sitzungsschlüssel zu erhalten.

Der private Schlüssel wird nur in Schritt 2 verwendet, und an dieser Stelle wird Keyless SSL relevant. Zu diesem Zeitpunkt sendet der SSL/TLS-Anbieter das Client-Random, das Server-Random und den DH-Parameter des Servers an den vom Kunden kontrollierten Server, der den privaten Schlüssel besitzt. Diese Informationen werden mit dem privaten Schlüssel verschlüsselt und in verschlüsselter Form an den Cloud-Anbieter zurückgeschickt, der sie an den Client weitergibt. Der Client ist in der Lage, diese Daten mit dem öffentlichen Schlüssel zu entschlüsseln, und der Handshake wird fortgesetzt. Auf diese Weise muss der Cloud-Anbieter den privaten Schlüssel nicht berühren.

Ephemeral Diffie-Hellman-Handshakes dauern zwar etwas länger als RSA-Handshakes, haben aber den Vorteil der sogenannten Forward Secrecy. Da der private Schlüssel nur zur Authentifizierung verwendet wird, kann ein Angreifer ihn nicht verwenden, um einen bestimmten Sitzungsschlüssel zu ermitteln.

Was ist Forward Secrecy? Was ist Perfect Forward Secrecy?

Forward Secrecy („vorwärts gerichtete Geheimhaltung“) stellt sicher, dass verschlüsselte Daten auch dann verschlüsselt bleiben, wenn der private Schlüssel offengelegt wird. Dies wird auch als „Perfect Forward Secrecy“ bezeichnet. Forward Secrecy ist möglich, wenn für jede Kommunikationssitzung ein eindeutiger Sitzungsschlüssel verwendet wird und wenn der Sitzungsschlüssel getrennt vom privaten Schlüssel generiert wird. Wenn ein einzelner Sitzungsschlüssel kompromittiert wird, kann nur diese Sitzung von einem Angreifer entschlüsselt werden; alle anderen Sitzungen bleiben verschlüsselt.

In einem Protokoll, das für Forward Secrecy eingerichtet wurde, wird der private Schlüssel während eines anfänglichen Handshake-Prozesses zur Authentifizierung verwendet, ansonsten wird er nicht zur Verschlüsselung genutzt. Der Ephemeral Diffie-Hellman-Handshake generiert Sitzungsschlüssel getrennt vom privaten Schlüssel und besitzt daher Forward Secrecy.

Im Gegensatz dazu hat RSA keine Forward Secrecy: Mit dem kompromittierten privaten Schlüssel könnte ein Angreifer Sitzungsschlüssel für vergangene Konversationen entschlüsseln, weil er das Premaster-Secret entschlüsseln kann und die Client-Randoms und Server-Randoms im Klartext vorliegen. Durch Kombination dieser drei Elemente kann der Angreifer jeden beliebigen Sitzungsschlüssel ableiten.

Wie implementiert Cloudflare Keyless SSL?

Cloudflare war der erste Cloud-Anbieter, der Keyless SSL eingeführt hat, wodurch Unternehmen, die strengen Sicherheitsbeschränkungen unterliegen, wie z. B. Banken, in die Cloud wechseln konnten. Cloudflare unterstützt sowohl RSA- als auch Diffie-Hellman-Handshakes, sodass Unternehmen die Forward Secrecy über Diffie-Hellman integrieren können, um sich vor der Möglichkeit zu schützen, dass ein Angreifer ihre Daten nach dem Diebstahl ihres privaten Schlüssels entschlüsselt.

Die gesamte Kommunikation zwischen den Cloudflare-Servern und den Servern mit den privaten Schlüsseln findet über einen sicheren, verschlüsselten Kanal statt. Darüber hinaus hat Cloudflare herausgefunden, dass Keyless SSL trotz der zusätzlichen Fahrten zum privaten Schlüsselserver eine vernachlässigbare Auswirkung auf die Performance hat.

Weitere technische Details zur Funktionsweise von Keyless SSL finden Sie in diesem Blogbeitrag. Mehr Informationen über Keyless SSL von Cloudflare finden Sie in den Erläuterungen unseres Keyless SSL-Dienstes.