Transportverschlüsselung Teil 1 TLS 1.3 - Viel heiße Luft oder ein großer Wurf?

Die Bedeutung der Datenverschlüsselung hat in den vergangenen Jahren massiv zugenommen. Beim Entwurf von TLS 1.3 bestand das Ziel darin, der aufkeimenden Bedrohung durch das Quantencomputing mit einer anspruchsvolleren Verschlüsselung gegenzusteuern, ohne dabei die User-Agents zu überfordern und gleichzeitig eine höhere Performance für latenzsensible IoT-Anwendungen zu liefern.

Anbieter zum Thema

SEPPmail - Deutschland GmbH

FTAPI Software GmbH

Das Aufkommen von Quantencomputern und fallende Kosten für massive Rechenleistung aus der Cloud haben der Notwendigkeit für ein neues Transportprotokoll eine gewisse Dringlichkeit verliehen. Nach den medienwirksamen HTTPS-Hacks der vergangenen Jahre fiel das Vertrauen in bestehende Standards ohnehin ja schon ins Bodenlose.

Mit dem Inkrafttreten der GDPR werde es mit dem Datenschutz jetzt aber wirklich ernst, warnen Experten wie Prof Bill Buchanan OBE, PhD, FBCS. Eine groß angelegte Datenschutzverletzung würde nicht „nur“ einen Vertrauensverlust bedeuten, sondern auch hohe Geldstrafen nach sich ziehen, argumentiert er weiter.

Bildergalerie

Alarmstufe „(GDPR-)rot“

Die Liste wirksamer Exploits gegen TLS (Transport Layer Security), das Protokoll der Transportebene in HTTPS, umfasst inzwischen: Poodle, BEAST, CRIME, BREACH, DROWN und neuerdings ROBOT, von den verschiedenen Downgrade-Attacken wie FREAK und Logjam ganz zu schweigen. Die Liste nimmt scheinbar kein Ende und es kommen ständig neue Überraschungen hinzu — wie eben ROBOT.

Bei ROBOT handelt es sich um eine neue Iterationsstufe einer knapp 20-Jahre alten Attacke. Sie wurde gerade im Dezember des vergangenen Jahres (2017) erneut nachgewiesen.

Zwischendurch gab es ja auch noch Heartbleed, doch diese Angriffstaktik zielte auf einen Bug in der OpenSSL-Bibliothek ab, der inzwischen mit einem Softwareupdate behoben wurde. Die anderen Exploits nutzen aber persistente Verwundbarkeiten des TLS-Protokolls und lassen sich mit einer bloßen Softwareaktualisierung nicht verhindern.

Die verschiedenen Exploits können, soweit bekannt, mittlerweile alle Versionen des TLS-Protokolls kompromittieren, mit der lobenswerten Ausnahme von TLS 1.2 unter Einhaltung bestimmter Voraussetzungen. Gemeint ist hierbei eine spezielle Konfiguration, welche die bekannten Sicherheitslücken schließt und vor Attacken wie SLOTH (gegen TLS 1.2 beim Einsatz von RSA-MD5-Signaturen) schützt.

Bei der HTTPS-Kommunikation auf die Angriffsbeständigkeit von TLS 1.2 zu wetten ist auf die Dauer also kein Erfolgsrezept.

Die Mehrzahl aller Web-Server ist zudem ja noch falsch konfiguriert. Der Einsatz veralteter Versionen des TLS-Protokolls, die Zulassung von Versions-Downgrades und unsicheren Cypher-Suites sind nach wie vor an der Tagesordnung.

Sogar einige der größten IT-Firmen kriegen eine korrekte TLS-Konfiguration nicht auf die Reihe. Alleine durch ROBOT waren bis vor kurzem noch 27 der ersten top 100 Websites im Alexa-Ranking verwundbar. Eine neue Version des TLS-Protokolls ist also wirklich längst überfällig.

