TLS 1.3: Die Zukunft der Netzverschlüsselung
Voraussichtlich Anfang 2017 wird es in Sachen Netzverschlüsselung eine große Neuerung geben: Nach neun Jahren wird die Internet Engineering Task Force (IETF) eine neue Version des Transport-Layer-Security-Protokolls (TLS) veröffentlichen. TLS ist das mit Abstand wichtigste Verschlüsselungsprotokoll, es wird beispielsweise genutzt, um die Übertragung von Webseiten via HTTPS abzusichern. Die Entwickler haben aus vielen Fehlern der Vergangenheit gelernt: Schwache und problematische kryptographische Konstruktionen fliegen raus, dafür gibt es mehr Performance.
Der Entwicklungsprozess von TLS 1.3 wurde getrieben durch eine ganze Reihe von Angriffen, die das bisherige TLS-Protokoll und dessen Vorgänger SSL betrafen. Den Anfang nahm diese Entwicklung mit dem Beast-Angriff , der 2011 entdeckt wurde. Was Beast und viele spätere Angriffe wie Crime, Lucky Thirteen , Triple Handshake und weitere gemeinsam haben: Es handelt sich nicht um Angriffe auf fehlerhafte Implementierungen – wie beispielsweise der Heartbleed-Bug -, sondern um Angriffe auf das Protokoll selbst.
Problematische Kombination von Verschlüsselung und Authentifizierung
Ein großes Problem der bisherigen TLS-Versionen war die Art und Weise, wie Verschlüsselung und Authentifizierung kombiniert werden. Die meisten älteren Verschlüsselungsverfahren in TLS nutzen für die Authentifizierung den HMAC-Algorithmus und zur Verschlüsselung ein Blockverschlüsselungsverfahren im CBC-Modus. Entscheidend ist hierbei die Reihenfolge: Zunächst wird mit HMAC ein Authentifizierungs-Tag berechnet und an die Daten angehängt, anschließend werden mittels Padding die Daten auf eine passende Blockgröße verlängert und verschlüsselt.
Diese Reihenfolge – MAC-then-Encrypt – erwies sich als fataler Fehler. 2002 fand der Kryptograph Sergey Vaudenay heraus(öffnet im neuen Fenster) , dass man diese Konstruktion angreifen kann, wenn der Server auf Fehler beim Padding und Fehler bei der MAC-Berechnung unterschiedlich antwortet. Doch selbst wenn der Server immer mit derselben Fehlermeldung antwortet, sind weiterhin Timing-Angriffe möglich. Die Entwickler der aktuellen TLS-Version 1.2(öffnet im neuen Fenster) waren sich über dieses Problem im Klaren. In der Protokollbeschreibung steht, dass selbst wenn man die vorgeschlagenen Gegenmaßnahmen gegen Timing-Angriffe umsetze, weiterhin ein kleiner Timing-Unterschied übrig bleibe. Dieser sei aber vermutlich nicht ausnutzbar.
Das erwies sich als Fehleinschätzung. 2013 konnten die Sicherheitsexperten Nadhem Alfardan und Kenny Paterson mit dem Lucky-Thirteen-Angriff(öffnet im neuen Fenster) zeigen, dass sich selbst kleinste Zeitunterschiede ausnutzen lassen. Es ist zwar möglich, Gegenmaßnahmen gegen Lucky Thirteen zu implementieren, aber das macht den Code deutlich komplexer. In OpenSSL führte ein Fehler bei den Gegenmaßnahmen dazu, dass eine andere Variante des Padding-Oracle-Angriffs ermöglicht wurde . Paterson konnte zudem mehrfach zeigen, dass in verschiedenen Implementierungen die Gegenmaßnahmen gegen Lucky Thirteen fehlerhaft implementiert wurden.
Besonders bitter: Nach Lucky Thirteen wechselten viele TLS-Server zur Verschlüsselung mittels des RC4-Stromverschlüsselungsverfahrens, da dies von derartigen Angriffen nicht betroffen war. Allerdings war schon länger bekannt, dass RC4 eine andere Schwäche hat: Bestimmte Bits im Schlüsselstrom von RC4 haben Biases, das bedeutet, dass eine Eins wahrscheinlicher ist als eine Null oder andersherum. Diese Biases ließen sich ebenfalls in TLS angreifen, wie mehrere Kryptographen 2013 zeigten . Gegen die RC4-Angriffe gibt es keine Gegenmaßnahmen, daher wurde dieser Algorithmus inzwischen untersagt .
Nur noch authentifizierte Verschlüsselung
Um Probleme wie die Padding-Oracle-Angriffe und ähnliche Schwächen grundsätzlich zu vermeiden, gibt es authentifizierte Verschlüsselungsmodi (AEAD, Authenticated Encryption with Additional Data). Diese Verschlüsselungsarten kombinieren Verschlüsselung und Authentifizierung in einer standardisierten Operation. TLS 1.2 unterstützte bereits das authentifizierte Verschlüsselungsverfahren Galois/Counter Mode (GCM), später kam das Verfahren Chacha20-Poly1305 hinzu . In TLS 1.3 werden ausschließlich diese authentifizierten Verschlüsselungsverfahren unterstützt.
Doch auch das GCM-Verfahren hat eine Schwäche, die mit TLS 1.3 behoben wurde. Zur Verschlüsselung mit GCM wird ein sogenannter Nonce-Wert benötigt. Nonce steht dabei für "Number used Once", also eine Zahl, die nur einmal genutzt wird. In TLS 1.2 bleibt es dem Programmierer überlassen, wie er den Nonce-Wert wählt. Das kann zu fatalen Fehlern führen: Wenn derselbe Nonce-Wert mehrmals genutzt wird, ist die Sicherheit der Verbindung dahin. Einige Enterprise-Appliances waren genau von diesem Problem betroffen – an der Entdeckung dieses Problems war der Autor dieses Artikels beteiligt. In TLS 1.3 wird der Nonce nicht mehr durch die Implementierung bestimmt, sondern implizit durch das Protokoll vorgegeben. Daher sind derartige Fehler von vornherein nicht mehr möglich.
Kompression fliegt raus
Als sehr problematisch hat sich die Kompression von Daten vor der Verschlüsselung erwiesen. Die Kompressionsfunktion von TLS war Grundlage des Crime-Angriffs(öffnet im neuen Fenster) . In TLS 1.3 ist die sowieso selten verwendete TLS-Kompression daher nicht mehr vorhanden.
Doch damit ist das Thema nicht erledigt. Nach Crime gab es weitere Angriffe, die die Kompressionsfunktion von HTTP ausnutzen . Allerdings kann man auf der TLS-Ebene gegen derartige Angriffe nichts unternehmen, das muss in den darunterliegenden Protokollen geschehen.
Forward Secrecy zu sicher für die Banken
Ein weiteres problematisches Verfahren, das in TLS 1.3 ersetzt wird, ist der Handshake mittels RSA-Verschlüsselung. Das TLS-Protokoll unterstützte beim Handshake in der Vergangenheit zwei Varianten: einen Schlüsselaustausch, der vom Zertifikat des Servers nur signiert war – mittels RSA oder ECDSA -, und eine Variante, bei der ein Geheimnis direkt mit RSA verschlüsselt wurde. Nur die erste der beiden Varianten – der Schlüsselaustausch – bietet Forward Secrecy .
Forward Secrecy bedeutet, dass die Verschlüsselung selbst dann noch geschützt ist, wenn der langfristige Serverschlüssel, der Teil des Zertifikats ist, kompromittiert wird. Ein großer Vorteil: Selbst wenn ein Angreifer nachträglich den Server hackt oder auf andere Weise an den geheimen Schlüssel kommt, ermöglicht das nicht das Entschlüsseln von Verbindungen aus der Vergangenheit. Der Handshake mittels RSA-Verschlüsselung hat diese Forward-Secrecy-Eigenschaft nicht.
Ein weiteres Problem der RSA-Verschlüsselung sind Bleichenbacher-Angriffe. Der Kryptograph Daniel Bleichenbacher entdeckte diesen Angriff bereits 1998. TLS enthält Gegenmaßnahmen gegen Bleichenbacher-Angriffe, diese sind jedoch ausgesprochen umständlich. Im Fall einer fehlerhaften Entschlüsselung muss eine TLS-Implementierung den Handshake mit Fake-Daten weiterführen und darf ihn nicht vorzeitig abbrechen. Auch diese Workarounds sind anfällig gegen Timing-Angriffe. Dass nicht alle Implementierungen diese Gegenmaßnahmen korrekt durchführten, konnte 2014 ein Team der Fachhochschule Münster und der Ruhr-Universität Bochum zeigen . Eine Variante des Bleichenbacher-Angriffs führte auch zur Drown-Attacke , die Schwächen im Uralt-Protokoll SSL Version 2 ausnutzte.
Eine besondere Eigenschaft der Bleichenbacher-Angriffe könnte auch zukünftig zu Problemen führen: Wenn ein entsprechender Fehler vorhanden ist, reicht es bereits, wenn ein Server die entsprechenden Verfahren unterstützt, sie müssen nicht zum Einsatz kommen. Ein Angreifer kann möglicherweise die Tatsache, dass ein Server den RSA-Handshake mit TLS 1.2 anbietet, ausnutzen, um eine Verbindung mit TLS 1.3 anzugreifen. Auf dieses Problem wiesen im vergangenen Jahr Forscher der Universität Bochum hin(öffnet im neuen Fenster) .
Banken protestieren gegen zu viel Sicherheit
Die Entfernung des RSA-Handshakes war eine der ersten Entscheidungen bei der Entwicklung von TLS 1.3. Sie wurde von allen Beteiligten uneingeschränkt begrüßt. Doch vor kurzem meldete sich ein Vertreter einer Lobbyorganisation der Finanzbranche und äußerte Bedenken(öffnet im neuen Fenster) . In vielen Banken nutze man intern TLS mit dem RSA-Handshake, um auf Netzwerkebene den Datenverkehr entschlüsseln zu können. Das ist mit Verfahren, die Forward Secrecy nutzen, so nicht mehr möglich. TLS 1.3 ist schlicht zu sicher für diesen Anwendungszweck.
In der TLS-Arbeitsgruppe fand die Bankenlobby mit ihrem Einwand wenig Freunde. Kenny Paterson wies darauf hin(öffnet im neuen Fenster) , dass die Bankenlobby reichlich spät dran sei mit ihren Einwänden. Die Party sei fast vorbei, und man sei nur noch damit beschäftigt, leere Bierdosen einzusammeln und Aschenbecher zu leeren.
RSA-Signaturen mit PSS
Dass der RSA-Verschlüsselungs-Handshake aus dem Protokoll gestrichen wird, bedeutet nicht das Ende von RSA in TLS. Zertifikate mit RSA-Schlüsseln können weiterhin für einen Forward-Secrecy-Handshake als Signaturverfahren genutzt werden.
Auch dabei gibt es jedoch eine Änderung: Bisher nutzte TLS als Padding-Verfahren für RSA ausschließlich das veraltete PKCS #1 1.5. Dieses Signaturverfahren hat ebenfalls eine Schwäche, die auch von Bleichenbacher entdeckt wurde. Sie betrifft allerdings nur fehlerhafte Implementierungen. Eine Variante dieses Bleichenbacher-Signaturangriffs ist der BERserk-Angriff . Statt PKCS #1 1.5 kommt das Padding-Verfahren PSS (Probabilistic Signature Scheme) zum Einsatz, das keine derartige Schwäche hat.
Handshake mit einem oder mit null Round-Trips
Der Handshake von TLS erforderte bisher zwei volle Round-Trips, bevor Daten gesendet werden können. TLS 1.3 optimiert den Protokollverlauf und verhindert dabei einen kompletten Round-Trip(öffnet im neuen Fenster) . Bei der ersten Verbindung mit einem TLS-Host können also deutlich früher Daten gesendet werden. Das Single-Round-Trip-Verfahren dürfte jenseits der Sicherheitsgewinne einer der größten Anreize sein, TLS 1.3 zu implementieren.
TLS 1.3 sieht auch eine noch schnellere Variante vor, ein Zero-Round-Trip-Verfahren (0-RTT), mit dem der Client direkt Daten an den Server schicken kann. Dieses Zero-Round-Trip-Verfahren funktioniert nur, wenn Server und Client bereits vorher eine Verbindung aufgebaut haben. Der Verbindungsschlüssel wird dabei aus dem Schlüssel der vorigen Verbindung berechnet.
Neue Angriffe durch Zero-Round-Trip-Handshake?
Doch dieses 0-RTT-Verfahren hat auch Bedenken hervorgerufen, es könne Replay-Angriffe ermöglichen(öffnet im neuen Fenster) . Denkbar wäre etwa eine Situation, in der ein Server eine bestimmte Aktion auf Anweisung eines Clients durchführt, etwa einen Geldtransfer. Ein Angreifer könnte das Datenpaket für diese Aktion mitlesen und erneut an den Server schicken – und somit die Aktion mehrfach ausführen.
Um solche Replay-Angriffe zu vermeiden, darf das Zero-Round-Trip-Verfahren nur für Aktionen eingesetzt werden, die den Status auf dem Server nicht ändern. Unproblematisch ist es etwa für normale Webseitenabrufe, bei denen der Client nur Daten anfordert, aber dem Server nichts mitteilt. Doch damit dies korrekt funktioniert, muss die Applikationslogik mit der TLS-Implementierung kommunizieren und entsprechend unterschiedliche Anfragen unterschiedlich behandeln. Das widerspricht der Idee, TLS als separaten Layer zu betrachten, der auf bestehende Protokolle aufgesetzt werden kann.
Bei allen Protokollen und Applikationen, die eine solch enge Verzahnung von TLS und Applikationslogik nicht gewährleisten können, sollte man auf den Zero-Round-Trip-Handshake trotz der Performancevorteile besser verzichten.
Formale Verifikation hilft beim Protokolldesign
Eine ganze Reihe der TLS-Angriffe, die in den vergangenen Jahren veröffentlicht wurden, geht zurück auf ein Team des Kryptographen Karthik Bhargavan, der am französischen Forschungsinstitut Inria das Prosecco-Team (Programming Securely with Cryptography) leitet.
Die Forscher von Inria haben in den vergangenen Jahren das TLS-Protokoll mit formalen mathematischen Methoden analysiert und konnten bestimmte Sicherheitseigenschaften beweisen. Außerdem erstellten sie eine formal verifizierte Implementierung namens miTLS(öffnet im neuen Fenster) in der Programmiersprache F#. Die Inria-Forscher waren permanent an der Diskussion um TLS 1.3 beteiligt und analysierten das Design des neuen Protokolls, um die bekannten Angriffe zu verhindern.
Diese Arbeiten führten etwa dazu, dass künftig mehr Daten des Handshakes signiert werden. Außerdem wurde die Berechnung des sogenannten Pre Master Secrets, aus dem der Sitzungsschlüssel abgeleitet wird, neu gestaltet. Hintergrund dafür war der sogenannte Triple-Handshake-Angriff.
Mit dem SLOTH-Angriff zeigten die Inria-Forscher zudem die Risiken von schwachen Hashverfahren wie MD5 und SHA-1. Der Sweet32-Angriff zeigte Schwächen des veralteten Triple-DES-Verfahrens, das mit einer kleinen Blockgröße von 64 Bit arbeitet. All diese alten Verfahren sind in TLS 1.3 nicht mehr nutzbar.
Versionsintoleranz und Schmierfett
Ein Problem, das bisher bei jeder neuen TLS-Version auftauchte, hängt mit der Aushandlung der TLS-Version zusammen(öffnet im neuen Fenster) . Bei einem TLS-Handshake sendet der Client die höchste TLS-Version, die er unterstützt. Aktuell wäre das etwa in der Regel TLS 1.2. Doch damit sich ein Client auch mit Servern verbinden kann, die nur ältere TLS-Protokollversionen unterstützen, kann der Server auch mit einer niedrigeren Protokollversion antworten, etwa TLS 1.0.
Das Problem: Obwohl dieses Versionsaushandlungsverfahren relativ simpel ist, schlampen viele Server dabei. Bei Verbindungen mit höheren TLS-Versionen brechen sie die Verbindung ab, senden einen Fehler oder produzieren einen Timeout. Dieses Verhalten wird als Versionsintoleranz bezeichnet.
Um auch mit solch fehlerhaften Servern eine Verbindung zu ermöglichen, haben die Browserhersteller Fallbacks implementiert. Schlug eine Verbindung mit TLS 1.2 fehl, versuchten sie es erneut mit TLS 1.1, danach mit TLS 1.0 und danach häufig sogar mit dem Uraltprotokoll SSL Version 3.
Diese Fallbacks führten jedoch zu einer ganzen Reihe von Problemen. Zunächst einmal traten sie manchmal auch bei schlechten Netzverbindungen auf. Das führte dazu, dass neuere Protokollfeatures gelegentlich nicht funktionierten. Beispielsweise ermöglicht die TLS-Erweiterung Server Name Indication seit TLS 1.0, dass auf derselben IP mehrere Hosts mit verschiedenen Hostnamen und Zertifikaten betrieben werden. Doch wenn ein Fallback die Verbindung auf SSL Version 3 reduziert, erhält der Nutzer das falsche Zertifikat.
Protokoll-Downgrades können auch zu Sicherheitsproblemen werden. Der erste Angriff, der auf Protokolldowngrades basierte, war 2014 der sogenannte Virtual-Host-Confusion-Angriff von Antoine Delignat-Lavaud. Auch der Ende 2014 entdeckte Poodle-Angriff nutzte die Protokoll-Downgrades .
Nach Poodle hatten die meisten Browser daher diese Downgrades entfernt. Doch zunächst sah es so aus, als würden die Protokolldowngrades mit TLS 1.3 ein Comeback erleben: Trotz dieser ganzen Sicherheitslücken und Fehler in der Vergangenheit haben viele Hersteller offenbar nichts gelernt. Eine ganze Reihe von Servern reagierte fehlerhaft auf Verbindungsversuche mit TLS 1.3 – darunter Webseiten von IT-Größen wie Apple, Ebay oder Paypal.
IBM, Cisco und Citrix mit defekten TLS-Implementierungen
Der Autor dieses Artikels versuchte im Sommer 2016, einige der Hersteller, die für diese defekten TLS-Implementierungen verantwortlich waren, zu kontaktieren, darunter Cisco, Citrix und IBM. Die Reaktionen auf die Meldung dieses Problems waren verhalten. IBM teilte mit, dass es bereits zu spät sei, dieses Problem im nächsten Versionsupdate zu beheben. Erst die übernächste Version – irgendwann 2017 – werde einen Fix enthalten. Cisco verweigerte einen Fix komplett, da das Ganze nur Geräte betraf, die nicht mehr unterstützt wurden. Citrix bestätigte zwar das Problem, sagte aber nicht, wann man einen Fix bereitstellen werde. Apple und Ebay antworteten auf Anfragen überhaupt nicht, Paypal teilte lediglich mit, dass derartige Probleme nicht Teil des Bug-Bounty-Programms der Firma seien.
Google-Entwickler David Benjamin schlug vor, das Problem der Versionsintoleranz durch ein neues Versionsaushandlungsverfahren zu umgehen(öffnet im neuen Fenster) . Benjamins Vorschlag sieht vor, dass künftig die unterstützten TLS-Versionen durch eine Erweiterung im Handshake mitgeteilt werden. Unbekannte TLS-Erweiterungen werden von Servern ignoriert. Theoretisch könnte ein Server auch in so einem Fall fehlerhaft reagieren, aber das kommt deutlich seltener vor. Der Grund dafür dürfte sein, dass neue TLS-Erweiterungen häufiger eingeführt werden als neue TLS-Versionen.
Dieser neue Mechanismus würde zwar für TLS 1.3 mit ziemlicher Sicherheit funktionieren, aber bei künftigen Versionen könnte sich ein ähnliches Problem ergeben: Server, die TLS 1.3 implementieren, könnten die Versionserweiterung auswerten und eine Verbindung ablehnen, wenn dort eine ihnen unbekannte Version auftaucht.
Schmierfett gegen unfähige Hersteller
Um solche Fehler auch zukünftig zu vermeiden hat Benjamin das Grease-Verfahren(öffnet im neuen Fenster) entwickelt (Generate Random Extensions And Sustain Extensibility). Man müsse verhindern, dass Protokollimplementierungen rosten und sie deswegen regelmäßig mit Schmierfett behandeln. Die Idee ist simpel: Browser und andere Clients können gelegentlich bestimmte reservierte Nonsens-Versionsnummern mit dem TLS-Handshake mitschicken. Auch für TLS-Erweiterungen und Verschlüsselungsverfahren sind Grease-Werte reserviert.
Ein Server muss unbekannte Werte in all diesen Fällen ignorieren. Falls ein Server auf unbekannte Werte mit einem Fehler reagiert, würde dies früh auffallen, da Verbindungen fehlschlagen. Somit soll verhindert werden, dass derartige fehlerhafte Implementierungen überhaupt Verbreitung finden.
Ein Schlupfloch für dumme Implementierungen bleibt: Entwickler einer TLS-Servers könnten zwar die vordefinierten Grease-Werte ignorieren, aber bei allen anderen Werten weiterhin einen Fehler produzieren. Dafür müssten sie aber schon das Protokoll lesen und gleichzeitig komplett missverstehen – oder absichtlich derartige Fehler einbauen.
TLS 1.3 oder doch TLS 4?
Immer wieder wurden während der Standardisierung von TLS 1.3 Stimmen laut, die anmerkten, dass angesichts der gravierenden Änderungen ein größerer Versionssprung gerechtfertigt sei. Doch TLS 2 will das neue Protokoll kaum jemand nennen. Das hat historische Gründe: Das Vorgängerprotokoll SSL gab es in Version 2 und 3. Es hat in der Vergangenheit bereits zu viel Verwirrung geführt, dass nach SSL 3 somit TLS 1.0 kam. Daher wollen einige gleich zu Version 4 springen. Bisher bleibt die TLS-Arbeitsgruppe zwar bei Version 1.3, aber in einer kürzlichen Diskussion auf der Mailingliste(öffnet im neuen Fenster) sprachen sich relativ viele Teilnehmer für eine Umbenennung zu Version 4 aus.
TLS 1.3 kommt – und ist teilweise schon da
Eine ganze Reihe von TLS-Implementierungen unterstützt bereits die aktuelle Entwurfsversion von TLS 1.3(öffnet im neuen Fenster) . Die von Google verwendete BoringSSL-Bibliothek unterstützt TLS 1.3 schon, in den Canary-Versionen von Chrome kann man das Protokoll mit einer Option aktivieren. Die Mozilla-Bibliothek NSS unterstützt TLS 1.3 ebenfalls, seit Firefox 49 lässt sich in Mozillas Browser das neue Protokoll optional nutzen. Webseiten, die Cloudflare verwenden, können bereits mit TLS 1.3 aufgerufen werden(öffnet im neuen Fenster) . Cloudflare nutzt dafür eine eigens entwickelte TLS-1.3-Implementierung in Go(öffnet im neuen Fenster) .
Die auf Servern am häufigsten eingesetzte OpenSSL-Bibliothek hat bislang keinen Support für die Vorabversionen von TLS 1.3. OpenSSL plant die Unterstützung in der Version 1.1.1(öffnet im neuen Fenster) .
Fazit: Mehr Sicherheit und mehr Performance
Die bessere Performance dürfte dazu führen, dass viele Webseitenbetreiber ein großes Interesse haben, TLS 1.3 schnell zu nutzen. Das war bei den Vorgängerversionen nicht so. TLS 1.2 existierte lange Zeit praktisch nur auf dem Papier, erst viele Jahre später implementierten die großen Browser Unterstützung für das Protokoll.
TLS 1.3 ist mit Abstand die größte Neuerung, die es im TLS-Ökosystem je gegeben hat. Während in TLS 1.2 einige schon damalsfragwürdige kryptographische Konstruktionen vorhanden waren, die aus Kompatibilitätsgründen fortgeführt wurden, wagt TLS 1.3 an vielen Stellen den großen Bruch. Manche problematische Algorithmen verbleiben jedoch, etwa der Signaturalgorithmus ECDSA oder die nicht nur wegen ihrer NSA-Herkunft als problematisch geltenden elliptischen Kurven der US-Behörde Nist. Mit dem Zero-Round-Trip-Verfahren kommt zudem eine Konstruktion hinzu, die neue Sicherheitsrisiken mit sich bringt. Es bleibt also spannend.