CDN SSL/TLS | CDN security

Zu den CDN-Strategien für die Behebung von Schwachstellen gehören richtige SSL/TLS-Verschlüsselung und spezielle Verschlüsselungshardware. Im CDN-Leitfaden finden Sie mehr darüber.

Lernziele

Nach Lektüre dieses Artikels können Sie Folgendes:

  • Verstehen, wie CDN SSL/TLS funktioniert
  • CDN-Optimierungen für SSL/TLS kennenlernen
  • Herausfinden, wie man mit einem CDN ein veraltetes SSL/TLS-Zertifikat verbessern kann
  • Erfahren, wie ein CDN DDoS-Angriffe abwehren kann

Link zum Artikel kopieren

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.

Nur durch richtige Verschlüsselungsmethoden kann man verhindern, dass Angreifer auf wichtige Daten zugreifen. Im Internet werden aufgrund der Struktur des Web Daten über viele Standorte hinweg übertragen. Deshalb können solche Pakete mit wichtigen Informationen auf ihrem Weg durch die Welt auch abgefangen werden. Aber wenn ein kryptografisches Protokoll genutzt wird, kann nur der vorgesehene Empfänger die Informationen decodieren und lesen. Die Übermittler hingegen sind nicht in der Lage, den Inhalt der übertragenen Daten zu entschlüsseln.

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.

Grafik SSL/TLS-Fehler

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.

Diagramm: SSL/TLS selbstsigniert

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.

Diagramm: SSL/TLS selbstsigniert

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.
Diagramm: Drei-Wege-Handshake bei TCP

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.

Diagramm: SSL/TLS-Handshake

For illustrative purposes it can be said the TCP handshake takes about 50ms, the TLS handshake may take about 110ms. This is largely a result of the time it takes for data to be sent both ways between the client and server. The idea of round-trip time (RTT), which is the amount of time it takes for information to travel from one device to another and back again, can be used to quantify how “expensive” a connection is to create. If left unoptimized and without the use of a CDN, additional RTT represents an increase in latency and a reduction in load time for end-users. Luckily, there are optimizations that can be made to improve total load time and reduce the number of trips back and forth.

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.

Infografik: Sitzungswiederaufnahme in Echtzeit

The overall cost of a session resumption is less than 50% of a full TLS handshake, mainly because session resumption only costs one round-trip while a full TLS handshake requires two. Additionally, a session resumption does not require any large finite field arithmetic (new sessions do), so the CPU cost for the client is almost negligible compared to that in a full TLS handshake. For mobile users, the performance improvement by session resumption means a much more reactive and battery-life-friendly surfing experience.

Infografik: Sitzungswiederaufnahme in CPU-Zeit

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.

Diagramm: SSL/TLS False Start-Handshake

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 bringt eine echte Verbesserung, dafür muss man aber Kompromisse bei der Sicherheit in Kauf nehmen. Um das Risiko eines sogenannten Replay-Angriffs auszuschließen, kann ein CDN-Dienst den Typ von HTTP-Anfragen und die zulässigen Parameter einschränken. Mehr darüber finden Sie in unserer Einführung in 0-RTT.

Schutz vor DDoS-Angriffen durch CDN

One of the most substantial security vulnerabilities of web properties on the modern Internet is the use of distributed denial-of-service (DDoS) attacks. Over time DDoS attacks have increased in size and complexity, with attackers utilizing botnets to target websites with attack traffic. A large and properly configured CDN has the potential benefit of scale as a protective factor against DDoS; by having enough data center locations and sizable bandwidth capabilities, a CDN is able to withstand and mitigate an amount of incoming attack traffic that would easily overwhelm the targeted origin server.

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.