Security

Das ändert sich in der neuen TLS-Version

TLS 1.3: Neuer Standard für mehr Sicherheit
Keine Kommentare

Am 10. August 2018 wurde RFC 8446 mit der Beschreibung von TLS 1.3 offiziell veröffentlicht. Damit ist TLS 1.3 der offizielle Standard für die Transportverschlüsselung, und die neue Version bringt im Vergleich zum Vorgänger einige Neuerungen mit: Sie ist sowohl sicherer als auch performanter.

Im Folgenden gehe ich vom Einsatz in Verbindung mit HTTP aus. TLS 1.3 kann aber natürlich überall eingesetzt werden, wo auch SSL und TLS bis Version 1.2 verwendet werden können.

Der Verbindungsaufbau

Der RSA-Schlüsselaustausch wurde in TLS 1.3 gestrichen. Der symmetrische Sitzungsschlüssel muss immer über das Diffie-Hellman-Verfahren (möglichst über die Variante auf elliptischen Kurven, ECDHE) ausgetauscht werden. Das ist nicht viel aufwendiger als das RSA-Verfahren, aber deutlich sicherer, da man damit Forward Secrecy erreicht und eine nachträgliche Entschlüsselung verhindert wird [1].

Beim RSA-Verfahren hängt die Sicherheit aller übertragenen Nachrichten vom Serverschlüssel ab. Wer den kennt, kann damit einen aufgezeichneten RSA-Schlüsselaustausch und damit auch den Sitzungsschlüssel nachträglich noch entschlüsseln. Und danach dann mit dem Sitzungsschlüssel die restlichen aufgezeichneten Daten.

Beim DH-Verfahren ist das nicht möglich: Nachdem der mit dem DH-Verfahren ausgetauschte Sitzungsschlüssel nach Ende der Sitzung gelöscht wurde, gibt es keine Möglichkeit mehr, ihn aus den aufgezeichneten Daten neu zu berechnen. Und auch auf dem Server werden keine Daten gespeichert, aus denen sich der Sitzungsschlüssel nachträglich wiederherstellen lässt. Die einzige Ausnahme tritt beim Einsatz der 0-RTT-Resumption auf und betrifft nur den ersten vom Client gesendeten Request.

Prinzipiell könnte ein Man in the Middle (MitM) während des Verbindungsaufbaus separate Schlüssel mit Client und Server austauschen und dann die Nachrichten für sich ent- und für die Weiterleitung neu verschlüsseln. Das ist aber ein von Anfang an bekanntes Problem und lässt sich durch eine Signatur der ausgetauschten Daten verhindern; ein Verfahren, das im Rahmen von SSL und TLS schon immer im Einsatz war.

Verbindungsaufbau mit TLS 1.2 braucht zwei Round-Trips

Den Handshake zum Verbindungsaufbau zeigen Tabelle 1 für Version 1.2 und Tabelle 2 für TLS 1.3. In beiden Fällen habe ich das Ganze teilweise vereinfacht. Fangen wir mit TLS 1.2 an.

Schritt Client Richtung Server
1 Sendet:
ClientHello
Unterstützte Cipher Suites
2 Sendet:
ServerHello
Gewählte Cipher Suite
Key Share
Zertifikat & Signatur
3 Prüft Zertifikat, wenn OK:
Berechnet Sitzungs-schlüssel aus Key Share des Servers und eigenem
Key Share,
sendet:
Key Share
Finished
4 Berechnet Sitzungsschlüssel aus Key Share des Clients und eigenem Key Share,
sendet:
Finished
5 1. HTTP-Request
6 1. HTTP-Response

Tabelle 1: Der Handshake zum Verbindungsaufbau mit TLS 1.2

Dort läuft der Handshake folgendermaßen ab:

  • Schritt 1: Der Verbindungsaufbau beginnt, wenn der Client seine ClientHello-Nachricht an den Server sendet. Dabei werden dem Server auch die vom Client unterstützten Cipher-Suiten mitgeteilt.
  • Schritt 2: Der Server antwortet mit einer ServerHello-Nachricht. Diese enthält die vom Server aus den vom Client angebotenen Cipher-Suiten ausgewählte Cipher-Suite, den gewählten Key Share des Servers, das Zertifikat des Servers und die Signatur eines Teils der übertragenen Daten. Die Spezifikation des Key Share ist abhängig von der gewählten Cipher-Suite.
  • Schritt 3: Der Client prüft das Zertifikat des Servers und die Signatur (durch die der Server beweist, im Besitz des zugehörigen privaten Schlüssels zu sein). Ist die Prüfung erfolgreich, sendet er den von ihm gewählten Key Share verschlüsselt mit dem öffentlichen Schlüssel aus dem Zertifikat an den Server. Mit einer Finished-Nachricht erklärt er, dass er mit dem Handshake fertig ist. Alle nachfolgenden Daten werden mit dem Sitzungsschlüssel verschlüsselt.
  • Schritt 4: Sowohl Client als auch Server können nun den Schlüsselaustausch abschließen und den Sitzungsschlüssel berechnen. Der Server sendet seinerseits eine Finished-Nachricht und erklärt damit, dass er mit dem Handshake fertig ist und alle weiteren Daten mit dem Sitzungsschlüssel verschlüsseln wird.
  • Schritt 5 ff: Die Nachrichten der HTTP-Verbindung werden mit dem Sitzungsschlüssel verschlüsselt.

Es werden also zwei Round-Trips (Kommunikationsschritte) zwischen Client und Server benötigt, um den Handshake abzuschließen. Erst danach kann die verschlüsselte HTTP-Kommunikation beginnen.

Verbindungsaufbau mit TLS 1.3 in einem Round-Trip

Kommen wir nun zum Verbindungsaufbau in TLS 1.3 (Tabelle 2).

Schritt Client Richtung Server
1 Sendet:
ClientHello
Unterstützte Cipher-Suites
Vermutetes Key Agreement Protocol
Key Share
2 Berechnet Sitzungsschlüssel aus Key Share des Clients und eigenem Key Share,
sendet:
ServerHello
Gewählte Cipher-Suite und Key Agreement Protocol
Key Share
Zertifikat (verschlüsselt mit dem Sitzungsschlüssel) und Signatur
Finished
3 Prüft Zertifikat, wenn OK:
Sendet:
Finished
4 1. HTTP-Request
5 1. HTTP-Response

Tabelle 2: Der Handshake zum Verbindungsaufbau mit TLS 1.3

  • Schritt 1: Der Verbindungsaufbau beginnt wie bei TLS 1.2, wenn der Client seine ClientHello-Nachricht an den Server sendet. Dabei werden dem Server auch die vom Client unterstützten Cipher-Suiten mitgeteilt (dazu gleich noch mehr), zusätzlich rät der Client aber, welches Key Agreement Protocol der Server wohl wählen wird und sendet passende Key Shares mit. Das Raten ist relativ einfach, da generell nur noch Diffie-Hellman-Verfahren ohne benutzerdefinierte Parameter unterstützt werden; außerdem sollen Verfahren auf der Grundlage von elliptischen Kurven bevorzugt werden. Die Wahl des Servers wird daher meist auf ECDHE mit einer der Kurven X25519 oder P-256 fallen, und wenn der Client Key Shares dafür mitschickt, liegt er meist richtig. Nur wenn der Server keinen vom Client gesendeten Key Share unterstützt, ist ein neuer Versuch nötig, was der Server über einen HelloRetryRequest mit den unterstützten Gruppen signalisiert.
  • Schritt 2: Der Server kann nun aus dem Key Share des Clients und seinem eigenen Key Share bereits den Sitzungsschlüssel berechnen. Er antwortet mit einer ServerHello-Nachricht. Diese enthält die vom Server aus den vom Client angebotenen Cipher-Suiten ausgewählte Cipher-Suite, das gewählte Key Agreement Protocol, den gewählten Key Share des Servers, das mit dem Sitzungsschlüssel verschlüsselte Zertifikat des Servers und die Signatur eines Teils der übertragenen Daten. Und da er nun bereits einen Sitzungsschlüssel besitzt, sendet er auch sofort seine Finished-Nachricht.
  • Schritt 3: Der Client erzeugt aus seinem Key Share und dem des Servers den Sitzungsschlüssel, entschlüsselt damit das Zertifikat und prüft das Zertifikat und die Signatur. Ist die Prüfung erfolgreich, sendet er seine Finished-Nachricht.
  • Schritt 4 ff: Die Nachrichten der HTTP-Verbindung werden mit dem Sitzungsschlüssel verschlüsselt.

