Die Sicherheit der Kommunikation und der Schutz der Privatsphäre sind in der heutigen digital vernetzten Welt nach wie vor ein wichtiges Anliegen. Das erste Protokoll, das sichere und verschlüsselte Verbindungen über das Internet ermöglichte, war Secure Socket Layer (SSL), das die Verschlüsselung mit öffentlichen Schlüsseln verwendete. Im Jahr 1999 wurde SSL auf Version 3 aufgerüstet und als Transport Layer Security Version (TLS) 1.0 standardisiert. Diese Protokolle sind nun durch die sichereren Versionen TLS 1.2 und 1.3 ersetzt worden.
Transport Layer Security (TLS) ist der Standard, der gewährleistet, dass die gesamte Kommunikation über das öffentliche Internet geschützt und manipulationssicher bleibt. Er bietet Vertraulichkeit, Authentifizierung, Integrität und Schutz vor Wiederholungsangriffen.
Dieser Artikel befasst sich mit den Änderungen und Verbesserungen von TLS 1.2 und 1.3 in TLS 1.3.
TLS 1.2 vs. 1.3 - Zusammenfassung der Unterschiede
TLS 1.2 wurde im Jahr 2008 veröffentlicht und in RFC 5246 dokumentiert. Die Aktualisierung umfasste mehrere Verbesserungen, bei denen schwächere Chiffriersuiten durch stärkere Chiffrierungen ersetzt wurden. TLS 1.3 wurde zehn Jahre nach Version 1.2 im Jahr 2018 veröffentlicht. Die IETF hat die neueste Version in RFC 8446 standardisiert. Zu den wesentlichen Änderungen in 1.3 gegenüber 1.2 gehören die folgenden:
Handshake-Prozess
Beide Protokolle beginnen mit einem Handshake-Prozess, der einen sicheren/verschlüsselten Tunnel zwischen einem Client und einem Server unter Verwendung einer Kombination aus asymmetrischer und symmetrischer Verschlüsselung herstellt. Die eigentliche Datenübertragung findet nach Abschluss des Handshakes statt.
Das TLS 1.2-Handshake-Verfahren war langwierig und zeitaufwändig. TLS 1.3 hat es effizienter gemacht und die Sicherheit erhöht.
TLS 1.2
Der TLS 1.2-Handshake erfordert zwei Roundtrips (2-RTT) oder den Austausch von Nachrichten zwischen Client und Server, um ihn abzuschließen. Der Prozess läuft wie folgt ab.
Client hello
Der Client initiiert einen TLS-Handshake mit einer Client Hello Nachricht, die Folgendes enthält:
- Client-unterstützte TLS-Versionen
- Client-unterstützte Cipher-Suites
- Eine Zufallszahl, die in einem späteren Schritt zur Erzeugung eines Verschlüsselungscodes verwendet wird.
- Eine nicht leere Sitzungs-ID, wenn der Client eine frühere Sitzung mit dem Server wieder aufnehmen möchte.
Server hello
Wenn der Client Hello eine nicht leere Sitzungs-ID hatte, sucht der Server nach einer früheren zwischengespeicherten Sitzung und setzt sie fort. Ist sie leer, generiert der Server eine neue zufällige Sitzungs-ID. Er antwortet dann mit einer Server-Hallo-Nachricht, die Folgendes enthält:
- Die TLS-Version wird aus der Liste der Versionen ausgewählt, die im Client Hello enthalten ist.
- Die ausgewählten Cipher-Suiten stammen aus der Liste, die im Client Hello enthalten ist.
- Eine vom Server generierte Zufallszahl für den Verschlüsselungsschlüssel im späteren Schritt.
- Die Sitzungs-ID
- Ein signiertes SSL/TLS-Zertifikat, das den öffentlichen Schlüssel des Servers enthält.
Der Server sendet dann eine Server Hello Done Nachricht an den Client
{{banner-6="/design/banners"}}
Austausch von Schlüsseln
Nach dem Empfang von Server Hello Done prüft der Client, ob eine Zertifizierungsstelle dem Serverzertifikat vertraut. Nach der Validierung sendet er eine Key Exchange-Nachricht mit einem zufällig generierten Pre-Master-Schlüssel an den Server, der mit dem öffentlichen Schlüssel des Servers verschlüsselt ist.
Der Server entschlüsselt den Pre-Master-Schlüssel mit seinem privaten Schlüssel. Der Client und der Server erzeugen ein Master Secret unter Verwendung der zuvor geteilten Zufallszahlen und des Pre-Master-Schlüssels. Beide verwenden das gemeinsam genutzte Master Secret, um Sitzungsschlüssel zu generieren.
Handshake beendet
Schließlich sendet der Client eine Change Cipher Spec-Nachricht an den Server, in der er angibt, dass er zur symmetrischen Verschlüsselung mit Sitzungsschlüsseln übergeht, gefolgt von der Handshake Finished-Nachricht.
Der Server antwortet ebenfalls mit einer Change Cipher Spec Nachricht und einer Handshake Finished Nachricht, die anzeigt, dass er ebenfalls bereit ist, den gemeinsamen symmetrischen Schlüssel zu verwenden.
Der Client und der Server tauschen nun vollständig verschlüsselte Daten unter Verwendung der Sitzungsschlüssel aus. Diese Schlüssel sind temporär und gelten nur für die Dauer der Sitzung zwischen dem Client und dem Server.
TLS 1.3
Im Vergleich dazu wird der TLS 1.3-Handshake-Prozess in einem Round Trip (1-RTT) abgeschlossen.
Client hello
Der Client initiiert einen TLS-Handshake mit einer Client Hello Nachricht, die Folgendes enthält:
- Verfügbare Protokollversion (1.3)
- Client-unterstützte Cipher-Suites
- Client-gestützte Schlüsselaustauschmethoden
- Client-generierte Zufallszahl
- Etwaige optionale Erweiterungen
Server hello
Der Server generiert das Master Secret anhand der ClientHello, Zufallszahl, seiner eigenen Zufallszahl, der Client-Parameter und der Cipher-Suites. Anschließend antwortet er mit einer "Server Hello" - und "Server Finished" -Nachricht, die Folgendes enthält:
- Serverseitig gewählte Protokollversion (1.3)
- Die vom Server ausgewählten Chiffriersuiten
- Die vom Server festgelegte Methode für den Schlüsselaustausch
- Server-generierte Zufallszahl
- Server SSL/TLS-Zertifikat
- Alle optionalen Parameter
Handshake beendet
Der Client verifiziert das Server-Zertifikat, generiert das Master-Secret und sendet die Nachricht Client Finished. Der Client und der Server beginnen dann sofort mit dem Austausch von Daten über symmetrische Verschlüsselung.
TLS 1.2 vs. 1.3 - Funktionsunterschiede
Einige Funktionen von TLS 1.2 wurden nicht in 1.3 übernommen. Außerdem wurden mehrere neue Funktionen hinzugefügt.
Algorithmen
Die veralteten und schwachen Verschlüsselungsalgorithmen von TLS 1.2 wurden entfernt. TLS 1.3 unterstützt nur noch AEAD-Algorithmen (Authenticated Encryption with Associated Data). AEAD ist eine Art der Verschlüsselung, die gleichzeitig die Vertraulichkeit, Integrität und Authentizität der Daten sicherstellt. Dabei werden die zu verschlüsselnden Daten (der Klartext) und zusätzliche Daten, für die Integrität, aber nicht Vertraulichkeit erforderlich ist (die zugehörigen Daten), kombiniert und verarbeitet. Dieser integrierte Ansatz stellt sicher, dass die verschlüsselten Daten (Chiffretext) nicht unbemerkt manipuliert oder gefälscht werden können, und dass jegliche Änderungen bei der Entschlüsselung sofort erkennbar sind.
Versionskontrolle
In TLS 1.2 und früheren Versionen ermöglichte der Mechanismus der Versionsaushandlung den Clients und Servern die Kommunikation der höchsten Version von TLS, die beide unterstützen konnten. Dieser Prozess war jedoch anfällig für Manipulationen durch Angreifer, die den Aushandlungsprozess abfangen und die Nachrichten ändern konnten, um die Verwendung einer älteren Protokollversion zu erzwingen. TLS 1.3 vereinfacht diesen Prozess, indem es verlangt, dass Clients und Server TLS 1.3 unterstützen, wenn es verwendet werden soll.
Komprimierung
TLS-Versionen vor 1.3 unterstützten Komprimierung, und eine Liste der unterstützten Komprimierungsmethoden wurde in Client Hello ausgetauscht. Diese Methoden wurden jedoch bei einigen Angriffen ausgenutzt. TLS 1.3 sendet nun ein Null-Byte (in legacy_compression_methods), wodurch die Komprimierung effektiv aus dem Protokoll entfernt wurde.
{{banner-9="/design/banners"}}
Überprüfung der digitalen Unterschrift
Wenn ein Server der anderen Partei sein Zertifikat als Teil des TLS-Handshakes vorlegt, stellt er auch eine digitale Signatur bereit, um zu beweisen, dass er der rechtmäßige Eigentümer des Zertifikats ist. Digitale Signaturen werden auch zur Validierung des Schlüsselaustauschprozesses verwendet.
TLS 1.2 unterstützt eine Reihe von Chiffriersuiten (in erster Linie RSA) für die Signaturprüfung, und die Wahl hängt davon ab, was sowohl der Client als auch der Server unterstützen und bevorzugen.
Im Gegensatz dazu betont TLS 1.3 die Verwendung des Elliptic Curve Digital Signature Algorithm (ECDSA), der kleinere Schlüsselgrößen verwendet, was zu schnelleren Berechnungen, geringerer Bandbreitennutzung und schnelleren Verbindungen führt. TLS 1.3 beschränkt die Verwendung von RSA auf sicherere Auffüllverfahren (insbesondere RSASSA-PSS) und fördert generell die Verwendung von Kryptographie mit elliptischen Kurven.
Vorwärtssicherheit
Forward Secrecy bezieht sich auf ephemere Schlüsselaustauschmechanismen, die für jede sichere Kommunikationssitzung einen neuen, eindeutigen Sitzungsschlüssel erzeugen.
TLS 1.3 schreibt die Verwendung von Forward Secrecy vor. Wie im vorigen Abschnitt erläutert, berechnen der Client und der Server während des TLS-1.3-Handshake-Prozesses unabhängig voneinander einen eindeutigen Sitzungsschlüssel unter Verwendung des Ephemeral-Diffie-Hellman-Schlüsselaustauschprotokolls. Die Schlüssel werden mathematisch aus den Zufallszahlen von Client und Server und den ausgewählten Cipher Suites berechnet. Diese Sitzungsschlüssel werden nicht über das Netz übertragen und nach Beendigung jeder Sitzung verworfen.
Ziel ist es, die Privatsphäre vergangener Sitzungen zu schützen, so dass ein Angreifer, selbst wenn er den privaten Schlüssel des Servers erbeutet, nicht den gesamten Datenaustausch entschlüsseln kann.
TLS 1.2 vs. 1.3 Performance
TLS 1.3 verbessert die Performance der Version 1.2 erheblich.
Geringere Handshake-Latenzzeit
TLS 1.2 erfordert zwei Durchläufe, um den Handshake-Prozess abzuschließen. TLS 1.3 fasst den anfänglichen Handshake und die Aushandlung der kryptografischen Parameter in einem einzigen Durchgang zusammen. Dadurch wird die Handshake-Zeit effektiv um die Hälfte reduziert.
TLS 1.3 bietet auch einen 0-RTT-Handshake, bei dem der Client und der Server eine zuvor aufgebaute TLS-Sitzung wieder aufnehmen können. Um den Datenaustausch mit Null-Round-Trip zu beginnen, müssen sowohl der Client als auch der Server die Sitzungsschlüssel aufbewahren. Sie tauschen Daten aus, bevor der Server die Identität des Clients ordnungsgemäß verifiziert.
Angenommen, ein Angreifer hat zuvor die Kommunikation zwischen Client und Server abgefangen. In diesem Fall kann der Angreifer die Client-Daten an den Server zurückspielen, und der Server kann nicht überprüfen, ob sie legitim sind oder nicht. Daher wird der 0-RTT-Handshake nicht empfohlen.
Verringerter Rechenaufwand
Mit TLS 1.3 werden die veralteten Chiffriersuiten und kryptografischen Funktionen aus dem Verhandlungsprozess entfernt. Außerdem wird der Schlüsselaustauschprozess durch die Verwendung des Diffie-Hellman-Schlüsselaustauschs vereinfacht, so dass keine separaten Schlüsselaustauschmechanismen wie der in TLS 1.2 verwendete RSA-Mechanismus mehr erforderlich sind. Durch diese beiden Verbesserungen wird der Rechenaufwand sowohl auf dem Client als auch auf dem Server verringert.
Einführung von TLS 1.3
Wenn Sie es noch nicht getan haben, sollten Sie auf TLS 1.3 umsteigen.
Verschiedene Regulierungs- und Normungsorganisationen nehmen TLS 1.3 in ihre Compliance-Anforderungen auf, um eine sichere Übertragung über verschiedene Netze hinweg zu gewährleisten.
So enthält beispielsweise die Sonderveröffentlichung 800-52 Revision 2 des National Institute of Standards and Technology (NIST) Richtlinien für die Implementierung von TLS 1.3 in Bundessystemen. NIST verlangt von den Organisationen, die Unterstützung für TLS 1.3 bis Januar 2024 zu planen und einzuführen. Dieses Mandat unterstreicht, wie wichtig die Umstellung auf TLS 1.3 ist, um den Industriestandards und bewährten Verfahren zu entsprechen.
Andere gängige Standards, wie der Payment Card Industry Standard Security Council(PCI-DSS) und der Health Insurance Portability and Accountability Act (HIPAA), beziehen sich ebenfalls auf die Richtlinien des NIST SP 800-52.
Eine große Anzahl von Websites verwendet sowohl 1.2 als auch 1.3, um die Interoperabilität mit den meisten Endgeräten zu gewährleisten. Qualys SSL Labs führt kontinuierlich Erhebungen der 150.000 beliebtesten Websites (laut Alexa) durch. Nach dem Scan vom Februar 2024 unterstützen 99,9 % der Websites die Version 1.2, während 67,8 % der Websites jetzt TLS 1.3 unterstützen.
Die größte Herausforderung bei der Einführung von TLS 1.3 ist der begrenzte Suport durch Client-Geräte. Die folgenden Browser und Anwendungen unterstützen TLS 1.3 zum Zeitpunkt der Erstellung dieses Dokuments vollständig.
- Firefox 63+
- Chrom 70+
- Edge 75+
- Opera 57+
- Safari 12.1+
- Android 10.0+
- Java 11+
- OpenSSL 1.1.1+
{{banner-3="/design/banners"}}
Optionen zur Konfiguration
Mozilla stellt einen SSL-Konfigurationsgenerator zur Verfügung, um TLS 1.3 in vielen Serversoftwares zu aktivieren. Im Folgenden finden Sie die empfohlene Konfiguration des Apache 2.4.41 Webservers mit ausschließlich aktiviertem TLS 1.3.
<VirtualHost *:80>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /path/to/signed_cert_and_inter_certs
SSLCertificateKeyFile /path/to/private_key
Protocols h2 http/1.1
Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"Schlussfolgerungen
TLS ist von entscheidender Bedeutung für die Sicherung von Übertragungen über jede Netzinfrastruktur durch Verschlüsselung mit öffentlichen Schlüsseln und einen Handshake-Mechanismus zwischen Clients und Servern. Im Vergleich zu TLS 1.2 bietet TLS 1.3 verbesserte Sicherheit, höhere Performance und optimierte Funktionen.
Wenn Sie mit Performance Problemen zu kämpfen haben, ist ein Upgarde Ihres TLS nur der erste Schritt. Sie brauchen Transparenz, um Probleme zu beheben und Ihre MTTR zu verringern. Catchpoints unvergleichliches Netzwerk aktiver Beobachter bietet Einblick in alle Standorte, Rechenzentren und Remote-Standorte. Sie können Probleme bei der Konnektivität von Benutzern, in öffentlichen und privaten Netzwerken und auf Anwendungsebenen diagnostizieren.
