Risiken der TLS-Sitzungswiederaufnahme TLS Session Resumption schafft Schlupflöcher

Anbieter zum Thema

SEPPmail - Deutschland GmbH

Specops Software GmbH

Venafi Inc.

Im Januar hat sie NSA eine Windows-Schwachstelle an Microsoft gemeldet, mit der ein Angreifer eine Malware so signieren kann, dass ein Benutzer keine Möglichkeit hat, die Datei als bösartig zu erkennen, da die digitale Signatur scheinbar von einem vertrauens­würdigen Anbieter stammt. Jedes Windows-Gerät verlässt sich auf das Vertrauen, das durch TLS und Code Signing-Zertifikate, aufgebaut wird – zurecht?

Mit dem Patchday vom Januar 2020 hat Microsoft einen Patch für einen großen Kryptographie-Fehler veröffentlicht. Die fragliche Sicherheitslücke lag in einer Windows-Komponente namens crypt32.dll, einem Windows-Modul, das laut Microsoft „Zertifikats- und kryptografische Nachrichtenfunktionen in der CryptoAPI“ handhabt. Gemeldet wurde die Schwachstelle Microsoft übrigens vom US-amerikanischen Geheimdienst NSA!

Microsoft hatte darüber informiert, dass ein Angreifer die Sicherheitslücke ausnutzen könnte, indem er ein gefälschtes Code-Signatur-Zertifikat zum Signieren einer bösartigen ausführbaren Datei verwendet, so dass der Eindruck entsteht, die Datei stamme aus einer vertrauenswürdigen, legitimen Quelle. Der Benutzer hätte keine Möglichkeit, die Datei als bösartig zu erkennen, da die digitale Signatur scheinbar von einem vertrauenswürdigen Anbieter stammt. Angreifbar sind diese Verbindungen dann beispielsweise über eine Man-in-the-Middle-Attacke.

Jedes Windows-Gerät verlässt sich auf das Vertrauen, das durch TLS und Code Signing-Zertifikate (Maschinenidentitäten), aufgebaut wird. Wenn sie diese Identitäten brechen, können die Devices nicht mehr zwischen Malware und Microsoft-Software unterscheiden. Durch die weite Verbreitung ist letztlich jede Schwachstelle im Kernstück von Windows ernst zu nehmen. Zusätzlich zu den eigenen Zertifikaten sind in Windows Hunderte von Zertifizierungsstellen installiert. Leider ist vielen Organisationen die Anzahl der Zertifikate auf ihrem System völlig unbekannt, und Cyberangreifer nutzen dies aus. Die Schwachstellen sollten uns an das blinde Vertrauen erinnern, das wir in die Kryptographie und in Maschinenidentitäten haben. Sicherheitsteams brauchen Transparenz, Intelligenz und Automatisierung, um zu wissen, wo ihre Maschinenidentitäten sind und um sie ändern zu können.

Grundlagen I: Was ist TLS

Zunächst noch einmal zur Wiederholung ein paar Grundlagen von TLS Sessions. Das TLS-Protokoll erbringt allen Anwendungen, die über ihm angesiedelt sind, drei wesentliche Dienste: Verschlüsselung, Authentifizierung und Datenintegrität. Ein Server erstellt für jede TLS-Verbindung eine Sitzung. Zur Erstellung einer Sitzung müssen zusätzliche Daten ausgetauscht werden, zum Beispiel digitale Zertifikate und kryptographische Schlüssel; erst dann können die eigentlichen Webdaten ausgetauscht werden. Der Aufbau einer TLS-Sitzung wird als Handshake bezeichnet.

Grundlagen II: TLS-Handshake

Bevor der Client und der Server mit dem Austausch von Anwendungsdaten via TLS beginnen können, muss der verschlüsselte Tunnel ausgehandelt werden: Client und Server müssen sich über die Version des TLS-Protokolls einigen, das Verschlüsselungsprotokoll wählen und gegebenenfalls Zertifikate überprüfen. Leider macht jeder dieser Schritte neue Paket-Roundtrips zwischen dem Client und dem Server erforderlich, was die Latenz beim Aufbau von TLS-Verbindungen erhöht.

Eine neue TLS-Verbindung erfordert zwei Roundtrips für einen kompletten Handshake. In der Praxis können optimierte Implementierungen den Prozess allerdings beschleunigen, sodass nur noch ein Roundtrip nötig ist, um einen TLS-Handshake abzuschließen. Ein solches optimiertes Verfahren wird angewandt, wenn der Client zuvor bereits mit dem Server kommuniziert hat. In diesem Fall kann ein „verkürzter Handshake“ durchgeführt werden, der nur einen Roundtrip benötigt und dem Client und dem Server zudem ermöglicht, die CPU-Belastung zu verringern, indem die zuvor bereits ausgehandelten Parameter für die sichere Sitzung erneut verwendet werden. Diese Technik wird als TLS Session Resumption (TLS-Sitzungswiederaufnahme) bezeichnet.

