CDN SSL/TLS | CDN-Sicherheit

Welche Sicherheitsrisiken bestehen für ein CDN?

Wie alle über das Internet zugänglichen Netzwerke müssen CDNs gegen On-Path-Angriffe, Datenschutzverletzungen und Versuche, das Netzwerk des anvisierten Ursprungsservers mithilfe von DDoS-Angriffen zu überlasten, abgesichert werden. Es kann bei einem CDN mehrere Strategien gegen Schwachstellen geben, zum Beispiel die richtige SSL/TLS-Verschlüsselung und spezialisierte Verschlüsselungs-Hardware.

Was ist SSL/TLS-Verschlüsselung?

Transport Layer Security (TLS) ist ein Protokoll zum Verschlüsseln von Daten, die über das Internet gesendet werden. Das TLS-Protokoll ist aus dem Secure Sockets Layer (SSL), dem ersten verbreiteten Webverschlüsselungsprotokoll, hervorgegangen und behebt die meisten Sicherheitslücken dieses älteren Protokolls. Aus historischen Gründen werden die Begriffe in der Branche oft immer noch synonym verwendet. Bei jeder Website, die mit „https://“ beginnt und nicht mit „http://“, wird die Kommunikation zwischen Browser und Server mit TLS/SSL verschlüsselt.

Proper encryption practices are a necessity in order to prevent attackers from accessing important data. Because the Internet is designed in such a way that data is transferred across many locations, it is possible to intercept packets of important information as they move across the globe. Through the utilization of a cryptographic protocol, only the intended recipient is able to decode and read the information and intermediaries are prevented from decoding the contents of the transferred data.

Das TLS-Protokoll zielt auf drei Funktionen ab:

1. Authentifizierung – Die Möglichkeit, die angegebenen Identifikationsdaten auf ihre Gültigkeit zu überprüfen
2. Verschlüsselung – Die Möglichkeit, Informationen unkenntlich zu machen, die von einem Host an einen anderen gesendet werden
3. Integrität – Die Möglichkeit, Fälschungen und Manipulationen zu erkennen

Was ist ein SSL-Zertifikat?

Für den Einsatz von TLS benötigt eine Website ein SSL-Zertifikat und einen entsprechenden Schlüssel. Zertifikate sind Dateien mit Informationen über den Eigentümer einer Website und mit dem öffentlichen Teil eines asymmetrischen Schlüsselpaars. Bei einer Zertifizierungsstelle (Certificate Authority – CA) wird das Zertifikat digital signiert und damit bestätigt, dass die Informationen im Zertifikat korrekt sind. Wenn Sie dem Zertifikat vertrauen, vertrauen Sie darauf, dass die Zertifizierungsstelle dies mit der gebotenen Sorgfalt überprüft hat.

Betriebssysteme und Browser führen normalerweise eine Liste von Zertifizierungsstellen, denen sie implizit vertrauen. Wenn eine Website ein Zertifikat vorlegt, das von einer nicht vertrauenswürdigen Zertifizierungsstelle signiert wurde, warnt der Browser den Besucher, dass etwas faul sein könnte.

Zertifikate und die Art ihrer Implementierung können auch unabhängig nach ihrer Stärke, Protokollunterstützung und anderen Merkmalen bewertet werden. Bewertungen können sich im Laufe der Zeit ändern, wenn neuere, bessere Implementierungen verfügbar sind oder andere Faktoren dazu führen, dass die Implementierung einer Zertifizierung insgesamt weniger sicher erscheint. Ein Ursprungsserver mit einer älteren SSL-Sicherheitsimplementierung minderer Qualität wird normalerweise schlechter bewertet und ist möglicherweise anfällig für Kompromittierungen.

Ein CDN bietet den Besuchern von Websites, die in seinem Netzwerk gehostet werden, durch das ihm bereitgestellte Zertifikat zusätzliche Sicherheit. Da die Besucher nur eine Verbindung zum CDN herstellen, führt die Verwendung eines älteren oder weniger sicheren Zertifikats von Ursprungsserver und CDN nicht zu schlechteren Client-seitigen Erfahrungen.

Diese geringere Sicherheit beim Austausch zwischen Ursprungsserver und Edge-Server stellt allerdings bei genauer Betrachtung immer noch ein Risiko dar und sollte deshalb vermieden werden, zumal es ganz einfach ist, durch kostenlose Verschlüsselung des Ursprungsservers für mehr Sicherheit zu sorgen.

Echte Sicherheit ist auch für die „organische“ Suche wichtig. Verschlüsselte Websites werden in der Google-Suche besser bewertet.

Eine SSL/TLS-Verbindung funktioniert anders als eine herkömmliche TCP/IP-Verbindung. Nach den ersten Phasen des TCP-Verbindungsaufbaus wird in einem separaten Austausch die sichere Verbindung eingerichtet. In diesem Artikel werden wir das Gerät, das die sichere Verbindung anfordert, als Client bezeichnen, und das Gerät, das die sichere Verbindung bereitstellt, als Server. So würde es sich bei einem Nutzer darstellen, der eine mit SSL/TLS verschlüsselte Webseite lädt.

Zuerst erfolgt in drei Schritten der TCP/IP-Handshake:

1. Der Client sendet ein SYN-Paket an den Server, um die Verbindung herzustellen.
2. Der Server antwortet dann auf dieses erste Paket mit einem SYN/ACK-Paket, um die Kommunikation zu bestätigen.
3. Schließlich gibt der Client ein ACK-Paket zurück, um wiederum den Empfang des Pakets vom Server zu bestätigen. Nach Abschluss dieser Sequenz ist die TCP-Verbindung offen, sodass darüber nun Daten gesendet und empfangen werden können.

Nach dem TCP/IP-Handshake folgt der Handshake für die TLS-Verschlüsselung. Eine detaillierte Beschreibung der TLS-Handshake-Implementierung würde den Rahmen dieses Artikels sprengen. Wir wollen uns stattdessen mit dem Kernzweck des Handshakes befassen und untersuchen, wie lange dieser Prozess dauert.

Vereinfachend gesagt besteht ein TLS-Handshake im Wesentlichen aus drei Vorgängen:

1. Client und Server stimmen die TLS-Versionen und die Art der kryptografischen Chiffre für die Kommunikation untereinander ab.
2. Client und Server ergreifen Maßnahmen, um eine gegenseitig authentische Kommunikation zu gewährleisten.
3. Für zukünftige verschlüsselte Kommunikation wird ein Schlüssel ausgetauscht.

Die folgende Abbildung zeigt alle Schritte eines TCP/IP-Handshakes und eines TLS-Handshakes. Jeder Pfeil steht dabei für eine separate Kommunikation, die physisch zwischen Client und Server übertragen werden muss. Bei TLS-Verschlüsselung nimmt die Gesamtzahl der Nachrichten in beide Richtungen zu, womit sich auch die Ladezeiten für Webseiten verlängern.

Zur Veranschaulichung kann man davon ausgehen, dass der TCP-Handshake ungefähr 50 ms dauert und der TLS-Handshake etwa 110 ms in Anspruch nimmt. Die meiste Zeit entfällt dabei auf das Hin- und Hersenden von Daten zwischen Client und Server. Mit dem Begriff der Paketumlaufzeit (Round-Trip Time – RTT), also der Zeit für die Übertragung von Informationen von einem Gerät zum anderen und wieder zurück, kann quantifiziert werden, wie „teuer“ der Aufbau einer Verbindung ist. Ohne Optimierung und ohne ein CDN bedeutet eine längere RTT eine Erhöhung der Latenz und der Ladezeiten für Endnutzer. Glücklicherweise kann man durch Optimierungen die Gesamtladezeit verkürzen und die Anzahl der ausgetauschten Nachrichten verringern.

Wie kann man die SSL-Latenz senken?

Mit SSL-Optimierungen lässt sich die RTT reduzieren und die Seitenladedauer verbessern. Hier drei Möglichkeiten zur Optimierung einer TLS-Verbindung:

