Jetzt abonnieren, um Benachrichtigungen über neue Beiträge zu erhalten:

Einführung individueller TLS-Einstellungen für jeden Hostnamen – Sicherheit nach Maß

2023-08-09

Lesezeit: 3 Min.
Dieser Beitrag ist auch auf English, 繁體中文, Français, 日本語, 한국어, und 简体中文 verfügbar.

Zu den Zielen von Cloudflare gehört es, Kunden die Möglichkeit zu geben, IT-Sicherheit genau auf ihre Bedürfnisse zuzuschneiden. Im Bereich SSL/TLS bieten wir zwei Wege zur Kontrolle von krytographischen Schlüsseln an: die Festlegung einer Mindest-TLS-Version und die Einschränkung der Liste unterstützter Cipher Suites. Bisher galten diese Einstellungen für die gesamte Domain, es hieß also „Alles oder Nichts“. Für manche Nutzer sind einheitliche Einstellungen für die gesamte Domain ideal. Andere benötigen aufgrund unterschiedlicher Anforderungen ihrer Subdomains mehr Möglichkeiten zur Ausdifferenzierung.

Introducing per hostname TLS settings — security fit to your needs

Daher freut es uns sehr, dass unsere Kunden ab sofort für jeden einzelnen Hostnamen separate TLS-Einstellungen festlegen können.

Die Nachteile des Einsatzes moderner Protokolle

In einer idealen Welt könnte jede Domain auf die sichersten und modernsten Protokolle umgestellt werden, ohne dass dies Nachteile mit sich bringt. Die Realität sieht leider anders aus. Damit neue Standards und Protokolle funktionieren, müssen sie erst breite Akzeptanz finden. TLS 1.3 wurde im April 2018 von der IETF standardisiert. Das Protokoll hat die anfälligen kryptografischen Algorithmen überflüssig gemacht, die von TLS 1.2 unterstützt wurden, und für eine Steigerung der Performance gesorgt, weil dafür anstatt zwei Roundtrips nur noch einer erforderlich ist. Damit ein Nutzer von TLS 1.3 profitieren kann, muss sein Browser oder Gerät diese neuere TLS-Version unterstützen. Bei modernen Browsern und Geräten ist das kein Problem, weil die betreffenden Betriebssysteme so konzipiert sind, dass sie sich zur Unterstützung neuer Protokolle dynamisch aktualisieren. Doch bei älteren Clients und Geräten wurde dieser Ansatz noch nicht verfolgt. Vor 2015 hat die Entwicklung neuer Protokolle und Standards nicht Monate oder Jahre, sondern Jahrzehnte gedauert, sodass Clients mit Unterstützung für einen Standard ausgeliefert wurden – und zwar für den, der zu der betreffenden Zeit gerade genutzt wurde.

Ein Blick in Cloudflare Radar zeigt, dass bei etwa 62,9 % des Datenverkehrs TLS 1.3 verwendet wird. Das ist recht beachtlich für ein Protokoll, das erst vor fünf Jahren standardisiert wurde. Es bedeutet aber auch, dass ein großer Teil des Internets weiterhin TLS 1.2 oder noch ältere Versionen nutzt.

Die gleichen Abstriche müssen bei Verschlüsselungsalgorithmen gemacht werden. ECDSA wurde 2005 standardisiert, etwa 20 Jahre nach RSA. Der Algorithmus bietet ein höheres Maß an Sicherheit als RSA und nutzt kürzere Schlüssellängen, was bei jeder Anfrage zu einer Performancesteigerung führt. Um ECDSA verwenden zu können, muss ein Domaininhaber ein ECDSA-Zertifikat erhalten und bereitstellen. Zudem muss der verbindende Client Cipher Suites unterstützen, die Elliptische-Kurven-Kryptografie (Elliptical Curve Cryptography – ECC) verwenden. Inzwischen unterstützen die meisten vertrauenswürdigen öffentlichen Zertifizierungsstellen ECDSA-basierte Zertifikate. Doch Letztere haben sich nur langsam durchgesetzt, weshalb viele ältere Systeme ausschließlich RSA unterstützen. Somit werden bei einer Beschränkung von Anwendungen auf die Unterstützung von ECC-basierten Algorithmen unter Umständen Kunden ausgeschlossen, die ältere Clients und Geräte verwenden.

Abwägung der Vor- und Nachteile

Wenn es um Sicherheit und Zugänglichkeit geht, ist es wichtig, den richtigen Mittelweg für Ihr Unternehmen zu finden.