TLS 1.3 kommt also mit einem Round-Trip aus und kann dadurch sehr viel schneller mit der HTTPS-Kommunikation beginnen.

Cipher-Suiten: Einmal kräftig ausmisten, bitte!

Auch bei den Cipher-Suiten hat sich einiges getan. In SSL und TLS bis einschließlich Version 1.2 wurde in den Cipher Suiten alles zusammengefasst, was für die Verbindung ausgehandelt werden konnte:

  • Unterstützte Zertifikatstypen
  • Hashfunktionen für die Ableitung von Schlüsseln durch eine Zufallszahlenfunktion (Pseudo Random Function, PRF) (z. B. SHA-1, SHA-256, …)
  • MAC-Funktionen (z. B. HMAC mit SHA-1, HMAC mit SHA 256, …)
  • Schlüsselaustauschalgorithmus (z. B. RSA, ECDHE, …)
  • Authentifizierungsalgorithmus (z. B. RSA)
  • Verschlüsselungsalgorithmus (z. B. AES, RC4, …)
  • Betriebsart für die Verschlüsselung (z. B. CBC)

Alle möglichen zulässigen Kombinationen wurden in einer von der Internet Assigned Numbers Authority (IANA) verwalteten Tabelle erfasst. Eine übliche Cipher Suite für TLS 1.2 ist z. B. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Dabei ist

  • TLS das Protokoll (Cipher-Suiten können auch anderswo zum Einsatz kommen),
  • ECDHE der Schlüsselaustauschalgorithmus,
  • RSA der Authentifizierungsalgorithmus,
  • AES_128_GCM der AEAD-Cipher-Modus (zu AEAD siehe unten),
  • SHA256 die Hashfunktion für die Ableitung von Schlüsseln (PRF-Hash-Algorithmus).

TLS 1.2 spezifiziert selbst 37 Cipher-Suiten, dazu kommen 319 Suiten aus vorangegangenen Versionen.

In TLS 1.3 wurden viele dieser veralteten Features entfernt, sodass nun eine klare Trennung zwischen drei orthogonalen Vereinbarungen möglich wurde: Verschlüsselungsalgorithmus und Hashfunktion für die „HMAC-based Extract-and-Expand Key Derivation Function“ (HKDF) zur Schlüsselerzeugung, Schlüsselaustauschalgorithmus, Signaturalgorithmus für die Authentifizierung.

TLS 1.3 definiert nur fünf neue Cipher-Suiten (und unterstützt keine der alten mehr):

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256

