Wie funktioniert Keyless SSL?

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 Authentifizierung des Servers des Anbieters zu verwenden, leitet der Cloud-Anbieter zu diesem Zweck Daten an den Server des Unternehmens weiter und empfängt Daten von ihm. Diese Kommunikation erfolgt über einen sicheren, verschlüsselten Kanal. Es wird also immer noch ein privater Schlüssel verwendet, der jedoch nicht an Personen außerhalb des Unternehmens weitergegeben wird.

Nehmen wir zum Beispiel an, dass die Acme Co. TLS implementiert. Die Firma speichert ihren privaten Schlüssel sicher auf einem eigenen Server, den sie kontrolliert. Wenn Acme Co. in die Cloud wechselt und einen Cloud-Service-Provider für das Web-Hosting nutzt, wird dieser Anbieter den privaten Schlüssel besitzen. Wenn Acme Co. jedoch mit einem Anbieter in die Cloud wechselt, der stattdessen Keyless SSL/TLS implementiert, kann der private Schlüssel auf dem Server verbleiben, den Acme Co. besitzt und kontrolliert – wie bei der Nicht-Cloud-TLS-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. Keyless SSL funktioniert, indem die Schritte des TLS-Handshakes geografisch aufgeteilt werden. 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 Signieren 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 entschlüsselt oder signiert die Daten auf dem Server des Kunden, der Server des Kunden sendet die Daten zurück an den Server des Anbieters, und der TLS-Handshake wird wie üblich fortgesetzt.

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.

Wie funktioniert Keyless SSL mit einem TLS-Handshake mit RSA-Schlüsselaustausch?

Bei einem RSA-Handshake laufen die Schritte eines TLS-Handshake wie folgt ab:

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 Sitzungsschlüssel 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.

Wie funktioniert Keyless SSL mit einem TLS-Handshake mit RSA-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. Es enthält auch eine digitale Signatur zur Authentifizierung. 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 prüft die digitale Signatur des Servers 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 hier kommt Keyless SSL ins Spiel. An diesem Punkt sendet der SSL/TLS-Anbieter den Client-Random, den Server-Random und den DH-Parameter des Servers an den vom Kunden kontrollierten Server, der über den privaten Schlüssel verfügt. Diese Informationen werden zur Erstellung der digitalen Signatur des Servers verwendet und an den Cloud-Anbieter zurückgeschickt, der sie an den Kunden weitergibt. Der Client ist in der Lage, diese Signatur mit dem öffentlichen Schlüssel zu verifizieren, 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 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 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 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 ermitteln, 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 (sowie auch TLS 1.3 Handshakes), sodass Unternehmen Forward Secrecy 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.