TLS – Transport Layer Security

Abkürzung: TLS

TLS verschlüsselt nicht einfach einen Datenstrom. Es klärt zuvor in einem festgelegten Nachrichtenwechsel, mit wem man spricht, welche Verfahren beide Seiten beherrschen und welche Schlüssel für diese eine Verbindung gelten. Erst danach fließen Nutzdaten.

Das Protokoll ist der Nachfolger von SSL und trägt seinen heutigen Namen seit 1999. Im Sprachgebrauch hat sich das abgelöste Kürzel gehalten — wer von einem SSL-Zertifikat spricht, meint fast immer TLS.

Was TLS leistet

Drei Eigenschaften, die sich technisch trennen lassen:

Vertraulichkeit. Die Nutzdaten werden mit einem symmetrischen Verfahren verschlüsselt, dessen Schlüssel nur für diese Sitzung gilt.

Integrität. Jeder Datensatz trägt eine Prüfsumme über den Inhalt. Eine Veränderung unterwegs fällt auf und beendet die Verbindung.

Authentizität. Der Server weist sich mit einem Zertifikat aus. Der Client prüft, ob das Zertifikat von einer Stelle stammt, der er vertraut, und ob es für den angefragten Namen gilt.

Die dritte Eigenschaft ist die, die in der Praxis schiefgeht. Verschlüsselung ohne Authentifizierung schützt vor dem Mitlesen, aber nicht davor, mit dem Falschen zu sprechen.

Der TLS-Handshake

Der Handshake ist der Teil, in dem die Verbindung verhandelt wird. Er unterscheidet sich zwischen den Versionen deutlich, und das ist der Grund, aus dem TLS 1.3 nicht einfach eine Fortschreibung ist.

Handshake in TLS 1.3

TLS 1.3 kommt mit einem Umlauf aus. Der Client rät, welche Schlüsseleinigung der Server beherrscht, und schickt seinen Anteil gleich mit:

Client                                        Server
  ClientHello
  + key_share
  + supported_versions           ────────▶
                                              ServerHello
                                              + key_share
                                           {EncryptedExtensions}
                                           {Certificate}
                                           {CertificateVerify}
                                           {Finished}
                                 ◀────────
  {Finished}                     ────────▶
  [Anwendungsdaten]              ◀───────▶   [Anwendungsdaten]

Alles in geschweiften Klammern ist schon verschlüsselt. Ab dem ServerHello liegt ein gemeinsames Geheimnis vor, und von da an ist auch das Serverzertifikat nicht mehr im Klartext auf der Leitung — ein Unterschied zu allen Vorgängerversionen.

Rät der Client die Gruppe falsch, antwortet der Server mit HelloRetryRequest und der Handshake kostet einen zweiten Umlauf.

Was TLS 1.2 anders machte

TLS 1.2 brauchte zwei Umläufe, weil Verfahrenswahl und Schlüsseleinigung aufeinander folgten statt gleichzeitig zu laufen. Der Ablauf umfasste ServerKeyExchange, ClientKeyExchange und ChangeCipherSpec als eigene Schritte. Das Zertifikat ging unverschlüsselt über die Leitung.

Gestrichen hat TLS 1.3 außerdem eine Reihe von Altlasten, an denen jahrelang Angriffe hingen: den Schlüsseltransport per RSA, statisches Diffie-Hellman, Kompression innerhalb von TLS, die Neuverhandlung laufender Verbindungen und alle Betriebsarten mit separater Prüfsumme. Übrig bleiben AEAD-Verfahren, die Verschlüsselung und Integrität in einem Schritt erledigen.

Daraus folgt eine Eigenschaft, die man nicht mehr konfigurieren muss: In TLS 1.3 ist Perfect Forward Secrecy nicht mehr eine Option unter mehreren, sondern die einzige Möglichkeit. Ein später kompromittierter Serverschlüssel gibt mitgeschnittene Sitzungen nicht preis.

Sitzungswiederaufnahme und 0-RTT

Für wiederkehrende Verbindungen kann der Server ein Ticket ausstellen, mit dem der Client den vollen Handshake überspringt. Darauf aufbauend erlaubt TLS 1.3, Anwendungsdaten bereits mit dem ClientHello zu senden — 0-RTT.

Das ist schnell und hat einen Haken, der in der Norm ausdrücklich benannt ist: 0-RTT-Daten sind gegen Wiedereinspielung nicht geschützt. Wer sie nutzt, muss sicherstellen, dass die übertragene Anfrage mehrfach ausgeführt nichts anrichtet.

Versionen und ihr Status

TLS 1.0 und 1.1 sind seit RFC 8996 vom März 2021 ausdrücklich abgeschafft. Das Dokument ist eine Best Current Practice und ändert gleichzeitig 84 andere RFCs, die diese Versionen noch voraussetzten — ein Hinweis darauf, wie breit die Protokollfamilie darauf aufgebaut hatte.

Praktisch heißt das: TLS 1.2 und 1.3 sind in Betrieb, alles darunter wird von aktuellen Clients abgelehnt.

Cipher Suites und die Algorithmenwahl

Eine Cipher Suite ist die Kombination der Verfahren, auf die sich beide Seiten einigen. Hier liegt der zweite große Bruch zwischen den Versionen.

In TLS 1.2 benannte eine Suite vier Dinge auf einmal: Schlüsseleinigung, Authentifizierung, Verschlüsselung und Prüfsummenverfahren, etwa TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Die Zahl der Kombinationen war entsprechend groß, und viele davon waren schwach.

In TLS 1.3 benennt eine Suite nur noch das AEAD-Verfahren und die Hashfunktion, etwa TLS_AES_128_GCM_SHA256. Schlüsseleinigung und Signaturverfahren werden getrennt über eigene Erweiterungen verhandelt. Die Liste zulässiger Suiten ist auf eine Handvoll geschrumpft.

Welche Verfahren und Schlüssellängen für deutsche Behörden und ihre Dienstleister vorgesehen sind, steht in Teil 2 der Technischen Richtlinie BSI TR-02102, der sich ausschließlich mit TLS befasst.

Erweiterungen, die man kennen sollte

Server Name Indication. Der Client nennt im ClientHello, mit welchem Hostnamen er sprechen will. Ohne diese Angabe könnte ein Server, der mehrere Namen unter einer Adresse bedient, nicht das richtige Zertifikat auswählen. Der Name steht dabei im Klartext auf der Leitung — auch in TLS 1.3.

Application-Layer Protocol Negotiation. Beide Seiten einigen sich während des Handshakes darauf, welches Anwendungsprotokoll folgt. Ohne dieses Verfahren gäbe es kein HTTP/2 und kein HTTP/3 auf demselben Port.

Was TLS nicht leistet

TLS sichert eine Strecke zwischen zwei Endpunkten. Was an den Endpunkten passiert, liegt außerhalb.

Es sagt nichts darüber, ob der Gegenüber vertrauenswürdig ist — nur, dass er den Namen rechtmäßig führt, für den sein Zertifikat gilt. Eine betrügerische Seite mit gültigem Zertifikat ist aus Sicht von TLS einwandfrei.

Es verbirgt nicht, mit wem gesprochen wird. Zieladresse, Verbindungszeitpunkt, Datenmenge und der Hostname aus der Server Name Indication bleiben sichtbar.

Und es schützt Daten nur unterwegs. Auf dem Server liegen sie entschlüsselt.