TLS Session Resumption

Die zusätzliche Latenzzeit und die CPU-Kosten bei einem kompletten TLS-Handshake bedeuten eine ernsthafte Leistungseinbuße für alle Anwendungen, die eine sichere Kommunikation erfordern. TLS Session Resumption bietet einen Mechanismus, um die bereits ausgehandelten Secret-Key-Daten über mehrere Verbindungen hinweg wieder aufzunehmen oder zu teilen, wodurch sich die Kosten verringern. Die Sitzungswiederaufnahme ist ein wichtiges Verfahren zur Performance-Optimierung. Der verkürzte Handshake halbiert die Verschlüsselungslatenz um einen kompletten Roundtrip und reduziert die CPU-Kosten für beide Seiten erheblich. Die TLS Session Resumption kann entweder mit Sitzungskennungen oder mit Sitzungstickets implementiert werden; TLS 1.3 verwendet zum Beispiel Pre-Shared-Keys (PSK).

Transportverschlüsselung Teil 1

TLS 1.3 - Viel heiße Luft oder ein großer Wurf?

Sitzungskennungen

Bei dieser Methode vergibt der Server beim ersten Handshake mit dem Browser (Client) eine zufällige Sitzungs-ID. Client und Server speichern diese Sitzungs-ID zusammen mit den Sitzungsschlüsseln und den Verbindungszuständen. Um eine Sitzung wiederherzustellen, sendet der Client die gespeicherte Sitzungs-ID mit der ersten Protokollnachricht (ClientHello) an den Server. Wenn der Server die Verbindung erkennt und zur Wiederaufnahme der Sitzung bereit ist, antwortet er mit der gleichen Sitzungs-ID, um die betreffende Sitzung wiederaufzubauen. So lässt sich eine sichere Verbindung schnell und ohne Sicherheitsdefizite fortsetzen, da die zuvor ausgehandelten Sitzungsdaten wiederverwendet werden.

Eine der Einschränkungen des Session-ID-Mechanismus in der Praxis ist allerdings, dass der Server dabei für jeden Client einen Sitzungscache anlegen und verwalten muss. Dies führt bei einem Server, über den täglich Zehntausende oder sogar Millionen einzelner Verbindungen laufen, zu mehreren Problemen: Jede offene TLS-Verbindung verbraucht Speicher; ein Session-ID-Cache und Eviction Policies werden benötigt; und es kann Schwierigkeiten bei der Bereitstellung populärer Websites mit vielen Servern geben, die idealerweise einen gemeinsamen TLS-Sitzungscache verwenden sollten, um die Leistung zu optimieren. Daher erfordern Sitzungskennungen in Multi-Server-Szenarien einige Überlegung und eine durchdachte Systemarchitektur, um einen gut funktionierenden Session-Cache zu gewährleisten.

Sitzungstickets

Um diesen Problemen bei der serverseitigen Zwischenspeicherung von TLS-Sitzungen zu begegnen, wurden als alternatives Verfahren Sitzungstickets (RFC 5077) eingeführt, bei denen der Server nicht für jeden Client den Sitzungsstatus speichern muss. Stattdessen kann er, wenn der Client angibt, dass er Sitzungstickets unterstützt, ein Sitzungsticket senden: einen Datensatz, der alle ausgehandelten Sitzungsdaten enthält und mit einem geheimen, nur dem Server bekannten Schlüssel verschlüsselt ist.

Dieses Sitzungsticket wird dann vom Client gespeichert und kann in die Handshake-Nachricht einer nachfolgenden Sitzung eingefügt werden. Alle Sitzungsdaten werden also nur auf dem Client gespeichert, doch das Ticket ist trotzdem sicher, da es mit einem Schlüssel verschlüsselt wird, den nur den Server kennt.

Der Mechanismus mit Sitzungstickets wird als zustandsloser Wiederaufnahme-Mechanismus bezeichnet. Die wichtigste Verbesserung ist dabei der Verzicht auf einen serverseitigen Sitzungscache, der das Verfahren vereinfacht. Stattdessen muss der Client bei jeder neuen Verbindungsaufnahme mit dem Server das Sitzungsticket präsentieren, so lange, bis es abgelaufen ist.

Pre-Shared Keys (PSK)

In TLS 1.3 werden die Sitzungskennungen und -tickets durch das Konzept der Sitzungswiederaufnahme über Pre-Shared Keys (PSK) ersetzt. Nach dem ersten Handshake sendet der Server eine PSK-Identität an den Client. Deren Inhalt hängt vom Server ab und kann einen Schlüssel zur Datenbanksuche oder ein selbst verschlüsseltes und selbst authentifiziertes Ticket umfassen. Der Client speichert diese PSK-Identität zusammen mit seinen eigenen Sitzungsschlüsseln.

