zurück zur Übersicht

TLS 1.3: schneller, sicherer & in den Startlöchern!

Sicherer Transport von Datencontainern: TLS 1.3 verbessert die Grundlage sicherer Onlinekommunikation

Motivation

Die allgemein bekannteste Anwendung des Transportprotokolls Transport Layer Security (TLS) dürfte die Übertragung von Hypertext Transfer Protocol (HTTP) über TLS sein – HTTPS.

Jeder kennt und sieht mehrfach täglich die typischen Vorhängeschloss-Icons in Adressleisten von Webbrowsern. Es bedeutet, dass sichergestellt ist: Die Seite ist wirklich die für die sie sich ausgibt, und die Kommunikation mit der Webseite ist geschützt.

Meta

Der TLS-Standard wird von der Internet Engineering Task Force (IETF) veröffentlicht und von einer untergeordneten Arbeitsgruppe „IETF TLS Working Group“ (TLSWG) entworfen. Der aktuelle Stand der Entwicklung ist TLS 1.3 Entwurf Nummer 18. Ein erwarteter Fertigstellungszeitpunkt ist schon Ende 2016. Der Arbeitsbereich der TLSWG für den Entwurf ist öffentlich zugänglich und jedermann ist eingeladen, seine Ideen beizutragen, um den endgültigen Standard zu verbessern. Für größere und breite Diskussionen dient die TLSWG-Mailingliste.

TLS 1.3 ist gegenüber dem Vorgänger TLS 1.2 ein deutlicher Funktionssprung. In den vergangenen Versionen von TLS 1.0 bis TLS 1.2 wurden nur Kleinigkeiten korrigiert. Möglicherweise wird der Name des endgültigen Standards daher TLS 2.0 sein.

Verbesserungen

Eine Auswahl der bedeutendsten Verbesserungen:

  • Reduktion der nötigen Roundtrips (RTT) …
    • … beim initialen Verbindungsaufbau von zwei auf nur einen („1-RTT“). In diesem „Handshake“ findet ein Abgleich von TLS-Version und Kryptoparametern zwischen Client und Server statt.
    • … beim Verbindungswiederaufnehmen – also falls bereits kürzlich eine Verbindung zwischen diesen Partnern bestand – sogar von einem auf null („0-RTT“). Schlüsselelement hierfür ist die Integration des clientseitigen Schlüsselteils für den Diffie-Hellman-Schlüsselaustausch (DHKE) direkt mit dem ersten Datenpaket. Dies bedeutet, dass gegenüber Klartext-Übertragung kein Overhead in RTT-Größenordnung mehr besteht!
  • Verschlanken der vielen TLS-Möglichkeiten für weniger Angriffsfläche. Bugs, die auf unwichtigen, leicht ersetzbaren oder selten genutzten Funktionen basieren, sind wohlbekannt – der Heartbleed-Bug von OpenSSL ist nur ein Vertreter von Angriffen auf TLS-geschützte Verbindungen, die hierdurch verhindert worden wären.
    • Entfernen von unnötigen Verschlüsselungsmodi: Statt dem CBC-Modus und MAC-then-encrypt kann Authenticated Encryption with Associated Data (AEAD) – beispielsweise AES im Galois/Counter Mode (GCM) – verwendet werden.
    • Entfall des statischen RSA-Schlüsselaustauschs: Stattdessen kann DHKE verwendet werden.
    • Entfall von Kompression – verantwortlich für den CRIME-Angriff
  • Entfall von mittlerweile als unsicher geltenden Algorithmen: RC4, SHA1, MD5
  • Obligatorische Perfect Forward Secrecy (PFS) durch den Entfall des statischen RSA-Schlüsselaustauschs
  • TLS-1.2-Downgradeschutz im Zusammenspiel mit TLS-1.3-kompatiblem Server und Client ermöglicht es, dass TLS-1.3-Server dennoch weiterhin TLS 1.2 für Clients unterstützen, die wirklich kein TLS 1.3 unterstützen.
  • Verhindern von Hintertüren durch vordefinierte Primzahlen für den DHKE. Bestimmte Primzahlen ermöglichen eine deutlich schnellere Ausführung von Algorithmen zur Berechnung des diskreten Logarithmus, was den DHKE kompromittiert. Ein Angreifer (beispielsweise ein Geheimdienst) könnte darauf hinwirken, dass eine Implementierung oder Standard bestimmte Primzahlen verwendet, für die er Informationen hat, die das Brechen erleichtern. TLS 1.3 sieht vor, dass nur noch bestimmte Primzahlen nach RFC 7919 verwendet werden. Diese Primzahlen wurden von der Eulerschen Zahl (e) abgeleitet („nothing-up-my-sleeve“).

Mögliche Herausforderungen

Eine Auswahl der bedeutendsten Herausforderungen:

  • Der neue Verbindungsaufbau mit 0-RRT und 1-RTT ist viel schneller, aber eventuell auch nicht so sicher?
    • Bekannt, klar und nicht schwerwiegend ist, dass eine per 0-RTT-aufgebaute Verbindung durch fehlenden erneuten DHKE keine PFS gegenüber Kompromittierung des verwendeten Session-Keys bietet. Daher sollte der Session-Key nicht über einen langen Zeitraum weiterverwendet werden, sondern periodisch (beispielsweise stündlich) gewechselt werden. Zu bedenken ist, dass auch TLS 1.2 keine PFS bei Verwendung von Wiederaufnahme per Session Tickets bietet.
    • Kritischer ist, dass das erste Paket einer 0-RTT-Verbindung nicht vor Replay-Angriffen geschützt ist. Es darf daher nur für nicht-verändernde Anfragen (beispielsweise HTTP GET bei einer HTTPS-Verbindung) an den Server zu akzeptieren. Stellt ein Client eine verändernde Anfrage per erstem 0-RTT-Paket an den Server, so muss der Server einen vollen 1-RTT-Handshake erzwingen.
  • Durch Wegfall des statischen RSA-Schlüsselaustauschs sind die Verbindungen nicht so simpel wie bisher für Mitlesen des TLS-Traffics durch Netzwerküberwachungsgeräte zugänglich (beispielsweise für Malwareerkennung, Data Loss Prevention oder Mitarbeiterüberwachung). Einige Anwender dieser Technologien äußern sich entsprechend besorgt. Der Wegfall des statischen RSA-Schlüsselaustauschs wird aber erneut mit guten Argumenten verteidigt.

Fazit

Die große Überarbeitung nach dem KISS-Prinzip zieht deutliche Lehren aus den bekannt gewordenen, teilweise sehr schwerwiegenden Angriffen auf die vorherigen TLS-Versionen und bereitet so eine Grundlage für eine sicherere Zukunft.

Weitere Quellen

Schreibe einen Kommentar