© best_vector/Shutterstock.com
Das ändert sich in der neuen TLS-Version

Neuer Standard für mehr Sicherheit


Am 10. August 2018 wurde RFC 8446 [1] 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 [2].

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 entsprechend 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. Dort läuft der Handshake folgendermaßen ab:

Schritt

Client

Richtung

Server

1

Sendet:

ClientHello

Unterstützte Cipher-Suiten

2

Sendet:

ServerHello

Gewählte Cipher-Suite

Key Share

Zertifikat und 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

  • 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-Suiten

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...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang