TLS Session resumption erklärt (Caching + Tickets)

In diesem Artikel erklären wir zwei standardisierte Mechanismen, um eine SSL-Sitzung wieder aufzunehmen: Session resumption Tickets (=Sitzungstickets, RFC 5077) und Session resumption ID/Caching (=Sitzungs-IDs, RFC 5246).

Beim Aufruf einer Webseite über https erfolgt ein sog. TLS/SSL Handshake. Dabei wird das Zertifikat geprüft und die Details der Verbindung zwischen dem Server und dem Client werden ausgehandelt. Zu diesen Sicherheits-Parametern zählen beispielsweise die beiderseitig unterstützten SSL-Ciphern. Ein solcher Handshake besteht in der Regel aus 4 Phasen (vgl. de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol).

Spätestens wenn Sie den Browser schließen wird auch die Verbindung beendet. Ebenfalls existiert meist eine maximale Zeitdauer, wie lange eine Verbindung zwischen den Beteiligten aktiv bleibt und bei Untätigkeit über diesen Zeitraum hinaus beendet wird. Dies kann auch schon beim Wechsel in einen anderen Browser-Tab erfolgen. Sobald dann eine Aktion auf der ursprünglichen Seite vorgenommen wird, erfolgt ein neuer TLS-Handshake. Die Zeit, die dafür jeweils verwendet wird, ist zwar nur sehr kurz, summiert sich aber auf Dauer. Es gibt daher verschiedene Verfahren, um keinen kompletten Handshake ausführen zu müssen und eine zuvor ausgehandelte erfolgreiche Sitzung schneller wieder aufzunehmen. Es handelt sich also um eine Performance-Steigerung.

Session resumption mit ID

Das Fortsetzen einer verschlüsselten Sitzung über eine sog. Sitzungs-ID bedeutet, dass der Server kürzlich ausgehandelte Sitzungen mit eindeutigen Sitzungs-IDs verfolgt. Dies geschieht, damit der Server die Sitzungsschlüssel schnell nachschlagen und die verschlüsselte Kommunikation fortsetzen kann, wenn ein Client eine Verbindung mit einem Server mit einer Sitzungs-ID herstellt.

Die Zeit, die für die Wiederaufnahme der Sitzung benötigt wird, liegt unter 50% eines vollständigen TLS-Handshakes. Darüber hinaus sind deutlich weniger Berechnungen über die CPU notwendig, so dass die CPU-Kosten für den Client im Vergleich zu einem vollständigen TLS-Handshake nahezu vernachlässigbar sind. Für mobile Benutzer bedeutet diese Leistungsverbesserung ein gefühlt schnelleres und flüssigeres Surf-Erlebnis.

Session resumption mit Ticket

Die Sitzungswiederherstellung mit den genannten Sitzungs-IDs weist allerdings eine große Einschränkung auf:
Die Server sind allein für die Verwaltung und korrekte Wiederherstellung der IDs verantwortlich. Dies führt zu Problemen bei der Skalierbarkeit wenn eine große Anzahl an gleichzeitigen Verbindungen pro Sekunde erfolgt, die verwaltet und deren Informationen längere Zeit zwischenspeichert und vorgehalten werden müssen.

Die Session Ticket resumption (=Sitzungsticket-Wiederaufnahme) soll dieses Problem beheben. Die Idee dahinter ist simpel, denn die Sessions werden einfach auf die Clients ausgelagert. Ein Sitzungsticket ist ein Datenobjekt eines Sitzungsschlüssels und aller zugehöriger Informationen, die mit einem Schlüssel verschlüsselt sind, der nur dem Server bekannt ist. Das Ticket wird am Ende des TLS-Handshakes vom Server gesendet. Clients, die Sitzungstickets unterstützen, werden dieses zusammen mit den aktuellen Sitzungsschlüsselinformationen zwischenspeichern. Später fügt der Client das Sitzungsticket dann wieder in die Handshake-Nachricht ein, um anzuzeigen, dass er die frühere Sitzung fortsetzen möchte. Der Server am anderen Ende kann dieses Ticket entschlüsseln, den Sitzungsschlüssel wiederherstellen und die Sitzung fortsetzen. Auch dabei wird deutlich Zeit eingespart.

Nachteil / Herausforderung

Einen Nachteil haben beide Optionen des Session resumption in Bezug auf die Sicherheit:

Die Daten der Sitzungs-IDs sollten nur für eine kurze Zeit gespeichert (gecached) werden. Ein Angreifer, der den Webserver kompromittiert, könnte den Speicher für die Session-IDs auslesen und damit einen zuvor aufgezeichneten Datenverkehr entschlüsseln.

Im Falle der Sitzungstickets ist der für die Verschlüsselung eingesetzte Schlüssel der Schwachpunkt. Sollte dieser gestohlen werden, könnte er zum Entschlüsseln des vom Server gesendeten Datenobjekts (oder vom Client bei der Wiederaufnahme der Session) verwendet werden. Mit den Informationen innerhalb eines Sitzungstickets kann ein Angreifer die eigentliche Kommunikation zwischen Client und Server dann leicht entschlüsseln.

Leider werden die Session-Tickets standardmäßig immer nur mit AES-128-CBC bzw. AES-256-CBC verschlüsselt und die Integrität mittels HMAC-SHA-256 geschützt. Selbst wenn grundsätzlich deutlich modernere und stärkere Algorithmen für die SSL/TLS-Verbindungen verwendet werden, wird die Sicherheit der Sitzungstickets reduziert.

Daher gilt, wie schon erwähnt, dass die Lebensdauer (Caching-Zeit) nicht zu lang ist. Auch sollte der Schlüssel für Session-Tickets regelmäßig geändert werden, z.B. alle 24 Stunden (Maximum laut RFC 5246 für TLS 1.2). Dann kann ein Angreifer der den Schlüssel erbeutet hat, maximal 24 Stunden der Netzwerkkommunikation entschlüsseln.

Twitter rotiert z.B. alle 12 Stunden den Schlüssel für die Verschlüsselung seiner Session-Tickets (Stand: 2013), Cloudflare sogar stündlich (Stand: 2015), hält allerdings für 18 Stunden die alten Ticket-Keys auf jedem Server vor.

Webseite / Server testen

Möchten Sie testen, welche Arten der Session resumption ihr Hosting-Anbieter unterstützt, so kann dafür beispielsweise der Online-Test von SSL Labs unter https://www.ssllabs.com/ssltest/ verwendet werden.

Das Ergebnis finden Sie unter den “Protocol Details” benannt mit ‘Session resumption (caching)’ sowie ‘Session resumption (tickets)’.