Wiederaufnahme der TLS-Sitzung – Ein CDN kann eine Verbindung zwischen dem Ursprungsserver und dem CDN-Netzwerk für längere Zeit aufrechterhalten. Die Sitzung wird bei weiteren Anfragen dann wieder aufgenommen. Die Aufrechterhaltung der Verbindung spart die Zeit für das neuerliche Aushandeln der Verbindung zwischen CDN und Ursprungsserver, wenn der Client etwas vom Ursprungsserver abruft, das nicht im Cache liegt. Solange der Ursprungsserver weitere Anfragen erhält, während die Verbindung zum CDN aufrechterhalten wird, ist die Latenz für weitere Besucher der Website geringer.

Die Gesamtkosten für die Wiederaufnahme einer Sitzung betragen weniger als 50 % eines vollständigen TLS-Handshakes. Das liegt vor allem daran, dass die Wiederaufnahme nur einen Paketumlauf kostet, ein vollständiger TLS-Handshake dagegen zwei. Darüber hinaus erfordert eine Sitzungswiederaufnahme (im Gegensatz zu neuen Sitzungen) keine großen Berechnungen über endliche Körper, sodass die CPU-Kosten für den Client im Vergleich zu einem vollständigen TLS-Handshake nahezu vernachlässigbar sind. Für Mobilnutzer bedeutet die Performanceverbesserung durch Wiederaufnahme der Sitzung ein viel reaktionsfreudigeres und akkuschonenderes Surferlebnis.

Aktivierung von TLS False Start – Wenn ein Besucher eine Website erstmals aufruft, bringt die oben erwähnte Wiederaufnahme der Sitzung keinen Nutzen. Mit TLS False Start kann der Absender ohne vollständigen TLS-Handshake Anwendungsdaten übermitteln.

Durch False Start wird nicht das TLS-Protokoll selbst verändert, sondern nur der Zeitpunkt der Datenübertragung. Sobald der Client den Schlüsselaustausch eingeleitet hat, kann die Verschlüsselung gewährleistet werden und die Datenübertragung beginnt. Mit dieser Modifikation reduziert sich die Gesamtzahl der Paketumläufe und damit die benötigte Latenz um 60 ms.

Zero Round Trip Time Resumption (0-RTT) – Durch 0-RTT (Wiederaufnahme mit einer Paketumlaufzeit von null) kann die Sitzung wieder aufgenommen werden, ohne dass zusätzliche RTT-Latenz bei der Verbindung entsteht. Wieder aufgenommene Verbindungen mit TLS 1.3 und 0-RTT bieten höhere Geschwindigkeit und damit ein schnelleres und gleichmäßigeres Web-Erlebnis bei häufig besuchten Websites. Dieser Geschwindigkeitsvorteil macht sich insbesondere in Mobilfunknetzen bemerkbar.

0-RTT is an effective improvement, but is not without some security tradeoffs. To overcome the risk of what is known as a replay attack, a CDN service may implement restriction on the type of HTTP requests and the allowed parameters. To learn more, explore an introduction to 0-RTT.

Schutz vor DDoS-Angriffen durch CDN

Eine der größten sicherheitstechnischen Schwachstellen von Websites im heutigen Internet sind DDoS-Angriffe (Distributed Denial-of-Service). Diese Attacken sind mit der Zeit umfangreicher und komplexer geworden. Dabei wird mithilfe von Botnetzen Angriffs-Traffic gebündelt und gegen Websites eingesetzt. In einem großen und richtig konfigurierten CDN kann Skalierung zum Schutz vor DDoS-Attacken beitragen. Mit genug Rechenzentrumsstandorten und beträchtlicher Bandbreitenkapazität ist ein CDN in der Lage, Angriffs-Traffic in einem Volumen zu bewältigen und zu entschärfen, das den anvisierten Ursprungsserver ansonsten schnell überlasten könnte.

Es können aber noch weitere Maßnahmen zum Schutz von TLS-Verbindungen ergriffen werden. Informieren Sie sich über das Cloudflare-CDN und halten Sie sich über TLS-Angriffe auf dem Laufenden. Im Cloudflare Diagnostic Center können Sie überprüfen, ob HTTPS auf Ihrer Website richtig eingesetzt wird.