TLS 1.3 - Status, Bedenken und Auswirkungen
Bekanntlich wurde im August 2018 die Version 1.3 des Transport Layer Security (TLS)-Protokolls von der Internet Engineering Task Force (IETF) ratifiziert und damit zum neuen Standard für die Verbindungssicherheit im Internet gemacht. Die verabschiedete Version des RFC ist eine Aktualisierung des TLS 1.2-Standards, der seit über zwei Jahren von der IETF diskutiert wurde. TLS 1.3 konzentriert sich in erster Linie auf die Geschwindigkeit und Sicherheit von Verbindungen.
TLS 1.3 bringt jedoch eine Reihe von Herausforderungen und Bedenken mit sich, insbesondere für die Branche der Netzverkehrskontrolle.
In diesem Artikel befassen wir uns mit einigen der wichtigsten TLS-Entwicklungen, ihrer Bedeutung für Middlebox-SSL-Entschlüsselungslösungen, den durch die eingeführten Upgrades aufgeworfenen Bedenken, der Bedeutung von TLS 1.2 nach der Ratifizierung von TLS 1.3 und den Auswirkungen dieser Änderungen auf Middlebox-SSL-Entschlüsselungslösungen.
Was ist neu bei TLS 1.3?
Einige der wichtigsten Neuerungen sind die folgenden:
Verschlüsselte Servernamen-Identifizierung (ESNI)
TLS 1.3 versprach erhebliche Verbesserungen beim Schutz der Privatsphäre der Benutzer. In TLS 1.2 wird der größte Teil des SSL-Handshake/TLS-Handshake im Klartext durchgeführt. Dadurch wird die Server-Namen-Identifikation (SNI) in Client Hello oder der Subject Alternate Name (SAN) im Server-Zertifikat zum Abhören freigegeben, so dass z. B. der Browserverlauf des Benutzers offengelegt wird. Um dieses Problem zu lösen, wurde in früheren Entwürfen von 1.3 das Konzept der verschlüsselten SNI (ESNI) in Client Hello sowie verschlüsselte Server-Zertifikate in Server-Hello-Nachrichten diskutiert.
Als diese neue Protokollversion veröffentlicht wurde, wurde die ESNI-Unterstützung wegen des Leistungsmangels und der geringen Akzeptanz eingestellt. Die Verschlüsselung von Serverzertifikaten wurde jedoch standardmäßig übernommen. Dies bietet zwar keinen vollständigen Schutz der Privatsphäre des Benutzers, trägt aber zur Weiterentwicklung des Protokolls bei, da der größte Teil des Handshakes nun verschlüsselt ist und somit nicht mehr von Kompatibilitätsproblemen mit älteren Clients betroffen ist.
Transport Layer Security (TLS) Versionsaushandlung
In früheren Transport Layer Security (TLS)- Versionen konnten Benutzer Cipher Suites neu aushandeln, indem sie einfach die Präferenzliste in der Server Hello neu anordneten. Dies konnte zu Downgrade-Angriffen führen, bei denen ein Angreifer einfach die Cipher-Suite-Liste umstellen und den Client auf eine anfällige TLS- oder SSL-Version herabstufen konnte, um deren Schwachstellen auszunutzen.
TLS 1.3 verbietet die Neuverhandlung und verwendet die Erweiterungen "supported_version" und "legacy_version". Jetzt werden TLS 1.2 und ältere Versionen als "legacy_versions" aufgeführt, wenn eine Verbindung aufgebaut wird, während 1.3 als einzige "supported_version" aufgeführt wird. Angreifer können nun nicht mehr einfach die Liste der Cipher-Suite-Einstellungen "mischen" und ein Downgrade vornehmen.
Zero Round-Trip Time (0-RTT)
Mit dem neuen Protokoll 1.3 wird ein neuer Modus mit der Bezeichnung Zero Round-Trip Time (0-RTT) eingeführt, der bei bestimmten Anwendungen einen Round-Trip während des Verbindungsaufbaus einspart. Diese Methode nutzt Pre-Shared Keys (PSK), die entweder von zuvor aufgebauten Transport Layer Security-Verbindungen oder von einer externen Quelle stammen, um die Leistung zu erhöhen und die Netzlatenz zu verringern. Diese Methode birgt jedoch gewisse Schwachstellen, die im nächsten Abschnitt erörtert werden.
Das Sicherheitsrisiko im SSL/TLS-Verkehr
Da Finanzdienstleistungsunternehmen ihre Abläufe umgestalten, verstärkt auf die Cloud zurückgreifen und Mitarbeiter an entfernten Standorten einsetzen, ist die IT-Abteilung aufgrund des fehlenden Einblicks in den verschlüsselten Datenverkehr und die möglicherweise darin enthaltene Malware dem Risiko eines Cyberangriffs, der Datenexfiltration und der Nichteinhaltung von Vorschriften ausgesetzt.
Probleme mit TLS 1.3
Bedenken hinsichtlich des Datenschutzes
Die Finanzdienstleistungs- und die Gesundheitsbranche unterliegen Datenschutznormen, z. B. dem Health Insurance Portability and Accountability Act von 1996 (HIPAA), der vorschreibt, dass der Datenschutz für Patientendaten gewahrt bleiben muss. Dies bedeutet, dass alle Daten, die zwischen einem Patienten und den Datenservern des Gesundheitswesens hin- und hergehen, jederzeit verschlüsselt werden müssen. SSL-Entschlüsselungslösungen, die zwischengeschaltet werden, sollen diesen Datenverkehr direkt an die Server weiterleiten.
Während die SSL-Entschlüsselungslösung Umgehungsrichtlinien auf der Grundlage der vom Client vorgelegten SNI-Informationen durchsetzen kann, kann das SAN-Zertifikat nicht aus einem verschlüsselten Serverzertifikat ermittelt werden, und daher kann die Entschlüsselungslösung die Identität des Servers nicht überprüfen.
Folglich muss dieser Datenverkehr entschlüsselt werden, um die SNI mit dem SAN-Zertifikat abzugleichen, und sobald der Datenverkehr entschlüsselt ist, werden die Datenschutzbestimmungen verletzt, was zu Klagen und Geldstrafen führt. Mit der zunehmenden Verbreitung von TLS 1.3 müssten diese Datenschutzregeln entsprechend aktualisiert werden, was wiederum eine Büchse der Pandora mit Datenschutzbedenken und anderen Problemen öffnen würde.
Bedenken hinsichtlich Leistung und Latenzzeit
Unternehmen haben Richtlinien, die sie dazu verpflichten, die Umgehung der SSL-Entschlüsselung durchzusetzen. Früher konnten Entschlüsselungslösungen bestimmte Arten von Datenverkehr auf der Grundlage der SNI oder des Zertifikats-SAN umgehen. Mit dem verschlüsselten SAN von TLS 1.3 ist dieser Prozess jedoch mühsamer geworden. SSL-Entschlüsselungslösungen müssen nun den Datenverkehr entschlüsseln, selbst wenn er umgangen werden soll. Dadurch wird die Latenz unnötig verlängert, was zu einer Leistungsverschlechterung im Vergleich zur Alternative, d. h. TLS 1.2, führt.
0-RTT und Replay-Angriffe
0-RTT soll die Leistung von TLS 1.3 verbessern, aber es ist wichtig zu beachten, dass die Verwendung dieses Modus Schwachstellen verursachen kann. Dazu gehören Replay-Angriffe, bei denen sich Angreifer Zugang zu den Verbindungsinformationen verschaffen und diese dann nutzen können, um erneut Anfragen an den Server zu senden, wobei sie echte Kunden imitieren. Dies kann im Finanzsektor verheerende Folgen haben, da Angreifer mehrere Banktransaktionen durchführen können, obwohl nur eine einzige Transaktion beabsichtigt war.
TLS 1.3 RFC räumt dies ein und erwähnt, dass es keine Garantie gegen Replay-Angriffe mit 0-RTT gibt. Die Last der Sicherheit wurde vom Protokoll auf die Anwendungen verlagert, wo vorgeschlagen wird, Sicherheitsmechanismen gegen Wiederholungsangriffe einzuführen.
Transport Layer Security Version Negotiation und fortgesetzte Sicherheit
Wenn früher eine TLS-Version oder eine Cipher-Suite vom Client oder vom Server nicht unterstützt wurde, mussten sie eine andere aus ihrer Präferenzliste aushandeln und auswählen. Diese Flexibilität ist wichtig, damit es bei der Einführung neuer Cipher-Suites oder TLS-Versionen nicht zu Netzwerkausfällen oder Sicherheitslücken kommt.
TLS 1.3 erlaubt kein "Shuffling" von Cipher-Suite-Präferenzlisten, was bedeutet, dass Pseudo-Proxy-Entschlüsselungslösungen fehlschlagen werden. Solche Lösungen haben in der Vergangenheit schwerwiegende Probleme verursacht, die von Netzwerkausfällen bis hin zur Durchleitung von Datenverkehr reichten, wodurch die Nutzer potenziellen Angriffen ausgesetzt waren.
Vollständige oder aktive Proxy-Lösungen sind jedoch in der Lage, je nach den Anforderungen des Benutzers verschiedene Cipher Suites und TLS-Versionen auszuhandeln. Eine vollständige Proxy-Lösung unterhält zwei getrennte Verbindungen: zwischen dem Client und sich selbst sowie zwischen sich selbst und dem Server. TLS 1.3 unterstützt solche Lösungen und bietet ihnen die Möglichkeit, die Version 1.3 aus der Liste "supported_version" zu entfernen und die Liste "legacy_version" zu verwenden. Vollständige Proxy-Entschlüsselungsgeräte bieten den Nutzern eine zukunftssichere und belastbare Lösung. Eine solche Herabstufung auf eine "Legacy"-Version oder TLS 1.2 ist gemäß RFC 8446 ebenfalls vollkommen akzeptabel.
Warum ist das Internet noch nicht auf TLS 1.3 umgestiegen?
Ausgehend von der obigen Diskussion können wir sagen, dass eine weit verbreitete Einführung von 1.3 als Internet-Standard länger dauern wird, als man vielleicht denkt.
- TLS 1.3 schreibt die Verwendung spezifischer Chiffren vor, die auf der Serverseite einen hohen Preis verlangen können. SSL-Offload auf Application Delivery Controllern (ADCs) und Entschlüsselung auf Servern würden kostspielige Hardware-Upgrades und einen hohen Verwaltungsaufwand erfordern.
- TLS 1.2 ist nach wie vor aktuell und wurde noch nicht kompromittiert. Mozilla hat festgestellt dass derzeit etwa 95 % der Internetverbindungen, die über Firefox hergestellt werden, TLS 1.2 verwenden, während nur 3,2 % der Verbindungen TLS 1.3 nutzen. Es gibt derzeit keinen zwingenden Grund für Nutzer, auf 1.3 umzusteigen, da TLS 1.2 immer noch mit Sicherheitsstandards wie PCI konform ist.
- Nach Angaben von QualysAlle SSL/TLS-Protokolle sind nicht sicher, und als beste Praxis sollte mindestens TLS 1.1 verwendet werden. TLS 1.2 und 1.3 sollten verwendet werden, wenn sie unterstützt werden. Es ist jedoch deutlich zu sehen, dass die Unterstützung von 1.3 noch weit hinter den TLS-Versionen 1.1 und 1.2 zurückbleibt.
- Das Internet nimmt neue Standards nur langsam an. Selbst veraltete TLS-Versionen wie 1.0 und 1.1 werden noch von allen großen Browserherstellern unterstützt und werden bis Mitte 2020 verwendet werden.
- Eine höhere Leistung mit 0-RTT ist ein Vorteil, aber wie wir bereits erörtert haben, kann dies zu Schwachstellen führen, deren Behebung kostspielige Upgrades erfordern würde.
Auswirkungen von TLS 1.3 auf Entschlüsselungslösungen
Vollständige Proxy-Architektur
Eine vollständige oder aktive Proxy-Lösung, die die volle Kontrolle über die Auswahl der Verschlüsselungssuite hat, kann 1.3-Verbindungen auf 1.2 zurückstufen oder getrennte Versionen auf der Client- und der Serverseite verwenden. Wie bereits erwähnt, verstößt dies nicht gegen den TLS 1.3 RFC.
Wird eine neue TLS-Version oder eine neue Chiffrier-Suite in das Netz eingeführt, unterbricht eine echte Vollproxy-Lösung das Netz nicht und gewährleistet durch die Aushandlung verschiedener Chiffrier-Suiten einen kontinuierlichen Schutz.
Datenschutz und Compliance
Mit der Unterstützung von TLS 1.2 können Entschlüsselungslösungen mit Datenschutzstandards wie HIPAA konform bleiben, da sie den Datenverkehr umgehen können, ohne ihn zu entschlüsseln. Durch die Verwendung von TLS 1.2 können Entschlüsselungslösungen auf die SNI und das Serverzertifikat SAN zugreifen, was die Umgehung zuverlässig und einfach macht. Außerdem wird die Latenz beseitigt, die durch die Entschlüsselung von Verbindungen zur Umgehung mit 1.3 auf der Client-Seite entsteht. Die Client-Seite ist bereits innerhalb der Unternehmensgrenzen gesichert, so dass keine Sicherheitsbedenken aufkommen.
Was ist also die empfohlene beste Praxis?
Obwohl TLS 1.3 im Jahr 2018 ratifiziert wurde, erfolgt die Annahme nur sehr langsam, da TLS 1.2 immer noch relevant ist und keine bekannten Schwachstellen aufweist. TLS 1.2 ist nach wie vor das Protokoll der Wahl für das Internet und stellt nach wie vor eine gültige Lösung für Unternehmen dar. Das neue Protokoll bringt aber auch eine Reihe von Problemen mit sich, die es zu lösen gilt.
A10 NetworksThunder® SSL Insight (SSLi®) ist eine vollständige Proxy-Lösung, die alle mit 1.3 eingeführten Herausforderungen angeht und gleichzeitig das Netzwerk widerstandsfähiger und zukunftssicherer macht. Eine solche Lösung verstößt nicht gegen den RFC und ist in Abschnitt 2.2.4 des TLS 1.3 RFC for TLS use cases, Entwurf 00, vorgesehen.
Mit seinen Full-Proxy-Fähigkeiten ist Thunder SSLi in der Lage, verschiedene Cipher-Suites für die Client- und die Serverseite auszuhandeln, und wird die folgenden Kombinationen unterstützen:
Da sich TLS 1.3 jedoch immer mehr durchsetzt, empfiehlt A10 Networks auf der Grundlage der obigen Ausführungen die Verwendung des zweiten Szenarios, d. h. die Verwendung von TLS 1.2 für die Client-Seite und 1.3 für die Server-Seite. Dies trägt zur Verbesserung der Leistung bei, stellt sicher, dass die Konformitätsstandards nicht verletzt werden, und nutzt alle Vorteile von 1.3 für die externen Verbindungen. Diese Flexibilität macht Thunder SSLi sowohl sicher als auch konform, ohne zusätzliche Patches oder Upgrades.