Die Hoffnungen in Bezug auf TLS 1.3 sind also recht hochgesteckt. Angesichts der drakonischen Strafen für Datenschutzverletzungen im Rahmen der GDPR dürfte ja auch der Wille, die Sicherheitsschraube anzudrehen, in den Chefetagen mittlerweile vorhanden sein.

Für die IT-Verantwortlichen stellt sich jetzt nur noch die Frage, was TLS 1.3 bringt und ob es den Aufwand lohnt.

Post-Quantum-Kryptographie

Die Zukunft der Kryptographie im Zeitalter der Quanten

Neuerungen in TLS 1.3 auf einen Blick

Beim Entwurf von TLS 1.3 bestand das Ziel darin, der aufkeimenden Bedrohung durch das Quantencomputing eine anspruchsvollere Verschlüsselung gegenzusteuern, ohne dabei die User-Agents zu überfordern und gleichzeitig eine höhere Performance für latenzsensible IoT-Anwendungen zu liefern. Lange Zeit klangen die Wünsche der IETF-Entwickler wie die sprichwörtliche „Quadratur des Kreises“.

Die wichtigsten Neuerungen in TLS 1.3 ließen sich etwa wie folgt zusammenfassen:

• AEAD (Authenticated Encryption with Associated Data, eine verbesserte Variante von AE) ist Pflicht: Diese Kategorie von Betriebsmodi von Blockchiffren gewährleistet neben Vertraulichkeit auch Integrität und Authentizität der Daten.

• der Verzicht auf problematische Altlasten reduziert das Potenzial für Konfigurationsfehler: TLS 1.3 legt u.a. SHA-1, RC4, DES, 3DES, AES-CBC, MD5 zu den Akten. Weggefallen sind außerdem Komprimierung (zum Schutz vor der CRIME-Attacke auf die Kompressionsrate), benutzerdefinierte DHE-Gruppen (auf Grund möglichen Missbrauchs durch abstreitbare Diffie-Hellman-Hintertüren, Engl. „deniable backdoors“) und der DSA-Signaturalgorithmus.

• der Wegfall eines Roundtrips (aus 2-RTT wird 1-RTT und aus 1-RTT wird 0-RTT) senkt die Server-Belastung, verringert die Latenz und verbessert die Performance: Im Schnitt können so gut hundert Millisekunden pro Roundtrip wegfallen

• neue Chiffre-Suiten beschränkten die Verwundbarkeiten auf ein kurzes Zeitfenster eines TLS-Handshake innerhalb von maximal einem einzigen Roundtrip; Curve25519 in ECDH beschleunigt den Schlüsselaustausch und reduziert die Latenz

Zwei grundlegende Neuerungen verdienen eine besondere Bedeutung: Vorwärtsgeheimhaltung (Engl. forward secrecy) und ephemere Schlüssel.

Doch TLS 1.3 hat auch einige Kritiker. Die größten Sorgen bereitet den Sicherheitsexperten ein Feature namens 0-RTT Resumption.

Bildergalerie

Partielle Forward-Secrecy

Beim ersten Verbindungsaufbau über TLS 1.3 einigen sich die Kommunikationspartner auf einen so genannten PSK (pre-shared key, also einen Wiederaufnahmeschlüssel). Ein Client, der sich in der Vergangenheit mit dem Server bereits verbinden konnte, darf so die verschlüsselte Kommunikation unter Verwendung des PSK mit 0-RTT wiederaufnehmen („0-RTT Resumption“). Der Verzicht auf ein erneutes Handshake ist ein Zugeständnis an die Anforderungen latenzsensibler IoT-Endgeräte.

Die niedrige Latenz wird mit dem Preis einer nur partiellen Forward-Secrecy erkauft. Sollte das Session-Ticket in TLS 1.3 kompromittiert werden, würde die Forward-Secrecy wegfallen. Ein Angreifer könnte mit einem gestohlenen STEK-Schlüssel (Session Ticket Encryption Key) das Session-Ticket entschlüsseln, dadurch an den Pre-Shared-Key gelangen und die Client-Daten aus dem Zeitraum des 0-RTTs entschlüsseln. Die restliche Kommunikation wäre aber nicht gefährdet, denn hierfür kommt ja in TLS 1.3 ein neuer Session-Ticket-Key zum Einsatz.

