© best_vector/Shutterstock.com
Windows Developer
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

Ge...

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

Carsten Eilers


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

Ge...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang