CDN SSL/TLS | CDN-Sicherheit

Zu den CDN-Strategien zur Behebung von Schwachstellen gehören richtige SSL/TLS-Verschlüsselung und spezielle Verschlüsselungshardware. Schauen Sie sich im CDN-Leitfaden um.

Share facebook icon linkedin icon twitter icon email icon

CDN-Sicherheit

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

Welche Sicherheitsrisiken gibt es für ein CDN?

Wie alle Netzwerke, die für das Internet zugänglich sind, müssen CDNs gegen Man-in-the-Middle-Angriffe, Datenschutzverletzungen und Versuchen, 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) hervorgegangen, dem ersten verbreiteten Webverschlüsselungsprotokoll, 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 von Ihnen besuchten 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 böswillige Akteure auf wichtige Daten zugreifen. Im Internet werden Daten über viele Standorte hinweg übertragen, das liegt einfach an seiner Struktur. 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 Vermittler können den Inhalt der übertragenen Daten nicht entschlüsseln.

Das TLS-Protokoll soll drei Komponenten gewährleisten:

  1. Authentifizierung – Die Möglichkeit, die Gültigkeit der angegebenen Identifikationen 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?

Damit TLS möglich wird, braucht 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.

SSL/TLS error graphic

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 werden oder andere Faktoren dazu führen, dass die Implementierung einer Zertifizierung insgesamt weniger sicher erscheint. Ein Ursprungsserver mit einer älteren SSL-Sicherheitsimplementierung niedrigerer 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 vom CDN bereitgestellte Zertifikat zusätzliche Sicherheit. Da die Besucher nur eine Verbindung zum CDN herstellen, führt ein älteres oder weniger sicheres Zertifikat zwischen dem Ursprungsserver und dem CDN nicht zu schlechteren Erfahrungen auf der Clientseite.

SSL/TLS self-signed diagram

Bei genauer Betrachtung ist diese schwächere Sicherheit zwischen Ursprungsserver und Edge-Server allerdings immer noch ein Risiko und sollte vermieden werden, zumal es ganz einfach ist, durch kostenlose Verschlüsselung des Ursprungsservers für mehr Sicherheit zu sorgen.

SSL/TLS self-signed diagram

Richtige 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 Benutzer 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 den Empfang des Pakets vom Server zu bestätigen. Nach Abschluss dieser Sequenz des Sendens und Empfangens von Paketen ist die TCP-Verbindung offen und kann Daten senden und empfangen.
TCP 3-way handshake diagram

Nach dem TCP/IP-Handshake folgt der Handshake für die TLS-Verschlüsselung. Die 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.

Grob betrachtet besteht ein TLS-Handshake aus drei Hauptkomponenten:

  1. Client und Server stimmen die TLS-Versionen und die Art der kryptografischen Chiffre für die Kommunikation 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.

In der folgenden Abbildung sind alle Schritte eines TCP/IP-Handshakes und eines TLS-Handshakes dargestellt. Jeder Pfeil ist dabei 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, und damit auch die Ladezeiten für Webseiten.

SSL/TLS handshake diagram

Zur Veranschaulichung kann man davon ausgehen, dass der TCP-Handshake ungefähr 50 ms dauert, der TLS-Handshake ungefähr 110 ms. Den Hauptanteil daran macht die Zeit zum Hin- und Hersenden von Daten zwischen Client und Server aus. Mit dem Begriff der Umlaufzeit (round-trip time, RTT), also der Zeit für die Übertragung von Informationen von einem Gerät zum anderen und wieder zurück, quantifizieren wir, wie „teuer“ der Aufbau einer Verbindung ist. Ohne Optimierung und ohne ein CDN bedeutet längere RTT eine Erhöhung der Latenz und eine Verlängerung der Ladezeiten für Endbenutzer. Glücklicherweise kann man durch Optimierungen die Gesamtladezeit verbessern und die Anzahl der ausgetauschten Nachrichten verringern.

Wie kann man die SSL-Latenz verbessern?

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 die Neuregelung 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.

session resumption real time infographic

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 Umlauf kostet, ein vollständiger TLS-Handshake dagegen zwei. Darüber hinaus erfordert eine Sitzungswiederaufnahme keine großen Berechnungen über endliche Körper (neue Sitzungen schon), 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.

session resumption CPU time infographic

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 senden.

SSL/TLS False Start handshake diagram

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. Diese Modifikation reduziert die Gesamtzahl der Umläufe und damit die benötigte Latenz um 60 ms.


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


0-RTT ist eine wirksame Verbesserung, dafür nimmt man aber Kompromisse bei der Sicherheit in Kauf. 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.

CDN-Schutz vor DDoS-Angriffen

Eine der größten sicherheitstechnischen Schwachstellen von Websites im heutigen Internet sind DDoS-Angriffe (Distributed Denial-of-Service). DDoS-Angriffe sind mit der Zeit umfangreicher und komplexer geworden. Die Angreifer nutzen Botnetze, um Angriffs-Traffic gegen Websites zu bündeln. In einem großen und richtig konfigurierten CDN kann Skalierung ein Schutzfaktor gegen DDoS sein. Mit genug Rechenzentrumsstandorten und beträchtlicher Bandbreitenkapazität kann ein CDN Angriffs-Traffic in einem Volumen bewältigen und entschärfen, das den anvisierten Ursprungsserver schnell überlasten könnte.


Es gibt noch weitere Maßnahmen zum Schutz von TLS-Verbindungen. 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.