TSL-Verschlüsselung: Warum größer nicht zwangsläufig besser ist | Fastly

Das Konfigurieren von TLS kann einige komplexe Entscheidungen beinhalten. Dies trifft sicherlich auf die Größe (Anzahl der Bits) der in Serverzertifikaten verwendeten Verschlüsselungsschlüssel zu. Es mag klug erscheinen, einen 4096-Bit-RSA-Schlüssel anstatt der typischen 2048-Bit-Variante zu wählen, insbesondere wenn es darum geht, Daten, die heute verschlüsselt werden, für sehr viele Jahre zu schützen. Um zu erklären, warum diese Entscheidung nicht so einfach ist, müssen wir uns die Funktion des TLS-Zertifikats und die von TLS angewendeten kryptografischen Abläufe näher ansehen. Legen wir los.

In allen Versionen des TLS-Protokolls spielt das Zertifikat eine ganz bestimmte Rolle: Es wird bei der Validierung des Hostnamens der Website verwendet und ermöglicht die Erstellung eines Sitzungsschlüssels, der zum Schutz der Daten im Transit verwendet wird. Das bedeutet, dass die Stärke des Sitzungsschlüssels für den Schutz Ihrer Daten mindestens genauso wichtig ist wie der Schlüssel des Zertifikats.

Die Stärke des Sitzungsschlüssels wird durch die „Cipher Suite“ bestimmt, die beim Aufbau einer TLS-Verbindung zwischen dem Browser und dem Webserver vereinbart wird. Die Cipher Suite legt auch die Methode fest, mit der der Sitzungsschlüssel erstellt wird. „Forward Secrecy“ (FS) ist eine Eigenschaft moderner Schlüsselvereinbarungsmechanismen, die sicherstellt, dass der persönliche Schlüssel des Zertifikats nicht zur Wiederherstellung der Sitzungsschlüssel verwendet werden kann. Wenn ein Schlüsselvereinbarungsmechanismus mit FS verwendet wird, kann ein kompromittierter Schlüssel im Zertifikat nicht verwendet werden, um alte Sitzungsschlüssel wiederherzustellen. Selbst wenn die verschlüsselten TLS-Daten lange gespeichert werden, können die Daten durch das Knacken des Zertifikatsschlüssels nicht kompromittiert werden. Kurz gesagt, eine Kompromittierung Ihres Webservers macht es dem Angreifer nicht möglich, TLS-Traffic zu entschlüsseln, der vor der Kompromittierung gesendet wurde. 

Das Fastly CDN ist standardmäßig so konfiguriert, dass es FS verwendet, wenn der Browser es unterstützt. Kunden können FS sicherstellen, indem sie verlangen, dass Verbindungen TLS 1.3 verwenden, die neueste Version des Protokolls, die nur FS-Cipher-Suites zulässt, oder indem sie eine nutzerdefinierte TLS-Konfiguration anfordern.

Das „National Institute of Standards and Technology“ (NIST) veröffentlicht in regelmäßigen Abständen Empfehlungen für die Verwendung von kryptografischen Algorithmen. Diese legen den jeweiligen Schutz, den die verschiedenen Arten von Algorithmen bieten, in „Bits of Security“ fest. NIST empfiehlt die Verwendung von Schlüsseln mit einer Mindeststärke von 112 Bit Sicherheit zum Schutz der Daten bis 2030 und danach 128 Bit Sicherheit. Ein 2048-Bit-RSA-Schlüssel bietet eine Sicherheit von 112 Bit. Angesichts der Tatsache, dass TLS-Zertifikate maximal ein Jahr lang gültig sind, erfüllt die RSA-Schlüssellänge von 2048 Bit die NIST-Empfehlung bis weit in dieses Jahrzehnt hinein. Darüber hinaus verlangt PCI DSS die Verwendung einer „starken Kryptographie“, die derzeit als RSA 2048-Bit- oder ECC 224-Bit (oder höher)-Verschlüsselungsschlüssel definiert wird.

