Die nächste Sicherheitsstufe

Was TLS 1.3 ist und wie Sie davon profitieren

Verabschiedet ist er, der Standard zur neuen Transport Layer Security. Das heißt aber noch längst nicht, dass alles läuft.

Von Jürgen Schmidt

Transport Layer Security (TLS) ist der wichtigste Krypto-Standard des Internets. Er schützt Kommunikation gegen Lauscher und Manipulation. Konkret sichert er den Transport zwischen Client-Programmen wie dem Browser oder Mailer und dem Server im Internet, der den jeweiligen Dienst bereitstellt. TLS kommt auf PCs aller Betriebssysteme genauso zum Einsatz wie auf Smartphones oder intelligenten IoT-Geräten – hoffentlich zumindest.

Im August war es endlich so weit: Die Hüter der Internet-Standards bei der IETF veröffentlichten die bereits im Frühjahr abgesegnete TLS-Version 1.3 offiziell als RFC 8446. Damit soll Transport Layer Security ein neues Sicherheitsniveau erklimmen. Doch bevor sich das auf die Praxis auswirkt, muss das neue Protokoll auch in den Programmen ankommen, die es nutzen. Da im Laufe der Standardisierung bereits einige Vorarbeiten erledigt wurden, sieht das schon ganz gut aus. Aber so ganz in der Realität des Alltags angekommen ist der neue Standard noch nicht.

Dabei ist zu hoffen, dass TLS 1.3 nicht das Schicksal seines Vorgängers droht: TLS 1.2 wurde bereits 2008 verabschiedet, fand aber bis 2014 keine nennenswerte Verbreitung. Erst zehn Jahre später ist es so weit etabliert, dass man eine endgültige Ausmusterung von TLS 1.0 und TLS 1.1 ins Auge fasst. Die Browser Chrome, Edge, Firefox, Internet Explorer 11 und Safari sollen diese als veraltetet und unsicher geltenden TLS-Versionen ab 2020 nicht mehr unterstützen.

Viele Sicherheitsratgeber empfehlen Admininistratoren schon jetzt das Abschalten von TLS 1.0 auf ihren Servern. Der für Zahlungsdienstleister verpflichtende Standard PCI-DSS verbietet dessen Einsatz sogar seit Juli 2018. Doch umsichtigen Admins ohne Compliance-Zwang empfehlen wir zunächst einen Blick in die eigenen Logfiles. Bei Heise zeigte der, dass sich immer noch rund 8 Prozent der Besucher mit TLS 1.0 verbinden.

Angesichts der mittlerweile konsequenten Verschlüsselung der gesamten Heise-Seiten bedeutete das Abschalten von TLS 1.0 also, dass fast jeder zehnte Besucher das Angebot gar nicht mehr abrufen könnte, sondern nur noch eine Fehlermeldung zu sehen bekäme. Das betrifft vor allem Nutzer älterer Smartphones mit Android 4.3 oder älter und alte Windows-Installationen mit Internet Explorer 10. Beide Plattformen können noch kein TLS 1.2. Und während die Windows-Nutzer prinzipiell IE 11 oder einen anderen Browser installieren könnten, bleibt vielen Android-Nutzern der Upgrade-Pfad verwehrt.

Langer Rede, kurzer Sinn: Bis auf Weiteres unterstützt der Heise-Server deshalb TLS 1.0. Und er befindet sich damit in guter Gesellschaft. Während etwa das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Abschaltung empfiehlt, unterstützt auch deren offizieller Webserver den veralteten Standard noch.

Für Entwickler

Noch die Ausnahme – aber erste Web-Seiten, mit denen Firefox und Chrome bereits Verbindungen mit TLS 1.3 aufbauen, tauchen bereits auf.

Zumindest die Basis für den Einsatz von TLS 1.3 ist bereits vorhanden: Die aktuellen Versionen der Bibliotheken OpenSSL (Version 1.1.1), GnuTLS (3.6.3) und Google BoringSSL bieten bereits TLS-1.3-Unterstützung. Das von Oracle im September veröffentlichte Java Development Kit 11 kann es ebenfalls. Damit können Software-Entwickler die in ihren Programmen und Apps erforderlichen Anpassungen ebenfalls vornehmen.

Welche das sind, hängt von der Abstraktionsebene ab, auf dem der Entwickler arbeitet. So bietet TLS 1.3 etwa einige neue Krypto-Verfahren, deren Nutzung man unter Umständen erst explizit erlauben muss. Es ist allerdings etwas Vorsicht geboten, da manche Versionen nur Vorabversionen des Standards wie Draft 28 umsetzen, die mit der finalen Version nicht vollständig kompatibel sind.

Für Anwender

Bei den Browsern sind – wie üblich – Firefox und Chrome ganz vorne mit dabei: Firefox 63 (security.tls.version.max = 4 in about:config) und Chrome 70 (chrome://flags/#tls13-variant steht auf „Enabled (Final)“) nutzen den neuen Standard bereits – und zwar ganz ohne dass der Anwender etwas dazu tun muss. Nutzer der Browser von Microsoft und Apple müssen noch etwas warten. Weder IE 11, Edge 17 noch Safari 12 können mit TLS 1.3 etwas anfangen. Auf Smartphones kann immerhin Chrome 69 für Android schon TLS 1.3. Im Zweifelsfall verrät der Aufruf von https://tls13.crypto.mozilla.org/, ob der eigene Browser das Protokoll bereits versteht. Wenn nicht, liefert das eine Fehlermeldung.

Apropos Fehler: Selbst wenn der eigene Browser bereits alles Notwendige mitbringt, kann der Aufruf von Mozillas Testseite zu einer Fehlermeldung führen. Das liegt dann an einer der Zwischenstationen auf dem Weg zum Server. Schon bei den Tests mit Vorabversionen des Standards kam es zu sehr hohen Fehlerraten durch sogenannte Middleboxes. Das ist dann etwa ein Intrusion Detection System, das sich sagt: „Da passiert etwas, das ich nicht kenne – das muss ein Angriff sein“, und dann kurzerhand versucht, diesen zu verhindern.

Die IETF-Experten haben deshalb schon einige Klimmzüge unternommen, TLS 1.3 ohne Abstriche an der Sicherheit so umzubauen, dass es diese kruden Tests passiert. Das hilft allerdings alles nichts, wenn sich ein Proxy oder eine auf dem PC installierte Antiviren-Software in die Verbindung aktiv einklinkt und selbst noch nicht auf TLS 1.3 umgestellt ist.

Der Test auf https://www.ssllabs.com/ssltest/viewMyClient.html verrät, was tatsächlich bei einem Internet-Server ankommt. Sie müssen das übrigens nicht abtippen, sondern finden alle weiterführenden Links unter ct.de/ydq7.

Für Server-Admins

Zum Kasten: Das bringt TLS 1.3

Noch nicht ganz so gut sieht es auf der Server-Seite aus. Zwar poppen bereits die ersten Webseiten mit TLS 1.3 auf. Die werden dann in aller Regel mit Nginx ab Version 1.13 ausgeliefert. Dort kann man TLS mit wenigen Handgriffen in der Konfigurationsdatei aktivieren:

ssl_protocols TLSv1.2 TLSv1.3;

Darüber hinaus möchte man noch die neuen Cipher-Suiten an den Beginn des Strings ssl_ciphers setzen:

TLS-CHACHA20-POLY1305-SHA256::

.TLS-AES-256-GCM-SHA384::

.TLS-AES-128-GCM-SHA256:

und die elliptischen Kurven explizit aktivieren:

ssl_ecdh_curve prime256v1:secp384r1;

Einige Webhoster bieten ebenfalls bereits TLS 1.3 als Feature an – allen voran Cloudflare, die die Entwicklung des Standards stark vorangetrieben haben. Dies kann man dann einfach im Web-Frontend konfigurieren; per Default ist die neue TLS-Version zumindest für neue Zonen bereits aktiviert. Dabei schaltet Cloudflare TLS 1.3 auf ihren Edge-Servern scharf, die mit Nginx als Reverse-Proxy arbeiten und die TLS-Verbindung terminieren. Der eigene Server muss deshalb kein TLS 1.3 können – kann es aber natürlich ebenfalls nutzen. Ein größerer Schub für die Verbreitung von TLS 1.3 im Web ist mit dessen Unterstützung ab Apache 2.4.37 zu erwarten. Aktuell ist noch Apache 2.4.35 mit maximal TLS 1.2.

Die offizielle Versionsangabe ist auf TLS 1.2 eingefroren – auch wenn beide Enden bereits 1.3 sprechen.

Die Analyse, ob eine TLS-Verbindung bereits gemäß Version 1.3 ausgehandelt wurde, ist übrigens nicht trivial. Denn das dafür vorgesehene Versionsfeld bei Client- und Server-Hello wurde wegen der Probleme mit den Schnüffelgeräten auf den Wert für TLS 1.2 eingefroren (0x0303). Erst die neu eingeführte Erweiterung supported_versions verrät, was wirklich passiert. Dort meldet dann etwa der Client, dass er die Versionen 1.0, 1.1, 1.2, 1.3 und eine zufällig ausgewürfelte, nicht existente Version unterstützt. Letzteres geschieht, um den Herstellern von Sicherheitssoftware die „Was der Bauer nicht kennt“-Mentalität auszutreiben. Wer möchte, kann sich das etwa mit Wireshark live anschauen. Das kann nämlich seit Version 2.6 mit TLS 1.3 umgehen. (ju@ct.de)

Tests und Status-Infos:ct.de/ydq7

Das bringt TLS 1.3

Am Beginn der Entwicklung des neuen Standards stand ein großes Ausmisten. Jede einzelne TLS-Funktion stellten die IETF-Experten dabei auf den Prüfstand. So ist das Wichtigste an den Neuerungen von TLS 1.3 eigentlich, was alles nicht mehr dabei ist. Und allein damit entfallen schon eine ganze Reihe von potenziellen Sicherheitsproblemen.

Das prominenteste Opfer der Entschlackungskur ist RSA. Zukünftig muss der Austausch des Sitzungsschlüssels über ein Diffie-Hellman-Verfahren abgewickelt werden, bevorzugt über dessen Variante auf elliptischen Kurven (ECDHE). Das stellt sicher, dass ein gestohlener Server-Schlüssel keinen Zugriff auf den Klartext bereits früher übertragener und verschlüsselt aufgezeichneter Daten ermöglicht (Forward Secrecy).

Außerdem wird das sogenannte Cipher Block Chaining (CBC) abgeschafft, das wegen der damit verbundenen Trennung von Verschlüsselung und Integritätssicherung immer wieder Angriffe ermöglichte (Stichwort: MAC-then-Encrypt). Zukünftig ist Authenticated Encryption angesagt, was beides in einem Schritt kombiniert. Statt als AES/CBC wird somit AES wohl häufig im Galois Counter Mode (GCM) betrieben; als Alternative sieht der Standard auch Counter with CBC-MAC (CCM) vor.

Bekannt kaputte Verfahren wie die Export Ciphers, MD5, SHA1, RC4 wurden beim Großreinemachen ebenfalls ausgemustert. Dafür beherrscht TLS 1.3 die längst überfällige DJB-Kurve Curve22519 und Goldilocks für Kryptografie auf Basis elliptischer Kurven (ECC) und die bereits seit einiger Zeit von Google genutzte Stream-Cipher ChaCha20.

Nicht nur aus Security-, sondern auch aus Privacy-Sicht interessant ist, dass TLS 1.3 einen weitaus größeren Teil des Verbindungsaufbaus verschlüsselt. Dabei gehen dann insbesondere die Server-Zertifikate nicht mehr im Klartext über die Leitung. An den darin enthaltenen Server-Namen konnten bislang Lauscher erkennen, mit welchem Webserver der Nutzer da gerade redet. Das geht immer noch mithilfe der sogenannten Server Name Indication (SNI); doch an deren Verschlüsselung wird ebenfalls bereits gearbeitet (Encrypted Server Name Indication for TLS 1.3, draft-ietf-tls-esni-01).

Ein weiteres Highlight ist der beschleunigte Verbindungsaufbau. Bereits nach dem Austausch eines Pakets mit Verwaltungsinformationen können TLS-gesicherte Nutzdaten übertragen werden. Man verliert dabei nur eine Round Trip Time und spricht von 1-RTT. In bestimmten Fällen kann der Client sogar ganz ohne Vorab-Fisimatenten sofort Daten schicken (0-RTT). Dazu muss allerdings Schlüsselmaterial aus vorherigen Sitzungen gespeichert und weiterverwendet werden, was in Security-Kreisen für etwas Unruhe sorgt. Schließlich ermöglicht das prinzipiell Replay-Angriffe. Der Standard adressiert diese Bedenken und erlaubt 0-RTT nur für ausgewählte Arten von Verbindungen.

Vom beschleunigten Verbindungsaufbau profitieren vor allem große Hoster wie Cloudflare, die Millionen von Verbindungsaufbauten pro Sekunde bedienen müssen. Aber auch neue TLS-Anwendungen wie DNS over TLS oder DNS over HTTPS werden erst mit den 1-RTT/0-RTT-Optimierungen performant genug, um mit den bisherigen, ungesicherten UDP-Protokollen konkurrieren zu können.