Mit Keyless SSL können Organisationen, die ihre privaten Schlüssel nicht mit anderen teilen dürfen, in die Cloud wechseln und dabei die SSL/TLS-Verschlüsselung beibehalten.
Nach Lektüre dieses Artikels können Sie Folgendes:
Link zum Artikel kopieren
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.
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.
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.
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.
Bei einem RSA-Handshake sind die Schritte zur Erstellung von Sitzungsschlüsseln bei einem TLS-Handshake wie folgt:
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.
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.
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.
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.
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.
Vertrieb
Über SSL/TLS
Navigation Infocenter