Die Neuerungen in TLS 1.3
Supersicher
TLS 1.3 tritt an, verschlüsselte Verbindungen im Internet sicherer und schneller zu machen. Das ist auch dringend nötig.
Transport Layer Security (TLS, Nachfolger des Secure Socket Layer SSL) ist der wichtigste Standard zur verschlüsselten Datenübertragung im Internet. In den letzten Jahren hat es allerdings TLS/SSL-Verwundbarkeiten nur so gehagelt.
Mit der ROBOT-Attacke (Return of Bleichenbacher’s Oracle Threat) haben Hanno Böck und Juraj Somorovsky von der Hackmanit GmbH und der Ruhr-Universität Bochum sowie Craig Young von Tripwire im Dezember 2017 nachgewiesen, dass sich Sicherheitsprobleme nicht aussitzen lassen: ROBOT hat die 19 Jahre alte Bleichenbacher-Verwundbarkeit zum sage und schreibe achten Mal wiederbelebt (siehe ix.de/ix1808110). Die Lücke fand sich in Webservern, Firewalls und Lastverteilern wie Ciscos ACE Load Balancer und Citrix’ NetScaler. Bei Veröffentlichung soll rund jede dritte Domain betroffen gewesen sein. Bleichenbacher-Attacken nutzen das deterministische RSA-PKCS#1-v1.5-Padding in TLS bis einschließlich Version 1.2 für ein Orakel, mit dessen Hilfe sich die symmetrischen Schlüssel errechnen lassen. Die Verwundbarkeit galt bereits mindestens sieben Mal in verschiedenen Szenarien als „behoben“.
Der TLS-1.3-Frühjahrsputz
Bei so vielen Schwachstellen bestehender TLS-Versionen war ein Frühjahrsputz längst überfällig. Die europäische Datenschutz-Grundverordnung mit ihren drakonischen Strafen und der Forderung, Daten nach dem Stand der Technik zu schützen, hat der Frage nach wirksamer Transportverschlüsselung weiteren Nachdruck verliehen. Und nun ist es so weit: Knapp ein Jahrzehnt nach der Vorstellung von TLS 1.2 durchläuft der finale Entwurf der Nachfolgeversion, TLS 1.3, gerade die letzte Phase der Standardisierung beim IETF.
Die IETF hatte sich für TLS 1.3 das Ziel gesetzt, alle bekannten Schwachstellen der Vorgängerversionen auszumerzen. Das war sicherlich keine leichte Aufgabe (siehe Tabelle). Darüber hinaus stand die für Edge Computing höchst relevante Latenzminimierung auf dem Programm. Nebenbei sollte eine optimierte Architektur geschaffen werden, die das Nachrüsten von Algorithmen wie SIDH (Supersingular Isogeny Diffie-Hellman) erleichtern würde, die auch Quantencomputern standhalten.
TLS 1.3 bringt ein neues, schlankeres Handshake-Verfahren sowie neue Signaturalgorithmen und ändert den konzeptionellen Aufbau einer Chiffre-Suite. Auch bei den Chiffre-Suites selbst wurde kräftig aufgeräumt: Weggefallen sind statische RSA-, DSA- und Diffie-Hellman-Cipher-Suites. Der Einsatz der unsicheren kryptografischen Hashfunktionen SHA1 und MD5 (angreifbar über SLOTH), der verwundbaren Stream-Verschlüsselung RC4 (Angriffe: Bar Mitzvah und RC4 NOMORE) und des Blockchiffre-Modus CBC (BEAST, Sweet32, Lucky13) ist in TLS 1.3 ebenfalls unzulässig.
Das Protokoll verschlüsselt jetzt alle Handshake-Nachrichten bis auf die ServerHello-Initialisierung. TLS 1.3 kann außerdem diverse Protokollerweiterungen, die zuvor im Klartext übermittelt wurden, in einer EncryptedExtension-Nachricht verschlüsselt übertragen und verzichtet auf überflüssige Nachrichten wie ChangeCipherSpec (außer zur Gewährleistung von Mittelbox-Kompatibilität).
Die neue Version entsorgt zudem zahlreiche kryptografische Altlasten. TLS 1.3 verbietet Static-RSA-Handshakes. Das Protokoll eliminiert alle Nicht-AEAD-Chiffren (Authenticated Encryption with Associated Data, eine Form der Verschlüsselung mit eingebauten Vorkehrungen zur Gewährleistung von Datenintegrität zusätzlich zur Vertraulichkeit und Authentizität) und damit auch alle Blockchiffren im CBC-Modus, einem unsicheren Chiffrierblockverkettungsmodus. TLS 1.3 schafft zudem die TLS-Kompression ab, denn sie hat sich mit Cross-Layer-Protokollattacken wie CRIME als verwundbar erwiesen.
Nach den Erfahrungen mit früheren Exploits hat die IETF offenbar viel Wert darauf gelegt, Manipulationsversuche im Keim zu ersticken. So ist die Neuverhandlung (Renegotiation) der Protokollversion erstmals prinzipiell ausgeschlossen. Wurde TLS 1.3 bereits ausgehandelt und sollte ein neues ClientHello eine andere Version anfordern, bricht der Server die Verbindung mit einer „unexpected_message“-Meldung ab. Auch ein nachträgliches Protokoll-Upgrade von einer niedrigeren Version auf TLS 1.3 ist unzulässig.
Neue Chiffre-Suites
TLS erfüllt drei primäre Aufgaben: Es authentifiziert die Kommunikationsparteien, zeichnet für die Transportdatenverschlüsselung verantwortlich und stellt die Integrität der übertragenen Daten sicher. Die Gewährleistung der Manipulationssicherheit ist bei TLS dementsprechend ein recht verzwicktes Problem.
Um die Authentizität, Vertraulichkeit und Nachrichtenintegrität zu gewährleisten, müssen die beiden legitimen Kommunikationsteilnehmer vor dem Aufbau eines sicheren TLS-Kanals eine Reihe von Sicherheitsparametern aushandeln. Die Algorithmen, die hierbei zum Einsatz kommen, werden als Chiffren bezeichnet. Eine Zusammenstellung der Sicherheitsparameter für die zu verwendenden Chiffren bildet eine sogenannte Chiffre-Suite.
In TLS 1.2 setzte sich eine Chiffre-Suite aus den Algorithmen der Schlüsselvereinbarung, der Authentifizierung, der symmetrischen Chiffre der Verbindungsabsicherung (gegebenenfalls unter Angabe des Betriebsmodus) und dem MAC-Verfahren zusammen. Der neue Aufbau einer Chiffre-Suite in TLS 1.3 trennt die Authentifizierungs- und Schlüsselaustauschverfahren von dem Algorithmus der Verbindungsabsicherung (TLS Record Protection Algorithm) und der Hashfunktion. Die Hashfunktion kommt mit der Schlüsselableitungsfunktion (Key Derivation Function) und (H)MAC (Hash-based Message Authentication Code, Hash-basierter Nachrichtenauthentifizierungscode) zum Einsatz. Eine Cipher-Suite in TLS 1.3 gibt somit weder den Schlüsselaustausch- noch den Authentifizierungsmechanismus vor; bei beiden Algorithmen handelt es sich um vereinbarte Optionen. Der neue Aufbau einer Chiffre-Suite ermöglicht Forward Secrecy trotz 0-RTT (Zero Round Trip Time Resumption zwecks beschleunigter Wiederaufnahme einer zuvor aufgebauten Verbindung).