TLS 1.3: Moderne Transportverschlüsselung für mehr Sicherheit

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ür die Transportverschlüsselung im Netz. Die inzwischen vierte Version des zur Absicherung der Internetkommunikation dienenden Protokolls schließt damit auch die Sicherheitslücken seines Vorgängers, das aus 2008 stammende TLS 1.2.

Die Ratifizierung in RFC 8446 beendete auch eine vierjährige Odyssee. Denn bereits seit 2014 wurde an dem Update gearbeitet – die im August 2018 von der für 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örden eine Opt-in-Technik für das Mitlesen der verschlüsselten Internetkommunikation gefordert. Wir berichteten.

Das Transport Layer Security Protokoll (TLS)

TLS steht kurz für: Transport Layer Security (deutsch: Transportsicherheit) und ist das Nachfolgeprotokoll von SSL. Mithilfe von TLS lassen sich Daten verschlüsselt über das Internet oder andere Netzwerke übertragen. Dabei handelt es sich um ein hybrides Verschlüsselungsprotokoll, also einer Kombination aus asymmetrischer und symmetrischer Verschlüsselung, bei dem die Kommunikationsteilnehmer authentifiziert, die Vertraulichkeit der Kommunikation gesichert und die Integrität der Daten garantiert ist. Das TLS-Protokoll basiert auf zwei Hauptkomponenten: dem Handshake-Protokoll und dem Record-Protokoll.

TLS Protokollaufbau

Das Handshake-Protokoll authentifiziert die Kommunikationsteilnehmer, handelt die kryptografischen Modi und Parameter aus und etabliert das gemeinsame Schlüsselmaterial. Ein typisches Funktionsmerkmal eines Handshake-Protokolls ist, dass der Empfänger 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ützen, sodass er nur an den Endpunkten lesbar ist.

Neben diesen beiden Protokollen kennt TLS auch noch drei weitere Protokolle:

Alert Protocol

Es ist für die Fehler- und Alarmbehandlung von TLS-Verbindungen zuständig ist und kennt verschiedene Alerts. Es kann das sofortige Abbrechen einer Verbindung veranlassen. Die Alert-Nachrichten sind, wie die anderen Nachrichten, verschlüsselt und komprimiert.

Application Data Protocol

Mithilfe des Application Data Protocols werden die Anwendungsdaten in Blöcke zerlegt, komprimiert, verschlüsselt und übertragen.

Change Cipher Spec Protocol

Das Change Cipher Spec Protocol teilt dem Empfänger mit, dass der Sender auf die zuvor im Handshake Protocol ausgehandelte Cipher Suite wechselt.

Der Verbindungsaufbau mit TLS

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ützten Cipher Suites mit. Daraufhin authentifiziert sich der Server mit einem Zertifikat und der ausgewählten Cipher Suite. Nun überprüft der Client die Vertrauenswürdigkeit des Zertifikats und dessen Übereinstimmung mit dem Servernamen. Gegebenenfalls authentisiert sich der Client selbst auch noch gegenüber dem Server mit einem eigenen Zertifikat. Im nächsten Schritt leiten die Kommunikationspartner unter Zuhilfenahme des öffentlichen Schlüssels des Servers einen kryptografischen Sitzungsschlüssel ab (eine Zufallszahl) oder beide Parteien berechnen mittels Diffie-Hellman-Schlüsselaustauschverfahren ein gemeinsames Geheimnis (kryptografischer Schlüssel), mit dem sie anschließend sämtliche zu übertragenen Nachrichten verschlüsseln.

Die Authentifizierung und Identifikation der Kommunikationspartner basieren übrigens auf asymmetrischen Verschlüsselungsverfahren. Der eigentliche Sitzungsschlüssel ist ein einmalig nutzbarer symmetrischer Schlüssel, mit dem die Daten sowohl entschlüsselt als auch verschlüsselt werden.

Was ist neu in TLS 1.3?

Schauen wir uns nun gemeinsam die wichtigsten Neuerungen an, die durch das Update auf TLS 1.3 die alten Sicherheitslücken schließen.

Forward Secrecy erhöht die TLS Sicherheit

Eine der wichtigsten Neuerungen ist die Forward Secrecy. Mit ihr ist eine nachträgliche Entschlüsselung nicht mehr möglich. Ebenso kann ein Angreifer auch nicht auf die Inhalte früherer Sessions zugreifen, selbst wenn er sich Zugriff auf einen aktuellen Schlüssel verschafft. Dies ist durch die Streichung des RSA-Schlüsselaustausches und den Zwang zum Diffie-Hellman-Verfahren beim Schlüsseltausch gewährleistet.

Ebenso wichtig ist, dass die Hintertür – auf die Banken und Behörden drängten – nicht eingebaut wurde, sodass ihnen nicht möglich ist, Nachschlüssel zu erstellen, mit denen sie in ihren eigenen Netzen den verschlüsselten Netzwerkverkehr aufbrechen könnten.

Round-Trip Performance-Optimierung

Verbindungen können in der TLS Version 1.3 viel schneller aufgebaut werden. Im Gegensatz zu TLS 1.2, bei dem für einen Verbindungsaufbau 2-Round-Trips (Kommunikationsschritte) benötigt wurden, erfolgt der Verbindungsaufbau bei TLS 1.3 mit nur einem Round-Trip. Dies ist möglich, da bei der ersten Client-Anfrage schon die unterstützten Cipher-Suiten mitgeteilt werden und der Server darauf gleich passend Antworten kann. Somit kann TLS 1.3 viel schneller mit der verschlüsselten HTTPS-Kommunikation begonnen werden.

Resumption für schnellere TLS Verbindung

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öglich. Somit kann der Client sofort verschlüsselte Daten schicken. Dabei können beide auf die bereits vorher getroffene Vereinbarung zurückgreifen und den Handshake beschleunigen.

Der Nachteil dabei ist allerdings, dass die Sicherheit des Client-Server-Handshakes eingeschränkt 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äter an den Session-Ticket-Key gelangt, kann er das Session-Ticket entschlüsseln und könnte damit die vom Client gesendeten 0-RTT-Daten entschlüsseln. Ein weiterer Nachteil: Auch der Schutz gegen Replay-Attacken zwischen einzelnen TLS-Verbindungen fällt weg.

Weniger ist mehr: Cipher-Suiten wurden aufgeräumt

In den Protokollen SSL und TLS bis einschließlich der TLS-Version 1.2 wurde in den Cipher Suiten alles zusammengefasst, was für die Verbindung ausgehandelt werden konnte. Dazu gehörten unterstützte Zertifikatstypen, Hashfunktionen für die Ableitung von Schlüsseln, MAC-Funktionen, der Schlüsselaustauschalgorithmus, der Authentifizierungsalgorithmus und der Verschlüsselungsalgorithmus sowie die Betriebsart für die Verschlüsselung. Eine ganze Menge also, was dazu führte, 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ünf neue Cipher-Suiten definiert. Zudem werden ältere Suiten nicht mehr unterstützt.

Besserer Schlüsselaustausch für mehr Integrität

SSL und TLS bis Version 1.2 verwenden bei der Verschlüsselung und Integritätssicherung den sogenannten MAC-then-Encrypt-Ansatz. Dabei wird zunächst ein Prüfwert über die Klartextdaten gebildet und an die Daten angehängt, bevor beide gemeinsam verschlüsselt werden. Dieser Ansatz erwies sich jedoch als problematisch, ermöglichte er doch beispielsweise den Poodle-Angriff. Sie erinnern sich: Angreifer errieten einfach Byte für Byte den Klartext und ließen sich von der Integritätssicherung bestätigen, 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ätssicherung und Verschlüsselung in einem Schritt durchgeführt werden.

TLS Verschlüsselung durch neue Krypto-Algorithmen verstärkt

Die ebenfalls problematischen Kryptoverfahren wie DES/3DES, MD5, SHA-1, RC4 und die Export-Cipher-Suiten sind in TLS 1.3 nicht mehr zulässig, da auch diese als eindeutig angreifbar gelten. Sie wurden gegen neue, sichere Verfahren ersetzt, sodass TLS 1.3 eine bessere Integritätssicherung der verschlüsselten Daten und weniger einsehbare Metadaten über 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ßerdem erfolgt der Verbindungsaufbau nun so weit wie möglich signiert.

Die folgende Tabelle fasst diese Neuerungen noch einmal zusammen:

Fazit: Diese Schwachstellen wurden mit dem TLS Update geschlossen

Verschiedene Angriffe aus der Vergangenheit sind dank TLS 1.3 Upgrade jedoch nicht mehr möglich. Dazu gehören beispielsweise Downgrade-Attacken wie POODLE, FREAK und LOGJAM, bei der die Nutzung der unsicheren Export-Cipher-Suiten erzwungen wurde, um danach die Verschlüsselung zu brechen. Auch Kollisionsattacken wie SLOTH und Sweet32 durch Verzicht auf schwache SHA-1-Hashes und Abschaffung der Stream-Chiffre RC4 gehören 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ächen von CBC ausnutzten, nicht mehr möglich. Kurzum: Alles, was bislang für Ärger sorgte, wurde bei TLS 1.3 gestrichen.