en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

TLS 1.3 Ist hier, um zu bleiben

Die Welt bewegt sich zu TLS 1.3, was sehr gut ist! Dieser Artikel bietet einen allgemeinen Überblick über TLS 1.3 und eine Diskussion über die Wirksamkeit seiner neuen Funktionen.

Transport Layer Security

Transportschicht-Sicherheit oder TLSist ein kryptografisches Protokoll, das Daten schützt, die über ein Computernetzwerk ausgetauscht werden. TLS ist berühmt geworden als die S in HTTPS. Genauer, TLS wird verwendet, um Webbenutzerdaten vor Netzwerkangriffen zu schützen.

TLS wurde als sicherere Alternative zu seinem Vorgänger konzipiert Secure Sockets Layer (SSL). Im Laufe der Jahre haben Sicherheitsforscher unzählige Sicherheitslücken entdeckt, die sich auf SSL auswirken und die IETF zum Design motiviert haben TLS in dem Bemühen, sie zu mildern.

Ironischerweise frühere Versionen von TLS waren auch von gefährlichen Schwachstellen betroffen, die letztendlich dazu führten TLS 1.2 (dh die von Branchenfachleuten empfohlene Standardversion).

Die meisten bekannten Protokollschwachstellen wurden behoben TLS 1.2, aber diese Sicherheitsstufe war immer noch das Ergebnis einer Reihe von Patches auf einem fehlerhaften Design.

Als Antwort, TLS 1.3 wurde von Grund auf neu entworfen, um ein modernes und sicheres Design sauber zu gestalten TLS Protokoll. Fünf Jahre später wurde es endgültig genehmigt und ist nun fast der Standardstandard für die Internetsicherheit.

TLS Versionen und ihre jeweiligen RFC-Dokumente finden Sie in der folgenden Liste:

  • TLS 1.0 wurde veröffentlicht als RFC 2246 in 1996
  • TLS 1.1 wurde veröffentlicht als RFC 4346 in 2006
  • TLS 1.2 wurde veröffentlicht als RFC 5246 in 2008
  • TLS 1.3 wurde als vorgeschlagener Standard in veröffentlicht RFC 8446 von Studenten unterstützt.

Wie geht es älteren TLS Versionen funktionieren?

Um die Vorteile von effektiv zu diskutieren TLS 1.3 müssen wir zuerst darüber sprechen, wie älter TLS Versionen funktionieren (und wie sie nicht funktionieren).

TLS ist ein Hybride Kryptosystem, was bedeutet, dass es beide verwendet asymmetrisch (öffentlicher Schlüssel) und symmetrisch (passwort- / phrasenbasierte) Verschlüsselung. Das ist wegen asymmetrische Kryptographie Größenordnungen langsamer als seine symmetrischen Äquivalente.

Folglich TLS Verwendet nur öffentliche Schlüssel, damit Clients und Server einen symmetrischen Schlüssel sicher austauschen können. Dieser Schlüssel kann dann verwendet werden, um alle nachfolgenden Kommunikationen zu verschlüsseln, wodurch der durch asymmetrische Verschlüsselung verursachte Leistungsaufwand vermieden wird.

TLS 1.2 unterstützt mehrere Schlüsselaustauschalgorithmen (z. B. RSA, DH usw.) sowie mehrere Algorithmen (auch bekannt als Chiffren) zum Ver- und Entschlüsseln von Nachrichten. Für diese große Anzahl alternativer Optionen müssen Clients und Server verhandeln, damit alle Parteien dasselbe verwenden TLS Parameter.

Diese Aushandlung ist in einem Protokoll standardisiert Handschlag. Wenn Sie damit nicht vertraut sind, lesen Sie bitte Dieser Artikel für weitere informationen.

Also, was ist los mit TLS 1.2?

Obwohl TLS 1.2 hat sich in den meisten Fällen als einwandfrei erwiesen. Nach Jahren des Patchens und Überarbeitens bestehen Bedenken hinsichtlich des allgemeinen Sicherheits- und Datenschutzniveaus.

Abgesehen von Sicherheitsüberlegungen TLS 1.2 verursacht auch unnötige Leistung und Netzwerk-Overhead.

TLS 1.2 Sicherheitsprobleme

Im Laufe der Jahre haben Forscher (und Angreifer) in vielen Fällen eine Reihe von Sicherheitslücken entdeckt TLS 1.2 Komponenten, einschließlich Schlüsselaustauschalgorithmen, Chiffren und digitaler Signaturen. Einige davon waren Implementierungsfehler, von denen Sie vielleicht schon gehört haben, wie z Heartbleed or BERserk. Einige waren jedoch Protokollschwachstellen - das heißt, sie nutzen frühere Fehlentscheidungen aus TLS Versionen (dh vorher TLS 1.2).