Im Fall von TLS_AES_128_GCM_SHA256 ist TLS das Protokoll, AES_128_GCM der AEAD-Cipher-Modus, SHA256 die HKDF-Hashfunktion. Dazu kommen die Schlüsselaustauschalgorithmen: Diffie-Hellman über je fünf elliptische Kurven (ECDHE) und Finite Field Groups (DHE), Pre-Shared Key (PSK) und PSK mit (EC)DHE sowie die Signaturalgorithmen RSA (PKCS#1), Elliptic Curve Digital Signature Algorithm (ECDSA) oder Edwards-Curve Digital Signature Algorithm (EdDSA) oder der symmetrische Pre-Shared Key. Das macht die Auswahl sehr viel einfacher.

Resumption: Vorherige Verbindungen wieder aufnehmen

Eine bereits in TLS 1.2 bestehende Möglichkeit, TLS-Verbindungen zu beschleunigen, ist die sogenannte Resumption. Wenn der Client sich bereits zuvor mit dem Server verbunden hat, können beide auf dabei getroffene Vereinbarungen zurückgreifen und den Handshake beschleunigen (Tabelle 3).

Schritt Client Richtung Server
1 Sendet:
ClientHello
Session-ID/-Ticket
2 Sendet:
ServerHello
Finished
3 Sendet:
Finished
4 1. HTTP-Request
5 1. HTTP-Request

Tabelle 3: Der Resumption-Handshake zur Verbindungswiederaufnahme mit TLS 1.2

In TLS 1.2 funktioniert die Resumption folgendermaßen: Der Server sendet dem Client eine Session-ID oder ein Session-Ticket. Während die Session-ID nur eine Referenznummer ist, anhand derer Server die gespeicherte Session erkennt, ist das Session-Ticket eine verschlüsselte, serialisierte Session, sodass der Server diese nicht speichern muss. Beim nächsten Verbindungsaufbau schickt der Client die Session-ID oder das Session-Ticket an den Server, der den Client daraufhin erkennt und den zuvor ausgehandelten Schlüssel etc. verwendet. Statt den Schlüsselaustausch durchzuführen, kann er also sofort sein Finished senden und spart damit einen Round-Trip.

TLS 1.2 bietet also eine One Round Trip Time Resumption (1-RTT), sofern der Client sich bereits zuvor schon einmal mit dem Server verbunden hat (was in vielen Fällen häufig vorkommt). Mit TLS 1.3 ist aber auch eine Zero Round Trip Time Resumption (0-RTT) möglich. Wenn sich der Client zuvor schon einmal mit dem Server verbunden hat, kann er sofort verschlüsselte Daten schicken (Tabelle 4). TLS 1.3 erzeugt in diesem Fall keinerlei Overhead, die Kommunikation läuft im Grunde genau wie bei einem unverschlüsselte HTTP-Request ab.

Schritt Client Richtung Server
1 Sendet:
ClientHello
Session-Ticket
Key Share
1. HTTP-Request
2 Sendet:
ServerHello
Key Share
Finished
1. HTTP-Response

Tabelle 4: Der 0-RTT-Resumption-Handshake zur Verbindungswiederaufnahme mit TLS 1.3

Wenn ein TLS-1.3-Client sich mit einem TLS-1.3-Server verbindet, einigen sie sich auf einen sogenannten Resumption Key oder Pre-Shared Key (PSK), und der Server teilt dem Client ein Session-Ticket mit, mit dem der sich den Key merken kann. Das Ticket kann eine verschlüsselte Kopie des PSK (sodass der Server den Status nicht speichern muss) oder eine Referenznummer sein.

Wenn sich der Client das nächste Mal mit dem Server verbindet, sendet er zusammen mit seinem ClientHello das Session-Ticket und beginnt sofort danach mit der HTTPS-Kommunikation (verschlüsselt mit dem PSK), ohne vorher auf eine Antwort vom Server zu warten. Der Server ermittelt über das Session-Ticket den passenden PSK und entschlüsselt damit den Request. Der Client sendet zusätzlich ein Key Share, sodass Client und Server einen neuen Sitzungsschlüssel austauschen können, der dann für die Verschlüsselung der ersten HTTPS-Response und aller weiteren Daten verwendet wird.

Die Nachteile von 0-RTT

Der Einsatz von 0-RTT hat zwei Nachteile: Es besteht keine vollständige Forward Secrecy mehr, und auch der Schutz gegen Replay-Attacken ist nicht mehr gegeben. Darauf wird aber in Abschnitt 2.3 von RFC 8446 ausdrücklich hingewiesen. Und es wird niemand gezwungen, 0-RTT zu nutzen.

Nachteil 1: Keine Forward Secrecy gegen kompromittierten Session-Ticket-Key

Der PSK bietet keine Forward Secrecy gegen einen kompromittierten Session-Ticket-Key. Wenn ein Angreifer die Daten aufzeichnet und später an den Session-Ticket-Key gelangt, kann er das Session-Ticket entschlüsseln und erhält dadurch den PSK. Damit kann er aber nur die vom Client gesendeten 0-RTT-Daten entschlüsseln, nicht den Rest der Verbindung. Für deren Verschlüsselung wird der neu aus den Key Shares per Diffie-Hellman-Verfahren gebildete Sitzungsschlüssel verwendet.

Als Schutz vor diesem Angriff sollte der Session-Ticket-Key oft ausgetauscht werden, sodass die Folgen eines Angriffs minimiert werden. Außerdem dürfen nicht mehr benötigte Session-Ticket-Keys nicht länger gespeichert werden (der Server braucht sie ja nicht mehr). Beides zusammen minimiert die Folgen eines Angriffs.

Das Problem ist im Vergleich zu TLS 1.2 auch nicht besonders schlimm, da TLS 1.2 selbst keinerlei Forward Secrecy gegen eine Kompromittierung des Session-Ticket-Keys bietet. TLS 1.3 mit 0-RTT ist also in der Hinsicht eine Verbesserung, da dabei alle nach dem ersten Request gesendeten Daten durch einen neuen Sitzungsschlüssel geschützt sind.

Nachteil 2: 0-RTT ist anfällig für Replay-Angriffe

Schwerwiegender sind Replay-Angriffe. Da die Server beim Einsatz von Session-Tickets statuslos arbeiten, haben sie keine Möglichkeit festzustellen, ob ein Paket mit 0-RTT-Daten bereits zuvor gesendet wurde. Dadurch sind Replay-Angriffe möglich.

Das ist weiter kein Problem, wenn der erste Request zu keinen Änderungen auf dem Server führt, sondern nur Daten wie z. B. die Startseite abfragt. Es wird aber gefährlich, wenn der erste Request zu einer Änderung auf dem Server führt, z. B. weil er eine Transaktion wie Hiermit kaufe ich eine Waschmaschine ausführt. Ein MitM kann das Paket mit dem ClientHello und den 0-RTT-Daten aufzeichnen und z. B. hundertmal an den Server senden. Und schon sind 101 Waschmaschinen bestellt. Die werden hoffentlich nicht ausgeliefert, sorgen aber bis zur Stornierung der überzähligen Bestellungen dafür, dass der Bestand um 100 Waschmaschinen zu niedrig ist. Wodurch vielleicht andere, reguläre Bestellungen nicht aufgegeben werden, weil diesen Benutzern angezeigt wird, dass das Gerät zurzeit nicht ab Lager lieferbar ist. Oder aber es wird automatisch Nachschub geordert, obwohl der gar nicht gebraucht wird.

Die Bestellungen werden vom Server akzeptiert, da der ein Session-Ticket erkennt, es entschlüsselt, um den PSK zu erhalten, mit dem PSK die 0-RTT-Daten entschlüsselt und den enthaltenen HTTP Request ausführt, ohne zu bemerken, dass er den bereits zuvor erhalten hat.

Zur Lösung des Problems dürfen Server in 0-RTT-Daten empfangene Requests nur ausführen, wenn sie keine Änderungen auf dem Server auslösen, die mehrmalige Ausführung also immer zum gleichen Ergebnis führt (sie also idempotent sind), was insbesondere für alle lesenden Zugriffe gilt.

Enthalten die 0-RTT-Daten einen Request, der nicht idempotent ist, sollte der Server einen vollen 1-RTT-Handshake durchführen. Dabei ist kein Replay-Angriff möglich, da sowohl ClientHello als auch ServerHello einen Zufallswert und die Verbindungen Sequenznummern enthalten.

Auf der Black Hat USA und der DEFCON 26 haben Alfonso Garcia Alguacil und Alejo Murillo Moya einen Vortrag mit Beispielen für Replay-Angriffe und möglichen Schutzmaßnahmen gehalten. Die schlechten Nachrichten daraus:

  • Eigentlich entscheidet der Browser, wann er 0-RTT verwendet. Der MitM kann aber einen Reset der Verbindung provozieren, sodass der Browser sie erneut aufbaut und dabei dann 0-RTT verwendet.
  • Auch wenn TLS-Library und Server 0-RTT-Replay-Angriffe perfekt verhindern, sind sie möglich, wenn die Anwendung nicht davor geschützt ist.

Die beiden Forscher haben ein Tool veröffentlicht, mit dem sich ihre Angriffe nachvollziehen lassen. Ihr Fazit: Die Entwickler müssen sich der Gefahr durch 0-RTT und der dadurch möglichen Replay-Angriffe bewusst sein und ihre Anwendungen selbst davor schützen. Was aber eigentlich selbstverständlich ist, denn Replay-Angriffe muss man ja generell verhindern.

MAC-then-encrypt – Problem vor Langem erkannt, Problem nun endlich gebannt

Kommen wir zur Verschlüsselung und Integritätssicherung. SSL und TLS bis Version 1.2 verwenden bei der Verschlüsselung und Integritätssicherung den sog. MAC-then-Encrypt-Ansatz: Erst wird ein Prüfwert über die Klartextdaten gebildet (der Message Authentication Code, MAC) und an die Daten angehängt, dann wird beides zusammen verschlüsselt.

Inzwischen hat sich herausgestellt, dass dieser Ansatz problematisch ist, denn er ermöglicht sogenannte „Padding-Oracle“-Angriffe. Dabei wird vereinfacht gesagt versucht, Byte für Byte den Klartext zu erraten und sich von der Integritätssicherung sagen zu lassen, ob man richtig geraten hat oder nicht.

Solche Angriffe wurden mehrfach gegen SSL und TLS vorgeführt; bekannt dürfte z. B. der Poodle-Angriff (Padding Oracle on downgraded Legacy Encryption [2]) sein. In TLS 1.3 ist damit Schluss, da darin MAC-then-Encrypt durch die Authenticated Encryption with Associated Data (AEAD) ersetzt wurde, bei der Integritätssicherung und Verschlüsselung in einem Schritt durchgeführt werden. Das bekannteste derartige Verfahren ist der Galois Counter Mode (GCM).

Das große Aufräumen

Kommen wir zu den weiteren Opfern der Aufräumaktion in TLS 1.3. Dazu gehört z. B. die Betriebsart Cipher Block Chaining (CBC), die z. B. für Poodle- [2] und BEAST-Angriffe verantwortlich ist. In TLS 1.3 ist sie verboten.

Auch alle als problematisch angesehenen oder sogar als gebrochen bekannten Kryptoverfahren wurden gestrichen. Das betrifft z. B. DES/3DES, MD5, SHA-1, RC4 und die Export-Cipher-Suiten, sodass Downgrade-Angriffe mit TLS 1.3 nicht mehr möglich sind. Beispielsweise nutzten die Angriffe FREAK und Logjam einen Downgrade-Angriff, um die Nutzung der unsicheren Export-Cipher-Suiten zu erzwingen und danach die Verschlüsselung brechen zu können [3].

Auch zwei weitere problematische Optionen wurden aus dem Standard gestrichen: die Kompression und die Renegotiation (Neuaushandlung einer existierenden Verbindung).

Mit anderen Worten: Alles, was in der Vergangenheit für Ärger gesorgt hat, ist in TLS 1.3 rausgeflogen.

Und dann neu einrichten!

Als Ersatz für die unsicheren Kryptoverfahren gibt es neue, sichere Verfahren, z. B. auf der Grundlage von elliptischen Kurven (ECC) wie der Curve25519 von Dan J. Bernstein und der Curve448 (Goldilocks-Kurve). Außerdem erfolgt der Verbindungsaufbau nun soweit wie möglich signiert.

Das war bisher nicht der Fall, und so konnte ein MitM z. B. die Liste der vom Client unterstützten Cipher-Suiten manipulieren, ohne dass Client oder Server es bemerken konnten. Darüber wurden in der Vergangenheit mehrmals Downgrade-Angriffe durchgeführt, bei denen der MitM die Liste des Clients auf die Suite(n) kürzte, die er brechen konnte. Im Allgemeinen waren das dann veraltete Verfahren oder solche mit kurzen Schlüssellängen wie die Exportverfahren. Der Server wich dann auf so eine eigentlich unsichere Cipher-Suite aus (frei nach dem Motto „Besser ein schlechtes Verfahren als gar keine Verschlüsselung“), obwohl eigentlich sowohl Client als auch Server sichere Versionen unterstützten. Bekannte Beispiele für solche Downgrade-Angriffe sind FREAK und LogJam [3].

In TLS 1.3 wird so oft wie möglich signiert, sodass u. a. die Liste der unterstützten Cipher-Suiten nicht mehr unerkannt manipuliert werden kann. Außerdem signalisieren TLS-1.3-fähige Server einen Downgrade des Protokolls über die letzten 8 Bytes ihres Zufallswerts im ServerHello. Wird TLS 1.2 ausgehandelt, müssen die letzten 8 Bytes des Zufallswerts auf 44 4F 57 4E 47 52 44 01 gesetzt werden (44 4F 57 4E 47 52 44 ergibt als ASCII die Buchstaben DOWNGRD).

Wird TLS 1.1 oder niedriger ausgehandelt, muss ein TLS-1.3-Server die letzten 8 Bytes des Zufallswerts auf 44 4F 57 4E 47 52 44 00 setzen, und TLS-1.2-Server sollten es ebenfalls tun.

Ein TLS-1.3-Client kann an diesen Werten erkennen, dass gerade ein Downgrade durchgeführt wird und er es nicht mit einem Server zu tun hat, der nichts Neueres unterstützt. Das ist i. A. ein sicheres Zeichen dafür, dass gerade ein Angriff läuft.

TLS 1.3 und MitM-Boxen

Mit TLS 1.3 werden MitM-Angriffe durch die Verschlüsselung der Zertifikate weiter erschwert (bzw. unbemerkt nahezu unmöglich). Das trifft auch alle, die bisher darauf angewiesen sind, wie Sicherheitsappliances, Tools zur Netzwerküberwachung und Ähnliches (Middleboxes), weshalb es immer wieder Versuche gab, diesen Schutz aufzuweichen. Zum Glück erfolglos, denn jede derartige Hintertür hätte auch wieder eine neue Angriffsfläche geboten. Außerdem hat eine solche Überwachung auch schon mit TLS 1.2 nicht wirklich funktioniert.

Versionswirrwar

Beim Test mit Vorversionen von TLS 1.3 stellt sich heraus, dass viele Webserver mit der neuen Versionsnummer im ClientHello nicht zurechtkamen und den Verbindungsaufbau abbrachen. Eigentlich sollten die Server in so einem Fall eine niedrigere, von ihnen unterstützte Version aushandeln. Das Problem wurde gelöst, indem die Versionsnummer im bisher dafür zuständigen Feld legacy_version auf den Wert 0x0303 für TLS 1.2 eingefroren wurde. Stattdessen signalisiert der Client seine Versionspräferenzen im Erweiterungsfeld supported_versions, wo für TLS 1.3 als höchster Wert 0x0304 eingetragen wird.

TLS 1.3 und Windows

Abschließend nehmen wir noch Windows in den Fokus: Wie sieht es mit der TLS-1.3-Unterstützung von Windows aus? Leider zur Zeit gar nicht gut – es gibt sie nicht. Schannel (Secure Channel) unterstützt TLS 1.3 nicht und damit auch weder der IE noch Edge. Bei den Bibliotheken gibt es als Alternative z. B. OpenSSL, bei den Browsern Firefox und Chrome. Aber eine wirklich gute Lösung ist das nicht, und Microsoft hat bisher nicht mal eine Roadmap veröffentlicht oder sich überhaupt zur Einführung von TLS 1.3 geäußert. Was eigentlich ziemlich peinlich ist, immerhin wird es von der Konkurrenz in vielen Bereichen bereits unterstützt. Hoffentlich ändert sich das möglichst bald.

Fazit

TLS 1.3 hat gegenüber TLS 1.2 zwei entscheidende Vorteile: Es ist sicherer und es ist performanter. Sicherer ist immer gut, und zumindest bei HTTPS war ja immer die Performance eine beliebte Ausrede, weshalb man darauf verzichtet hat. Diese Ausrede zieht jetzt nicht mehr oder zumindest weniger. Aber dem unverschlüsselten Web hat ja Google schon den Todesstoß versetzt. Und das sogar zweimal: Zum ersten Mal, als man anfing, HTTPS-Seiten in der Suchmaschine zu bevorzugen. Und zum zweiten Mal mit der Ankündigung, im Browser in Zukunft vor HTTP-Seiten zu warnen.

Jetzt muss sich TLS 1.3 nur noch durchsetzen, und das hat bei TLS 1.2 ziemlich lange gedauert – obwohl den älteren Versionen der Reihe durch Angriffe quasi der Boden unter den Füßen weggerissen wurde.

Ich bin aber zuversichtlich, dass es diesmal schneller gehen wird, denn es gibt bereits einige Early Adopters, und z. B. Facebook meldet, dass jetzt schon mehr als 50 Prozent des Internet-Traffics mit TLS 1.3 geschützt ist. Das kommt mir ziemlich viel vor, denn bei Firefox und Cloudflare sind es nur fünf Prozent. Aber auch fünf Prozent sind für ein gerade erst veröffentlichtes Protokoll schon ganz beachtlich.

Links&Literatur

[1] Eilers, Carsten: „Heute aufgezeichnet – morgen entschlüsselt?“; PHP Magazin 5.2014
[2] Eilers, Carsten: „Herzbluten, ein bissiger Poodle und Co. – Ein Rückblick auf Schwachstellen und Angriffe im Jahr 2014“; Entwickler Magazin 1.15
[3] Eilers, Carsten: „Kurze Schlüssel, große Gefahr – Logjam und FREAK gefährden TLS“; PHP Magazin 5.2015

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -