Die Arbeiten an der neuen Version des TLS 1.3-Protokolls sind fast abgeschlossen. Nach vierjähriger Diskussion im März 2018 genehmigte die IETF die
28. Version des Entwurfs als vorgeschlagenen Standard, daher sollte es die letzte sein, bevor die endgültigen Spezifikationen angenommen werden.
TLS 1.3 beschleunigt den Aufbau einer sicheren Verbindung um etwa die Hälfte, indem an dieser Stelle mehrere Schritte kombiniert werden. Darüber hinaus wird ein Regime perfekter direkter Geheimhaltung durch die kurzlebigen Schlüssel (EC) DH implementiert. Dieser Modus garantiert den Schutz von Sitzungsschlüsseln auch bei Kompromittierung von Langzeitschlüsseln.
Zahlreiche weitere Verbesserungen wurden implementiert, einschließlich der Unterstützung der ChaCha20-Stream-Verschlüsselung, der digitalen Signaturalgorithmen Ed25519 und Ed448, der Schlüsselaustauschprotokolle x25519 und x448 usw. Die Unterstützung veralteter MD5- und SHA-224-Hash-Funktionen sowie schwacher und selten verwendeter elliptischer Kurven wurde entfernt
Am interessantesten ist jedoch die neue Idee,
die auf der IETF diskutiert wird . Google-Experten schlagen vor, regelmäßig eine neue Version des TLS-Protokolls mit geringfügigen Änderungen zufällig zu generieren. Die Idee ist, dass häufige Updates ein Gegenmittel gegen gefährliche Ossifikation sind.
Was ist das für ein Problem?
Die sogenannte "Ossifikation" ist eine Situation, in der die Protokollentwickler plötzlich erkennen, dass es aufgrund der weit verbreiteten Verbreitung der alten Version, die aus irgendeinem Grund für Benutzer geeignet ist, schwierig ist, Verbesserungen einzuführen. In der Realität erfüllt die alte Version nicht mehr die modernen Sicherheitsanforderungen und neuen Spezifikationen, kann jedoch nicht de facto implementiert werden.
Es wird
angenommen, dass die sogenannten Zwischenknoten, nämlich die Anbieter von Lösungen im Bereich "Sicherheit", speziell mit der Implementierung von TLS 1.3 zur Hauptbremse wurden. Sie empfehlen ihren Kunden, beim Händeschütteln mit TLS
bestimmte Firewall-Regeln für das Scannen von Zertifikaten vorzuschreiben. In der neuen Version des Standards werden
SSL-Zertifikate verschlüsselt, sodass Vermittler sie nicht mehr scannen können.
Wie wird eine ständige Aktualisierung das Problem der Ossifikation des Protokolls lösen?
Die kontinuierliche Aktualisierung alle sechs Wochen ist ein bekanntes Muster des Chrome-Browsers. In dieser Situation sind die "Darsteller"
gezwungen, die Spezifikationen einzuhalten, da eine inkompatible Implementierung für einen großen Teil der Benutzer nicht funktioniert.
Auf der IETF-Mailingliste wurde diese Idee
von David Benjamin vom Chromium-Projekt vorgeschlagen. Er schreibt, dass TLS 1.3 ein erweiterbares Protokoll ist, das mit TLS 1.2 abwärtskompatibel ist. Es kann schrittweise gerollt werden, um die aktuellen Implementierungen von TLS 1.2 zu aktualisieren. Und hier gibt es Probleme. Zahlreiche inkompatible Server können in der TLS 1.3 ClientHello-Phase keine Verbindung herstellen. Sie müssen daher ein Rollback durchführen, um eine Verbindung mit der unterstützten Protokollversion herzustellen.
David Benjamin bringt die Idee vor, wie dieses Problem in Zukunft vermieden werden kann. In Bezug auf vorbeugende Maßnahmen erwähnt er
Protokollinvarianten , die in Abschnitt 9.3 der Spezifikationen aufgeführt sind. Alle Endpunkte und Zwischenknoten
müssen den beschriebenen Invarianten entsprechen. Insbesondere neue Clients und neue Server haben nicht das Recht, die Parameter auf die alte Version zu reduzieren. Auf die gleiche Weise haben Zwischenknoten nicht das Recht, dies beim Übertragen der Verbindung zwischen dem aktualisierten Client und dem Server zu tun, und können den Handshake nicht beeinflussen. Angesichts der ungleichmäßigen Aktualisierungsgeschwindigkeit können aktualisierte Clients und Server den Aufbau der Kommunikation unter Verwendung des alten Protokolls unterstützen, jedoch nur auf die in Abschnitt 9.3 beschriebene Weise.
Die Praxis zeigt jedoch, dass es nicht ausreicht, das erforderliche Verhalten in den Spezifikationen zu beschreiben. Wie kann man Zwischenknoten
zwingen , die Schlüsselregel der ClientHello-Verarbeitung zu erfüllen - nicht erkannte Parameter zu ignorieren? Hierzu wird die
GREASE- Methode vorgeschlagen.
FETT: Gegenmittel gegen Ossifikation
GREASE (Generate Random Extensions And Sustain Extensibility) ist eine Methode zum Generieren von
zufälligen Erweiterungen für TLS und zur ständigen Veröffentlichung neuer Versionen des Protokolls. David Benjamin schlägt vor, einen standardmäßigen sechswöchigen Veröffentlichungszyklus einzurichten, der mit der Veröffentlichung neuer Versionen von Chrome zusammenfällt.
Die Freigabe eines solchen "Mülls" in großer Anzahl zwingt Server dazu, die Schlüsselregel der ClientHello-Verarbeitung einzuhalten, um nicht erkannte Parameter zu ignorieren. Es wird sich auch auf Zwischenknoten ausbreiten. Damit sie die Kommunikation zwischen Client und Server nicht stören, lautet die Schlüsselregel für sie: Wenn Sie keine ClientHello-Anfrage gesendet haben, haben Sie nicht das Recht, die Antwort zu verarbeiten. Ebenso sollte das Ökosystem mit einer großen Anzahl solcher Reaktionen überflutet werden.
"Kurz gesagt, wir planen, regelmäßig neue Versionen von TLS (und wahrscheinlich auch andere sensible Parameter wie Erweiterungen) zu stempeln", sagt Benjamin und drückt offenbar den Standpunkt von Google aus. - ungefähr alle sechs Wochen gemäß dem Chrome-Veröffentlichungsplan. Dann unterstützen Chrome, die Server von Google und alle anderen, die teilnehmen möchten, zwei (oder mehr) Versionen von TLS 1.3: die standardmäßige stabile Version 0x0304 und die temporäre alternative Version. Alle sechs Wochen wählen wir zufällig einen neuen Codepunkt aus. Im Übrigen sind diese Versionen mit 1.3 identisch, mit der möglichen Ausnahme kleinerer Details zum Trennen von Schlüsseln und zum Vornehmen zulässiger syntaktischer Änderungen. Ziel ist es, den Weg für zukünftige Versionen von TLS zu ebnen, indem diese nachgeahmt werden (Entwurf einer negativen Version). “
Ein solches Schema birgt bestimmte Risiken, einschließlich Kollisionen von Codepunkten. Darüber hinaus sollten Vorsichtsmaßnahmen getroffen werden, da die Aufgabe darin besteht, die Erweiterbarkeit von TLS aufrechtzuerhalten und aufrechtzuerhalten und die Entwicklung des Protokolls nicht zu beeinträchtigen. Aus Vorsichtsmaßnahmen:
- Detaillierte Dokumentation aller Codepunkte (wenn Sie einen Punkt in anderthalb Monaten ausarbeiten, reichen sie für mehr als 7000 Jahre aus).
- Proaktive Kollisionsvermeidung: Ablehnen von Zahlen, die die IETF auswählen kann.
- BoringSSL aktiviert diese Option standardmäßig nicht. Es wird nur dort aktiviert, wo es deaktiviert werden kann: auf Servern und im Browser. In der Realität werden höchstwahrscheinlich zu jedem Zeitpunkt nur die letzten Codepunkte verwendet. Da sie sich schnell ändern, sollte das Ökosystem nicht an eine solche vorübergehende Erweiterung gebunden sein, und die Implementierungen bleiben miteinander kompatibel.
- Wenn die Methode aus irgendeinem Grund nicht funktioniert, kann das Experiment jederzeit abgebrochen werden.
Die Idee ist interessant, und wenn Google anfängt, auf diese Weise zu handeln, kann es das Ökosystem wirklich vor gefährlicher "Ossifikation" bewahren, die von Anbietern von Lösungen im Bereich "Sicherheit" und anderen spezifischen Unternehmenssystemen angeboten wird. Ein Vertreter von Cloudflare
unterstützte diesen Vorschlag. Auf jeden Fall müsse zumindest etwas getan werden, um das Problem zu vermeiden, auf das wir bei der Implementierung von TLS 1.3 gestoßen sind. Ein anderes Mitglied der IETF-Arbeitsgruppe
nannte es eine „fantastische Idee“ und schlug vor, dass Google eine Wiki-Seite erstellt, die die Codepunkte beschreibt, die es verwendet oder in Zukunft verwenden möchte.