Kann es negative Auswirkungen haben, wenn ein größerer, gar nicht erforderlicher 4096-Bit-RSA-Schlüssel verwendet wird? Die Antwort lautet: Ja, auf die Performance. Längere Schlüssel benötigen sowohl auf dem Server als auch auf dem Client mehr Berechnungszeit. Auf Fastlys Servern haben wir kürzlich gemessen, dass 2048-Bit-Verifikationsabläufe viermal schneller laufen als 4096-Bit-RSA-Schlüsselverifikationen. Diese Auswirkung, kombiniert mit den zusätzlichen Daten, die an den Client übertragen werden müssen, wenn ein 4096-Bit-RSA-Server und ein Zwischenzertifikat verwendet werden, beeinträchtigen die Performance zwar nur gering, aber doch bedeutsam. Wenn Sie sich dafür entscheiden, jedes Jahr bei der Erneuerung eines Zertifikats einen kleineren Schlüssel zu verwenden, profitieren Sie von einer besseren Performance, bis es Zeit für stärkere Schlüssel wird.

Eine noch bessere Lösung für dieses Problem bietet die Umstellung von RSA- auf ECDSA-Schlüssel. ECDSA verwendet ein anderes mathematisches Konstrukt als RSA und führt zu viel kleineren Schlüsseln, die ein hohes Maß an Schutz bieten. Ein 256-Bit ECDSA-Schlüssel bietet 128 Bit Sicherheit, was einem 3072-Bit-RSA-Schlüssel entspricht. Da Fastly jetzt auch ECDSA-Zertifikate unterstützt, braucht es keinen Kompromiss mehr zwischen der Performance und der erhöhten Sicherheit eines Zertifikats, das 4096-Bit-RSA-Schlüssel nutzt. Wenn Sie Bedenken haben, zu einem relativ neuen kryptographischen Algorithmus zu wechseln (ECDSA wurde in den 1990er Jahren erfunden), sollten Sie sich umsehen. Bei einem kürzlichen Besuch auf Google.com wurde ein ECDSA-Zertifikat zurückgegeben.

Zusammenfassend lässt sich sagen, dass die Konfiguration Ihres Webservers ein entscheidender Faktor für den Schutz von Daten ist, die über TLS übertragen werden. Das gilt für heute und auch in der Zukunft. Es kann sein, das zwischen Sicherheit und Kompatibilität mit älteren Clients, die TLS 1.3 möglicherweise nicht unterstützen, ein paar Kompromisse eingegangen werden müssen. Mozilla veröffentlicht empfohlene Konfigurationen, die diese Kompromisse berücksichtigen. Für TLS-Serverzertifikate bieten 2048-Bit-RSA-Schlüssel oder 256-Bit-ECDSA-Schlüssel derzeit die beste Kombination aus Sicherheit und Performance. Berücksichtigen Sie die Rolle des Zertifikats und die Auswirkungen auf die Performance, bevor Sie einen größeren Schlüssel wählen.

Wayne Thayer
Senior Director of Engineering
Veröffentlicht am

Lesedauer: 3 Min.

Sie möchten sich mit einem Experten austauschen?
Sprechen Sie mit einem Experten
Diesen Beitrag teilen

Four Things Every Security Director Should Know About GraphQL

An increasing number of developer teams are using GraphQL due to its efficiency, speed, and specificity over other query languages such as REST and SOAP. Educate yourself on GraphQL and how to make sure you're getting ahead of any security considerations for your applications and APIs using it.

Download the white paper
Wayne Thayer
Senior Director of Engineering

Wayne Thayer kümmert sich bei Fastly um Sicherheitsprodukte und TLS. Bevor er zu Fastly kam, leitete er Mozillas Certificate-Authority-Programm und die offizielle Certificate Authority (CA) von GoDaddy. Außerdem ist Wayne in der Mozilla Sicherheits-Community sowie im CA/Browser Forum aktiv, wo er sich auf die Verbesserung der Vertrauenswürdigkeit von CAs konzentriert.

Sie möchten loslegen?

Setzen Sie sich mit uns in Verbindung oder erstellen Sie einen Account.