TLS 1.3 wurde von der Internet Engineering Task Force (IETF) genehmigt. Es umfasst „wesentliche Verbesserungen in den Bereichen Sicherheit, Leistung und Datenschutz“, und im Gegensatz zu TLS 1.2 scheint die Motivation für ein Upgrade bereits integriert zu sein. Allein die Leistungssteigerung, die TLS 1.3 bietet, wird nicht nur die Ohren von Sicherheitsexperten aufhorchen lassen.
Die Vorteile, die TLS 1.3 bietet, sind beträchtlich. Mit einer umfassenderen Verschlüsselung ist es aber auch schwieriger, bösartigen Datenverkehr zu erkennen und Angriffe abzuwehren, die sich in diesem verschlüsselten Datenverkehr verstecken. Dies ist eine echte Bedrohung: Jüngste Forschungen von F5 Labs haben ergeben, dass sich 68 % der Malware in Verschlüsselungen versteckt. Möglicherweise müssen Sie einen neuen Ansatz wählen, um die erforderliche Transparenz erhalten und gleichzeitig das Plus an Leistung zu bewahren, das Sie mit dem neuen Protokoll erzielen.
Die Vorteile, die TLS 1.3 bietet, sind beträchtlich. Mit einer umfassenderen Verschlüsselung ist es aber auch schwieriger, bösartigen Datenverkehr zu erkennen.
TLS 1.3 bietet einige große Verbesserungen gegenüber TLS 1.2. Anfällige optionale Teile des Protokolls wurden entfernt, es gibt Unterstützung für stärkere Verschlüsselungen, die zur Implementierung von Perfect-Forward-Secrecy (PFS) erforderlich sind, und der Handshake-Prozess wurde erheblich verkürzt.
Darüber hinaus sollte die Implementierung von TLS 1.3 relativ einfach sein. Sie können die gleichen Schlüssel verwenden, die Sie für TLS 1.2 verwendet haben. Clients und Server handeln automatisch einen TLS 1.3-Handshake aus, wenn dies von beiden unterstützt wird, und die meisten Mainstream-Browser unterstützen TLS 1.3 standardmäßig auf den neuesten Versionen.
Auch wenn TLS 1.2 immer noch sicher eingesetzt werden kann, haben einige namhafte Schwachstellen optionale Teile des Protokolls und veraltete Chiffren ausgenutzt. TLS 1.3 entfernt viele dieser problematischen Optionen und enthält nur Unterstützung für Algorithmen, die derzeit keine bekannten Schwachstellen aufweisen.
Die IETF entschied sich dafür, alle Chiffren, die PFS nicht unterstützen, aus den TLS-Verbindungen zu entfernen, darunter DES, AES-CBC, RC4 und andere weniger gebräuchliche Chiffren. Außerdem wurde die Möglichkeit entfernt, eine so genannte „Neuverhandlung“ durchzuführen, die es einem Client und Server, die bereits über eine TLS-Verbindung verfügen, ermöglicht, neue Parameter auszuhandeln, neue Schlüssel zu generieren usw. Durch die Abschaffung der Neuverhandlung wurde eine Möglichkeit des Angriffs entfernt.
TLS 1.3 aktiviert außerdem standardmäßig PFS. Diese kryptografische Technik fügt einer verschlüsselten Sitzung eine weitere Vertraulichkeitsebene hinzu, wodurch sichergestellt wird, dass nur die beiden Endpunkte den Datenverkehr entschlüsseln können. Selbst wenn ein Dritter eine verschlüsselte Sitzung aufzeichnen und später Zugriff auf den privaten Schlüssel des Servers erhalten würde, könnte er bei Nutzung von PFS diesen Schlüssel nicht zur Entschlüsselung der Sitzung verwenden.
Was die Leistung betrifft, so spart TLS 1.3 beim Verbindungsaufbau-Handshake einen ganzen Umlauf, wodurch die Verschlüsselungslatenz halbiert wird. Ein weiterer Vorteil ist, dass Sie beim Zugriff auf eine Website, die Sie zuvor besucht haben, nun Daten über die erste Nachricht an den Server senden können. Dies wird als „Null-Umlaufzeit“ (0-RTT) bezeichnet. Diese Verbesserungen, zusammen mit effizienten modernen kryptografischen Algorithmen, machen TLS 1.3 schneller als TLS 1.2.
Bei all diesen Vorteilen, was könnte da schon problematisch sein? Schön, dass Sie fragen! Bei Nutzung von PFS können nur die Endpunkte (der Webbenutzer und der Anwendungsserver) den Datenverkehr entschlüsseln. Wahrscheinlich verfügen Sie aber über eine oder mehrere Lösungen, wie z. B. eine Firewall der nächsten Generation, ein Intrusion-Detection-System (IDS) oder eine Malware-Sandbox, die so konzipiert sind, dass sie bösartigen Datenverkehr, der aus Ihrem Netzwerk austritt, erkennen. Alternativ setzen Sie vielleicht eine Webanwendungs-Firewall, ein IDS oder eine Analyselösung vor einer Anwendung, die Sie hosten, ein. All diese Lösungen befinden sich zwischen einem Benutzer und der Anwendung oder Website, mit der der Benutzer verbunden ist, sodass sie in der Regel blind für den verschlüsselten Datenverkehr sind.
Einige Sicherheitsprüfungstools können zwar entschlüsseln. Dies ist jedoch oft mit Leistungseinbußen bei den Tools verbunden und erhöht die Komplexität Ihrer Netzwerkarchitektur. Außerdem kann eine blinde Entschlüsselung von allem zu Verletzungen der Datenschutzbestimmungen führen.
Erwähnenswert ist, dass einige Sicherheitsexperten wegen des Potenzials für Replay-Angriffe aufgrund der 0-RTT-Funktion in Sorge sind. Und ohne 0-RTT, die in der TLS-Konfiguration aktiviert ist, verlieren Sie möglicherweise den größten Teil der Leistungssteigerung, die Sie überhaupt erst zur Implementierung motiviert hat.
Die Entscheidung, TLS 1.3 zu diesem Zeitpunkt zu implementieren, ist abhängig von Ihren Anforderungen und Motivationen. Es gibt einige Browser, die TLS 1.3 nicht unterstützen, was zu einer negativen Benutzererfahrung führen könnte. Wenn Sie außerdem potenziell anfällige Funktionen wie die Neuverhandlung herausnehmen und PFS für die TLS 1.2-Konfiguration Ihrer Anwendungen verwenden, erhalten Sie dieselben Sicherheits- und Datenschutzvorteile wie bei TLS 1.3. Was eine mögliche Leistungssteigerung betrifft, so sollten Sie gründliche Tests durchführen, um zu sehen, ob dies für Ihre Anwendung zutrifft, da sich der Aufwand bei deaktiviertem 0-RTT möglicherweise nicht lohnt.
Wie auch immer Sie sich entscheiden, es bedeutet nicht, dass frühere Versionen von TLS in absehbarer Zeit verschwinden werden. Google hat angekündigt, dass es TLS 1.0 und 1.1 ab 2020 nicht mehr unterstützen wird, sodass TLS 1.2 noch eine ganze Weile in Umlauf bleiben wird. Mit Ausnahme einiger durchgehender API-Verbindungen müssen Sie die Unterstützung für TLS 1.2 (und möglicherweise 1.1) noch einige Zeit fortsetzen, um sicherzustellen, dass die Verbindungen der Benutzer zu Ihren Anwendungen nicht unterbrochen werden.
Unabhängig von Ihrer TLS-Version müssen Sie Einblick in verschlüsselte Bedrohungen haben, um Ihr Unternehmen zu schützen. SSL/TLS-basierte Entschlüsselungslösungen, die eine Paketprüfung ermöglichen, können verschlüsselten Datenverkehr abfangen sowie nicht vertrauenswürdigen TLS-Datenverkehr, der in das Netzwerk gelangt oder es verlässt, entschlüsseln, prüfen und erneut verschlüsseln. Auch das reicht aber nicht aus.
SSL/TLS-basierte Entschlüsselungslösungen, die eine Paketprüfung ermöglichen, können verschlüsselten Datenverkehr abfangen sowie nicht vertrauenswürdigen TLS-Datenverkehr, der in das Netzwerk gelangt oder es verlässt, entschlüsseln, prüfen und erneut verschlüsseln. Auch das reicht aber nicht aus.
Die Sicherheits- und Netzwerkteams haben festgestellt, dass die Einrichtung von Entschlüsselungszonen nicht einfach ist. Sie müssen oft auf manuelle Verkettungen oder mühsame Konfigurationen zurückgreifen, um die Entschlüsselung bzw. Verschlüsselung über den gesamten Sicherheitsstapel hinweg zu verwalten. Und dann stellen sie fest, dass es zahlreiche Ausnahmen gibt.
Der F5 SSL Orchestrator ermöglicht mehr Transparenz, unterscheidet sich von anderen Produkten jedoch durch die Orchestrierung, die eine richtlinienbasierte Datenverkehrssteuerung für eine Servicekette auf der Grundlage von Risiken und dynamischen Netzwerkbedingungen bietet. Da er sowohl für SSL/TLS als auch für HTTP als Vollproxy fungiert, kann der SSL Orchestrator intelligente Entscheidungen treffen, um ein- und ausgehenden Datenverkehr zu jeder beliebigen Kombination von Prüfungstools innerhalb des Sicherheitsstapels zu leiten.
Egal, wie kompliziert Ihre Verschlüsselungsanforderungen an den ein- und ausgehenden Datenverkehr sind: Der SSL Orchestrator bringt wieder Transparenz in Ihre Prüfungslösungen, wodurch auch Ihr Netzwerk und Ihre Anwendungen sicherer werden.