Trotzdem ist sogar das 0-RTTs-Resumption-Szenario als ein Fortschritt gegenüber TLS 1.2 zu werten. Bei der Wiederaufnahme einer Sitzung in TLS 1.2 erfolgt gar kein Diffie-Hellman-Austausch und damit entfällt jegliche Forward-Secrecy. Ein Angreifer im Besitz eines STEK-Schlüssels kann beim Einsatz von TLS 1.2 den gesamten Ablauf der (zuvor aufgezeichneten) Kommunikation der aktuellen Sitzung rückwirkend entschlüsseln. Als Workaround kursierte zeitweise die Empfehlung, die STEKS periodisch zu vernichten, doch diese Maßnahme ist nur bei zustandslosen Server-Architekturen realistisch umsetzbar. Ansonsten müssen die Tickets nämlich zwischen mehreren Servern — via Netzwerk wohlgemerkt — periodisch synchronisiert werden, um den aktuellen Zustand der Sitzung zu propagieren. Dieser Abgleich führt das ganze Sicherheitskonzept in TLS 1.2 natürlich ad absurdum. Doch damit nicht genug: Ein Session-Ticket beinhaltet den ursprünglichen STEK-Schlüssel; wird ein Session-Ticket kompromittiert, kann der Angreifer mit dem so gewonnenen STEK-Schlüssel nicht nur die aktive, sondern auch die ursprüngliche Sitzung rückwirkend entziffern. Da ein Session-Ticket in TLS 1.2 im Klartext übermittelt wird, ist das Szenario eines gestohlenen STEK-Schlüssels gar nicht so unwahrscheinlich. In TLS 1.3 werden Session-Tickets und ihre STEK-Keys erstmals verschlüsselt übertragen.

Forward-Secrecy ist ein Konzept von enormer Tragweite. Das ROBOT-Exploit kann beispielsweise beim Einsatz von RSA-basierten Ciphermodi im Rahmen der Verschlüsselung zuvor aufgezeichnete Daten rückwirkend entschlüsseln. Um die Angriffsfläche zu minimieren empfiehlt es sich, einen Schlüsselaustauschalgorithmus mit Forward-Secrecy zu nutzen; in diesem Szenario müsste der Angreifer die gesamte Attacke während des Handshake erfolgreich abschließen, üblicherweise in einem Zeitfenster im Millisekunden-Bereich und nur wenn der Server den verwundbaren RSA-Modus nutzt.

„In Zukunft müssen wir standardmäßig [alles] verschlüsseln und unsere Kommunikationsverbindungen auf die Identität der Gegenseite und die Vertrauenswürdigkeit hin überprüfen“, urteilt Prof Buchanan.

Neue Algorithmen gegen Quantencomputer

Verschlüsselung in Zeiten der Post-Quantum-Kryptographie

Fazit

In allen bisherigen Versionen von TLS waren Sicherheitsprobleme quasi vorprogrammiert. Im GDPR-Zeitalter können sich Unternehmen den Luxus grober Fahrlässigkeit im Umgang mit sensiblen Daten nicht mehr leisten. TLS 1.3 kommt da wie gerufen.

Die Version 1.3 des TLS-Protokolls schneidet nicht nur alte Zöpfe ab und führt lange überfällige Neuerungen ein, sondern setzt sich von ihren Vorgängern durch eine ansehnliche Dosis an gesundem Menschenverstand ab.

Auf IT-Administratoren und IT-Sicherheitsspezialisten kommt neue Arbeit zu: die Umstellung auf HTTPS mit TLS 1.3.

Über die Autoren: Filipe Pereira Martins und Anna Kobylinska von McKinley Denali Inc. sind als IT-Consultants auf Cybersecurity spezialisiert und sind für die Leser auf Twitter via @RealPro4Real, @CloudInsidr und @D1gitalInfo erreichbar.

(ID:45290467)