Obwohl der Großteil der Implementierung und andere Fehler behoben wurden TLS 1.2, leider können die Schwachstellen im Protokolldesign nicht nur mit einem Software-Patch behoben werden. Wie sich herausstellte, musste die IETF dazu das Handshake-Protokoll komplett neu gestalten TLS 1.3

Es gab viele Bedenken TLS Sicherheit, aber eine der wirkungsvollsten war die Erkenntnis, dass TLS 1.2 (und alle früheren Versionen, einschließlich SSL) ist aufgrund eines Fehlers im Design des Handshake-Protokolls anfällig für Downgrade-Angriffe. Genauer, TLS 1.2 verwendet keine digitalen Signaturen, um die Integrität des Handshakes zu schützen. Signaturen schützen einen Teil des Handshakes erst nach der Aushandlung der Chiffresuite.

Infolgedessen können Angreifer alle Cipher-Suite-Verhandlungen von Drittanbietern manipulieren, die im selben Computernetzwerk stattfinden (z. B. Flughafen-WLAN), und die Verwendung einer unsicheren Verschlüsselung erzwingen. Sie können dann diese anfällige Chiffre aufheben und ungerechtfertigten Zugriff auf die gesamte Konversation erhalten.

TLS 1.2 Leistungsprobleme

Neben diesen Sicherheitsüberlegungen TLS 1.2s Notwendigkeit, zahlreiche zu verhandeln TLS Parameter können HTTPS (oder anderen) einen Leistungsaufwand auferlegen TLS geschützte) Kommunikation.

TLS Der 1.2-stufige Handshake von 4 erfordert zwei Round-Trip-Austausche, um zuerst die Chiffresuite auszuwählen und dann die Zertifikate und symmetrischen Schlüssel (oder Schlüsselfreigaben) auszutauschen.

Dies bedeutet, dass für jeden TLS Verbindung hergestellt werden, zwei zusätzliche Transaktionen mit dem Server sind erforderlich. Als Ergebnis, TLS Verbindungen erfordern mehr Bandbreite und Leistung als (unverschlüsseltes) HTTP, was für Internet-of-Things-Anwendungen (IoT) besonders kostspielig sein kann, bei denen ein geringer Strom- und Bandbreitenverbrauch harte Einschränkungen darstellt.

TLS 1.2 Datenschutzprobleme

Schließlich TLS 1.2 wurde wegen Beeinträchtigung der Privatsphäre von Webbenutzern kritisiert.

Genauer gesagt, TLS bietet eine Erweiterung bekannt als Servername-Angabe oder SNI. Mit SNI kann der Hostname eines Servers in den anfänglichen SSL-Handshake einbezogen werden. Diese Erweiterung wird für virtuelles Hosting verwendet, bei dem Server möglicherweise mehrere Domänen mit derselben IP-Adresse und demselben Port bedienen und für jede Domäne ein anderes Zertifikat vorlegen.

In TLS 1.2 werden SNIs gesendet unverschlüsseltTrotz der Verwendung von HTTPS kann ein Netzwerkangreifer diese Informationen verlieren und die Webseiten verfolgen, die ein Benutzer besucht.

Wie funktioniert TLS 1.3 das alles reparieren?

TLS 1.2 (und frühere Versionen) konzentrierten sich auf die Aufrechterhaltung der Abwärtskompatibilität. Jede Version baut auf den vorherigen auf, mit geringfügigen Überarbeitungen, die versuchen, die zwischen veröffentlichten Versionen zu beseitigen TLS Versionen.

Leider bedeutete dies auch, dass schlechte Entscheidungen zum Protokolldesign (z. B. der ungeschützte Handshake) auch in den neueren Versionen vererbt wurden.

TLS 1.3 verzichtet auf Abwärtskompatibilität zugunsten eines ordnungsgemäßen Sicherheitsdesigns. Es wurde von Grund auf neu entwickelt, um ähnliche (aber nicht kompatible) Funktionen bereitzustellen TLS 1.2, jedoch mit deutlich verbesserter Leistung, Datenschutz und Sicherheit.

TLS 1.3-Sicherheit

Ein Kernsatz von TLS 1.3 ist Einfachheit. In der neuen Version sind alle Schlüsselaustauschalgorithmen außer dem Diffie-Hellman (DH) Schlüsselaustausch wurden entfernt. TLS 1.3 hat außerdem eine Reihe bewährter DH-Parameter definiert, sodass keine Parameter mehr mit dem Server ausgehandelt werden müssen.

Was ist mehr, TLS 1.3 unterstützt keine unnötigen oder anfälligen Chiffren mehr wie den CBC-Modus und die RC4-Chiffre. Diese Chiffren sind bekanntermaßen anfällig für Angriffe, wurden jedoch in den meisten Fällen weiterhin unterstützt TLS Implementierungen für Legacy-Kompatibilität. Glücklicherweise wirkt sich der jüngste Ansturm von Downgrade-Angriffen frühzeitig aus TLS Versionen motivierten die IETF, solche Chiffren vollständig zu entfernen TLS 1.3

In Ergänzung, TLS 1.3 erfordert, dass Server den gesamten Handshake einschließlich der Verschlüsselungsverhandlung kryptografisch signieren, wodurch Angreifer daran gehindert werden, Handshake-Parameter zu ändern. Dies bedeutet, dass TLS 1.3 ist architektonisch undurchlässig für die zuvor betroffenen Downgrade-Angriffe TLS Versionen.

Schließlich wurden auch die Signaturen selbst durch die Implementierung eines neuen Standards namens "Called" verbessert RSA-PSS. RSA-PSS-Signaturen sind immun gegen kryptografische Angriffe, die sich auf die früher verwendeten Signaturschemata auswirken TLS Versionen.

TLS 1.3-Leistung

Neben verbesserter Sicherheit, dem reduzierten Parametersatz und dem vereinfachten Handshake-In TLS 1.3 trägt auch zur Verbesserung der Gesamtleistung bei. Da es nur einen Schlüsselaustauschalgorithmus (mit eingebauten Parametern) und nur eine Handvoll unterstützter Chiffren gibt, ist die absolute Bandbreite erforderlich, um a einzurichten TLS 1.3 Kanal ist erheblich weniger als frühere Versionen.

Außerdem, TLS 1.3 unterstützt jetzt ein neues Handshake-Protokoll namens 1-RTT-Modus. In 1-RTT kann der Client in der ersten Handshake-Nachricht DH-Schlüsselfreigaben senden, da die vom Server verwendeten Parameter ziemlich sicher sein können. In dem seltenen Fall, dass der Server sie nicht unterstützt, kann ein Fehler auftreten, sodass der Client eine andere Konfiguration sendet.

Anstatt zuerst die Parameter auszuhandeln und dann Schlüssel oder Schlüsselfreigaben auszutauschen, TLS 1.3 ermöglicht es einem Client, a einzurichten TLS Kanal mit nur einer Hin- und Rücktransaktion (anstelle von zwei, wie zuvor). Dies kann einen großen kumulativen Effekt auf die Verarbeitungs-, Leistungs- und Netzwerkressourcen haben, die ein Client für die Kommunikation mit einem Server benötigt TLS 1.3

Leistungsoptimierungen hören hier jedoch nicht auf TLS 1.3 Funktion, genannt 0-RTT-Wiederaufnahmemodus. Wenn ein Browser zum ersten Mal einen Server besucht und a erfolgreich abschließt TLS Beim Handshake können sowohl der Client als auch der Server einen vorinstallierten Verschlüsselungsschlüssel lokal speichern.

Wenn der Browser den Server erneut besucht, kann er diesen Wiederaufnahmeschlüssel verwenden, um verschlüsselte Anwendungsdaten in seiner ersten Nachricht an den Server zu senden. Dies hat die gleiche Latenz wie unverschlüsseltes HTTP, da keine ersten Handshakes erforderlich sind.

Es sollte beachtet werden, dass es eine gewisse Sicherheit gegeben hat Bedenken über 0-RTT-Modus in der Vergangenheit.

TLS 1.3-Datenschutz

Aus Fehlern der Vergangenheit lernen, TLS 1.3 bietet jetzt eine Erweiterung das verschlüsselt SNI-Informationen. Bei korrekter Verwendung verhindert diese Erweiterung, dass Angreifer den Domänennamen des Remoteservers verlieren, sodass sie keine Methode zum Verfolgen des HTTPS-Benutzerverlaufs haben. Diese Funktion bietet Internetbenutzern mehr Datenschutz als frühere Versionen von TLS.

Fazit

Während TLS 1.2 hat all die Jahre ehrenhaft gedient, TLS 1.3 ist nachweislich sicherer und effizienter. TLS 1.3 wurde ausführlich in experimentellen Browser-Implementierungen getestet und kann jetzt ersetzt werden TLS 1.2 als Netzwerksicherheitsprotokoll der Wahl. Veröffentlichen TLS 1.3 ist ein großer Schritt in Richtung eines schnelleren und sichereren Internets für alle.

Vielen Dank, dass Sie sich für SSL.com entschieden haben Sicherheit Internet ist ein better Internet.

Verwandte Artikel

Abonnieren Sie den Newsletter von SSL.com

Was ist SSL /TLS?

Video abspielen

Abonnieren Sie den Newsletter von SSL.com

Verpassen Sie keine neuen Artikel und Updates von SSL.com