{"id":7093,"date":"2019-08-15T18:32:09","date_gmt":"2019-08-15T16:32:09","guid":{"rendered":"https:\/\/www.psw-group.de\/blog\/?p=7093"},"modified":"2025-12-17T11:37:23","modified_gmt":"2025-12-17T10:37:23","slug":"tls-1-3-moderne-transportverschluesselung-fuer-mehr-sicherheit","status":"publish","type":"post","link":"https:\/\/www.psw-group.de\/blog\/tls-1-3-moderne-transportverschluesselung-fuer-mehr-sicherheit\/","title":{"rendered":"TLS 1.3: Moderne Transportverschl\u00fcsselung f\u00fcr mehr Sicherheit"},"content":{"rendered":"

Das langersehnte Update des Protokolls Transport Layer Security (TLS) von 1.2 auf 1.3 ist endlich vollzogen. Damit ist TLS 1.3 der offizielle Standard f\u00fcr die Transportverschl\u00fcsselung im Netz. Die inzwischen vierte Version des zur Absicherung der Internetkommunikation dienenden Protokolls schlie\u00dft damit auch die Sicherheitsl\u00fccken seines Vorg\u00e4ngers, das aus 2008 stammende TLS 1.2.<\/p>\n

Die Ratifizierung in RFC 8446 beendete auch eine vierj\u00e4hrige Odyssee. Denn bereits seit 2014 wurde an dem Update gearbeitet \u2013 die im August 2018 von der f\u00fcr Internetprotokolle und Standards verantwortliche Organisation IETF (Internet Engineering Task Force) verabschiedete Finalversion ist nach vier Jahren des Testens und Aushandelns die sage und schreibe 28.(!) Fassung. Zuletzt hatten noch Banken und Beh\u00f6rden eine Opt-in-Technik f\u00fcr das Mitlesen der verschl\u00fcsselten Internetkommunikation gefordert. Wir berichteten<\/a>.<\/p>\n

Das Transport Layer Security Protokoll (TLS)<\/h2>\n

TLS steht kurz f\u00fcr: Transport Layer Security (deutsch: Transportsicherheit) und ist das Nachfolgeprotokoll von SSL<\/a>. Mithilfe von TLS lassen sich Daten verschl\u00fcsselt \u00fcber das Internet oder andere Netzwerke \u00fcbertragen. Dabei handelt es sich um ein hybrides Verschl\u00fcsselungsprotokoll, also einer Kombination aus asymmetrischer und symmetrischer Verschl\u00fcsselung, bei dem die Kommunikationsteilnehmer authentifiziert, die Vertraulichkeit der Kommunikation gesichert und die Integrit\u00e4t der Daten garantiert ist. Das TLS-Protokoll basiert auf zwei Hauptkomponenten: dem Handshake-Protokoll und dem Record-Protokoll.<\/p>\n

TLS Protokollaufbau<\/h2>\n

Das Handshake-Protokoll authentifiziert die Kommunikationsteilnehmer, handelt die kryptografischen Modi und Parameter aus und etabliert das gemeinsame Schl\u00fcsselmaterial. Ein typisches Funktionsmerkmal eines Handshake-Protokolls ist, dass der Empf\u00e4nger dem Sender den Empfang von Daten quittiert. Das Record-Protokoll spielt bei TLS die zentrale Rolle. Es nutzt die zuvor vom Handshake-Protokoll aufgestellten Parameter, um den Datenverkehr zwischen den Partnern zu sch\u00fctzen, sodass er nur an den Endpunkten lesbar ist.<\/p>\n

Neben diesen beiden Protokollen kennt TLS auch noch drei weitere Protokolle:<\/p>\n

Alert Protocol<\/h3>\n

Es ist f\u00fcr die Fehler- und Alarmbehandlung von TLS-Verbindungen zust\u00e4ndig ist und kennt verschiedene Alerts. Es kann das sofortige Abbrechen einer Verbindung veranlassen. Die Alert-Nachrichten sind, wie die anderen Nachrichten, verschl\u00fcsselt und komprimiert.<\/p>\n

Application Data Protocol<\/h3>\n

Mithilfe des Application Data Protocols werden die Anwendungsdaten in Bl\u00f6cke zerlegt, komprimiert, verschl\u00fcsselt und \u00fcbertragen.<\/p>\n

Change Cipher Spec Protocol<\/h3>\n

Das Change Cipher Spec Protocol teilt dem Empf\u00e4nger mit, dass der Sender auf die zuvor im Handshake Protocol ausgehandelte Cipher Suite wechselt.<\/p>\n

Der Verbindungsaufbau mit TLS<\/h2>\n

Der generelle Ablauf bei TLS beginnt mit dem Aufbau einer Verbindung vom Client zum Server. Wenn der Client eine Verbindung zu einem Server aufbaut, schickt er dabei gleich eine Liste an unterst\u00fctzten Cipher Suites mit. Daraufhin authentifiziert sich der Server mit einem Zertifikat und der ausgew\u00e4hlten Cipher Suite. Nun \u00fcberpr\u00fcft der Client die Vertrauensw\u00fcrdigkeit des Zertifikats und dessen \u00dcbereinstimmung mit dem Servernamen. Gegebenenfalls authentisiert sich der Client selbst auch noch gegen\u00fcber dem Server mit einem eigenen Zertifikat. Im n\u00e4chsten Schritt leiten die Kommunikationspartner unter Zuhilfenahme des \u00f6ffentlichen Schl\u00fcssels des Servers einen kryptografischen Sitzungsschl\u00fcssel ab (eine Zufallszahl) oder beide Parteien berechnen mittels Diffie-Hellman-Schl\u00fcsselaustauschverfahren ein gemeinsames Geheimnis (kryptografischer Schl\u00fcssel), mit dem sie anschlie\u00dfend s\u00e4mtliche zu \u00fcbertragenen Nachrichten verschl\u00fcsseln.<\/p>\n

Die Authentifizierung und Identifikation der Kommunikationspartner basieren \u00fcbrigens auf asymmetrischen Verschl\u00fcsselungsverfahren. Der eigentliche Sitzungsschl\u00fcssel ist ein einmalig nutzbarer symmetrischer Schl\u00fcssel, mit dem die Daten sowohl entschl\u00fcsselt als auch verschl\u00fcsselt werden.<\/p>\n

Was ist neu in TLS 1.3?<\/h2>\n

Schauen wir uns nun gemeinsam die wichtigsten Neuerungen an, die durch das Update auf TLS 1.3 die alten Sicherheitsl\u00fccken schlie\u00dfen.<\/p>\n

Forward Secrecy erh\u00f6ht die TLS Sicherheit<\/h3>\n

Eine der wichtigsten Neuerungen ist die Forward Secrecy. Mit ihr ist eine nachtr\u00e4gliche Entschl\u00fcsselung nicht mehr m\u00f6glich. Ebenso kann ein Angreifer auch nicht auf die Inhalte fr\u00fcherer Sessions zugreifen, selbst wenn er sich Zugriff auf einen aktuellen Schl\u00fcssel verschafft. Dies ist durch die Streichung des RSA-Schl\u00fcsselaustausches und den Zwang zum Diffie-Hellman-Verfahren beim Schl\u00fcsseltausch gew\u00e4hrleistet.<\/p>\n

Ebenso wichtig ist, dass die Hintert\u00fcr \u2013 auf die Banken und Beh\u00f6rden dr\u00e4ngten \u2013 nicht eingebaut wurde, sodass ihnen nicht m\u00f6glich ist, Nachschl\u00fcssel zu erstellen, mit denen sie in ihren eigenen Netzen den verschl\u00fcsselten Netzwerkverkehr aufbrechen k\u00f6nnten.<\/p>\n

Round-Trip Performance-Optimierung<\/h3>\n

Verbindungen k\u00f6nnen in der TLS Version 1.3 viel schneller aufgebaut werden. Im Gegensatz zu TLS 1.2, bei dem f\u00fcr einen Verbindungsaufbau 2-Round-Trips (Kommunikationsschritte) ben\u00f6tigt wurden, erfolgt der Verbindungsaufbau bei TLS 1.3 mit nur einem Round-Trip. Dies ist m\u00f6glich, da bei der ersten Client-Anfrage schon die unterst\u00fctzten Cipher-Suiten mitgeteilt werden und der Server darauf gleich passend Antworten kann. Somit kann TLS 1.3 viel schneller mit der verschl\u00fcsselten HTTPS-Kommunikation begonnen werden.<\/p>\n

Resumption f\u00fcr schnellere TLS Verbindung<\/h3>\n

Wenn ein Client in der Vergangenheit bereits mit einem Server verbunden war, ist die erneute Verbindung sogar mit einem Zero Round Trip Time Resumption (0-RTT) m\u00f6glich. Somit kann der Client sofort verschl\u00fcsselte Daten schicken. Dabei k\u00f6nnen beide auf die bereits vorher getroffene Vereinbarung zur\u00fcckgreifen und den Handshake beschleunigen.<\/p>\n

Der Nachteil dabei ist allerdings, dass die Sicherheit des Client-Server-Handshakes eingeschr\u00e4nkt ist: Beim Einsatz von 0-RTT besteht keine Forward Secrecy gegen einen kompromittierten Session-Ticket-Key mehr. Das bedeutet: Sollte ein Angreifer die Daten aufzeichnen und sp\u00e4ter an den Session-Ticket-Key gelangt, kann er das Session-Ticket entschl\u00fcsseln und k\u00f6nnte damit die vom Client gesendeten 0-RTT-Daten entschl\u00fcsseln. Ein weiterer Nachteil: Auch der Schutz gegen Replay-Attacken zwischen einzelnen TLS-Verbindungen f\u00e4llt weg.<\/p>\n

Weniger ist mehr: Cipher-Suiten wurden aufger\u00e4umt<\/h3>\n

In den Protokollen SSL und TLS bis einschlie\u00dflich der TLS-Version 1.2 wurde in den Cipher Suiten alles zusammengefasst, was f\u00fcr die Verbindung ausgehandelt werden konnte. Dazu geh\u00f6rten unterst\u00fctzte Zertifikatstypen, Hashfunktionen f\u00fcr die Ableitung von Schl\u00fcsseln, MAC-Funktionen, der Schl\u00fcsselaustauschalgorithmus, der Authentifizierungsalgorithmus und der Verschl\u00fcsselungsalgorithmus sowie die Betriebsart f\u00fcr die Verschl\u00fcsselung. Eine ganze Menge also, was dazu f\u00fchrte, dass TLS 1.2 selbst 37 Cipher-Suiten spezifiziert. Dazu kommen noch 319 Suiten aus vorangegangenen TLS-Versionen. In TLS 1.3 wurden viele dieser veralteten Features entfernt und nur f\u00fcnf neue Cipher-Suiten definiert. Zudem werden \u00e4ltere Suiten nicht mehr unterst\u00fctzt.<\/p>\n

Besserer Schl\u00fcsselaustausch f\u00fcr mehr Integrit\u00e4t<\/h3>\n

SSL und TLS bis Version 1.2 verwenden bei der Verschl\u00fcsselung und Integrit\u00e4tssicherung den sogenannten MAC-then-Encrypt-Ansatz. Dabei wird zun\u00e4chst ein Pr\u00fcfwert \u00fcber die Klartextdaten gebildet und an die Daten angeh\u00e4ngt, bevor beide gemeinsam verschl\u00fcsselt werden. Dieser Ansatz erwies sich jedoch als problematisch, erm\u00f6glichte er doch beispielsweise den Poodle-Angriff. Sie erinnern sich: Angreifer errieten einfach Byte f\u00fcr Byte den Klartext und lie\u00dfen sich von der Integrit\u00e4tssicherung best\u00e4tigen, ob sie richtig geraten haben. In TLS 1.3 ist damit Schluss, indem Methoden wie Elliptic Curve Diffie-Hellman (ECDH), Authenticated Encryption with Associated Data (AEAD) und HMAC Key Derivation Function (HKDF) eingesetzt werden, bei der die Integrit\u00e4tssicherung und Verschl\u00fcsselung in einem Schritt durchgef\u00fchrt werden.<\/p>\n

TLS Verschl\u00fcsselung durch neue Krypto-Algorithmen verst\u00e4rkt<\/h3>\n

Die ebenfalls problematischen Kryptoverfahren wie DES\/3DES, MD5, SHA-1, RC4 und die Export-Cipher-Suiten sind in TLS 1.3 nicht mehr zul\u00e4ssig, da auch diese als eindeutig angreifbar gelten. Sie wurden gegen neue, sichere Verfahren ersetzt, sodass TLS 1.3 eine bessere Integrit\u00e4tssicherung der verschl\u00fcsselten Daten und weniger einsehbare Metadaten \u00fcber den Inhalt der TLS-Verbindung erlaubt. Diese neuen Verfahren basieren auf der Grundlage von elliptischen Kurven (ECC) wie der Curve25519 von Dan J. Bernstein und der Curve448 (Goldilocks-Kurve). Au\u00dferdem erfolgt der Verbindungsaufbau nun so weit wie m\u00f6glich signiert.<\/p>\n

Die folgende Tabelle fasst diese Neuerungen noch einmal zusammen:<\/h2>\n

\"TLS<\/a><\/p>\n

 <\/p>\n

Fazit: Diese Schwachstellen wurden mit dem TLS Update geschlossen<\/h2>\n

Verschiedene Angriffe aus der Vergangenheit sind dank TLS 1.3 Upgrade jedoch nicht mehr m\u00f6glich. Dazu geh\u00f6ren beispielsweise Downgrade-Attacken wie POODLE, FREAK und LOGJAM, bei der die Nutzung der unsicheren Export-Cipher-Suiten erzwungen wurde, um danach die Verschl\u00fcsselung zu brechen. Auch Kollisionsattacken wie SLOTH und Sweet32 durch Verzicht auf schwache SHA-1-Hashes und Abschaffung der Stream-Chiffre RC4 geh\u00f6ren der Vergangenheit an. Und da die Betriebsart Cipher Block Chaining (CBC) in TLS 1.3 ebenfalls verboten ist, sind auch Angriffe wie BEAST und LUCKY13, die die Schw\u00e4chen von CBC ausnutzten, nicht mehr m\u00f6glich. Kurzum: Alles, was bislang f\u00fcr \u00c4rger sorgte, wurde bei TLS 1.3 gestrichen.<\/p>\n