Bei einem nachfolgenden Handshake präsentiert der Client in der ClientHello-Nachricht dem Server diese PSK-Identität. Abhängig vom Inhalt der PSK-Identität entschlüsselt der Server entweder das Ticket und verwendet die enthaltenen Sitzungsschlüssel und Verbindungszustände, um die Sitzung fortzusetzen, oder er verwendet den enthaltenen Nachschlagschlüssel, um die Sitzungsschlüssel und Verbindungszustände in seiner eigenen Datenbank zu finden.

Transportverschlüsselung Teil 2

Webmaster in der HTTPS-Pflicht

Probleme bei Datenschutz und IT-Sicherheit

Leider sind Sicherheit und Nützlichkeit in den meisten Fällen umgekehrt proportional. Am 18. Dezember 2018 veröffentlichten Sicherheitsforscher der Universität Hamburg ein Paper, das eine neue Methode beschreibt, mit der Websites den Browserverlauf von Nutzern verfolgen können. Die beschriebene Technik nutzt die im TLS-Protokoll implementierte Funktion zur Sitzungswiederaufnahme aus.

Eine Sitzung hat eine festgelegte maximale Dauer, die einige Minuten bis hin zu mehreren Stunden betragen kann. Wenn der Browser einen Server innerhalb eines Sitzungsfensters erneut besucht, kann die laufende TLS-Sitzung mit einer einzigen Wiederherstellungsanfrage fortgesetzt werden, statt dass erneut ein vollständiger Handshake ausgeführt werden muss.

Da eine TLS-Sitzungswiederaufnahme eindeutig an einen bestimmten Browser gebunden ist, kann sie dazu genutzt werden, Benutzer auf die gleiche Weise zu verfolgen wie mit Cookies. Auf einen Nenner gebracht: Die Website kann bei der Wiederaufnahme einer Sitzung durch einen Browser die Verbindung mit derjenigen Verbindung korrelieren, bei der die Sitzung ursprünglich erstellt wurde. Dies gilt auch dann, wenn der Benutzer aus einem anderen Netzwerk kommt (d. h. mit einer anderen IP-Adresse) oder andere Datenschutzeinstellungen verwendet (z. B. User-Agent).

Mit der oben beschriebenen Methode kann jeder einzelne Benutzer (maximal) mehrere Stunden lang verfolgt werden, ja nach Länge des ausgehandelten Sitzungsfensters. Eine Website kann jedoch die Sitzung bei jeder Sitzungswiederaufnahme um einen weiteren Zeitraum erneuern, das Sitzungsfenster zurücksetzen und die Lebensdauer der Sitzung somit quasi auf unbestimmte Zeit verlängern. Das Paper bezeichnet diese Technik als Verlängerungsangriff.

Gefahr Verlängerungsangriffe (prolongation attack)

Die Forscher zeigten, dass mit dieser Technik 65 Prozent der Benutzer in ihrem Datenbestand permanent verfolgt werden können, da diese Benutzer dazu neigen, die verfolgenden Websites öfter zu besuchen, als die Sitzungen ablaufen. Die Forscher kommen zu folgendem Schluss: Die Ergebnisse zeigen, dass es mit der standardmäßig eingestellten Lebensdauer der Sitzungswiederaufnahme in vielen aktuellen Browsern möglich ist, den durchschnittlichen Benutzer bis zu acht Tage lang zu verfolgen.

Transportverschlüsselung Teil 3

HTTPS mit TLS 1.3 in der Praxis

Fazit

Diese hypothetische Schwäche zu beheben wird nicht einfach sein. Die Browser-Anbieter könnten die Lebensdauer von Sitzungskennungen verringern oder sogar ganz auf sie verzichten, was aber die Performance beeinträchtigen könnte. Eine andere Lösung könnte darin bestehen, die Session Resumption nur für Erst-, nicht aber für Dritt-Domains zu erlauben. Dies würde jedoch unweigerlich als Anschlag auf den Datenverkehr und die Latenzzeit angesehen werden, da die meisten Websites zahlreiche HTTPS-TLS-Verbindungen zu Dritt-Domains herstellen.

TLS Session Resumption wird daher leider noch eine ganze Zeit lang ein Problem bleiben. Dass TLS-Verbindungen und Codesignaturen generell angreifbar sind hat nicht zuletzt die eingangs erwähnte, von der NSA gemeldete Schwachstelle in Windows gezeigt und sollte alle Unternehmen und Verantwortlichen daran erinnern, dass sie Transparenz, Intelligenz und Automatisierung benötigen, um zu wissen, wo sich ihre Maschinenidentitäten befinden, und um die Möglichkeit zu haben, sie schnell und unkompliziert zu ändern, wenn es nötig ist.

Über den Autor: Kevin Bocek ist VP Security Strategy & Threat Intelligence bei Venafi.

(ID:46360914)