Um den Wiedererkennungswert ihrer Marke zu wahren, stellen die meisten Unternehmen alle ihre Ressourcen unter einer Domain bereit. Es ist üblich, dass die Stammdomain (z. B. beispiel.com) für die Marketing-Website verwendet wird, um Informationen über das Unternehmen, seine Ziele sowie die angebotenen Produkte und Dienstleistungen bereitzustellen. Unter derselben Domain können dann auch der Unternehmensblog (z. B. blog.beispiel.com), das Verwaltungsportal (z. B. dash.beispiel.com) und das API-Gateway (z. B. api.beispiel.com) angesiedelt sein.

Die Marketing-Website und der Blog sind insofern ähnlich, als es sich um statische Websites handelt, die keine Informationen von den zugreifenden Nutzern erfassen. Das Verwaltungsportal und das API-Gateway hingegen erheben und präsentieren sensible Daten, die geschützt werden müssen.

Bei der Überlegung, welche Einstellungen festgelegt werden sollten, müssen die Art der ausgetauschten Daten und der Nutzerstamm berücksichtigt werden. Die Marketing-Website und der Blog sollten für alle Nutzer zugänglich sein. Sie können so eingerichtet werden, dass sie mit modernen Protokollen für die Clients funktionieren, die sie unterstützen. Doch der Zugang sollte nicht notwendigerweise für Nutzer eingeschränkt werden, die von alten Geräten auf diese Seiten zugreifen.

Das Verwaltungsportal und das API-Gateway sollten so eingerichtet werden, dass die ausgetauschten Daten bestmöglich geschützt sind. Das bedeutet, dass die Unterstützung für weniger sichere Standards mit bekannten Schwachstellen beendet und neue, sichere Protokolle genutzt werden sollten.

Dafür müssen Sie in der Lage sein, die Einstellungen für jede Subdomain innerhalb Ihrer Domain einzeln zu konfigurieren.

Individuelle TLS-Einstellungen für jeden Hostnamen – jetzt verfügbar!

Kunden, die den Advanced Certificate Manager von Cloudflare verwenden, können TLS-Einstellungen für einzelne Hostnamen innerhalb einer Domain konfigurieren. Damit können sie HTTP/2 aktivieren oder die Mindest-TLS-Version und die unterstützten Cipher Suites für einen bestimmten Hostnamen konfigurieren. Alle Einstellungen, die auf einen bestimmten Hostnamen angewendet werden, haben Vorrang vor den Einstellungen auf Zonenebene. Mit der neuen Funktion können auch verschiedene Einstellungen für einen Hostnamen und seinen Wildcard-Eintrag festgelegt werden. Sie können also beispiel.com so konfigurieren, dass eine bestimmte Einstellung verwendet wird, und *.beispiel.com so, dass eine andere angewendet wird.

Nehmen wir an, Sie möchten, dass die standardmäßige Mindest-TLS-Version für Ihre Domain TLS 1.2 ist, aber für Ihre Dashboard- und API-Subdomains möchten Sie TLS 1.3 als Mindest-TLS-Version vorgeben. Dafür können Sie wie unten dargestellt im Cloudflare-Dashboard die Mindest-TLS-Version auf Zonenebene auf 1.2 setzen. Um dann für das Dashboard und die API-Subdomains TLS 1.3 als Mindest-TLS-Version zu bestimmen, rufen Sie den API-Endpunkt für die TLS-Einstellungen pro Hostname mit dem spezifischen Hostnamen und der Einstellung auf.

Das alles ist ab heute über den API-Endpunkt verfügbar! Mehr darüber, wie Sie unsere TLS-Einstellungen für individuelle Hostnamen verwenden können, entnehmen Sie unserer Dokumentation für Entwickler.

Wir schützen komplette Firmennetzwerke, helfen Kunden dabei, Internetanwendungen effizient zu erstellen, jede Website oder Internetanwendung zu beschleunigen, DDoS-Angriffe abzuwehren, Hacker in Schach zu halten, und unterstützen Sie bei Ihrer Umstellung auf Zero Trust.

Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.

Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen.
SicherheitSSLTLSProdukt-News

Folgen auf X

Dina Kozlov|@dinasaur_404
Cloudflare|@cloudflare

Verwandte Beiträge

24. Oktober 2024 um 13:00

Durable Objects aren't just durable, they're fast: a 10x speedup for Cloudflare Queues

Learn how we built Cloudflare Queues using our own Developer Platform and how it evolved to a geographically-distributed, horizontally-scalable architecture built on Durable Objects. Our new architecture supports over 10x more throughput and over 3x lower latency compared to the previous version....