Unterschied zwischen SSL und TLS


88

Laut Wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security

Scheint, als wäre TLS ein Ersatz für SSL, aber die meisten Websites verwenden immer noch SSL?


4
"Die meisten Websites verwenden immer noch SSL". Hier ist eine gute Übersicht über die Protokollunterstützung trustworthyinternet.org/ssl-pulse/#chart-protocol-support
Colonel Panic

Antworten:


59

Kurz gesagt, TLSv1.0 ist mehr oder weniger SSLv3.1. Weitere Details finden Sie in dieser Frage unter ServerFault .

Die meisten Websites unterstützen zumindest SSLv3 und TLSv1.0, wie aus dieser Studie hervorgeht ( Artikel von Lee, Malkin und Nahum: Kryptografische Stärke von SSL / TLS-Servern: Aktuelle und aktuelle Praktiken , IMC 2007) (Link aus der IETF-TLS-Liste) ). Mehr als 98% unterstützen TLSv1 +.

Ich denke, der Grund, warum SSLv3 immer noch verwendet wird, war die Legacy-Unterstützung (obwohl die meisten Browser heutzutage TLSv1 und einige TLSv1.1 oder sogar TLSv1.2 unterstützen). Bis vor nicht allzu langer Zeit war auf einigen Distributionen neben den anderen standardmäßig SSLv2 (als unsicher eingestuft) aktiviert.

( Diese Frage ist möglicherweise auch interessant, obwohl es sich eher um das Verwendungsmuster von TLS als um SSL im Vergleich zu TLS handelt (Sie könnten tatsächlich dasselbe Muster mit SSL verwenden). Dies gilt ohnehin nicht für HTTPS, da HTTPS SSL / TLS verwendet vom Beginn der Verbindung.)


23

Von http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

In den frühen 90er Jahren, zu Beginn des World Wide Web, entwickelten einige Ingenieure von Netscape ein Protokoll zum Erstellen sicherer HTTP-Anforderungen, und das, was sie entwickelten, hieß SSL. Angesichts des damals relativ geringen Wissens über sichere Protokolle und des starken Drucks, unter dem alle Mitarbeiter von Netscape arbeiteten, können ihre Bemühungen nur als unglaublich heldenhaft angesehen werden. Es ist erstaunlich, dass SSL im Gegensatz zu einer Reihe anderer Protokolle aus demselben Jahrgang so lange Bestand hat. Seitdem haben wir definitiv viel gelernt, aber das Besondere an Protokollen und APIs ist, dass es nur sehr wenig gibt.

Es gab zwei wichtige Aktualisierungen des SSL-Protokolls, SSL 2 (1995) und SSL 3 (1996). Diese wurden sorgfältig durchgeführt, um abwärtskompatibel zu sein und die Übernahme zu erleichtern. Die Abwärtskompatibilität ist jedoch eine Einschränkung für ein Sicherheitsprotokoll, für das es eine Abwärtsanfälligkeit bedeuten kann.

Daher wurde beschlossen, die Abwärtskompatibilität und das neue Protokoll TLS 1.0 (1999) zu unterbrechen . (Im Nachhinein könnte es klarer gewesen sein, es TLS 4 zu nennen)

Die Unterschiede zwischen diesem Protokoll und SSL 3.0 sind nicht dramatisch, aber sie sind signifikant genug, dass TLS 1.0 und SSL 3.0 nicht zusammenarbeiten.

TLS wurde zweimal überarbeitet, TLS 1.1 (2006) und TLS 1.2 (2008).

Ab 2015 sind alle SSL-Versionen defekt und unsicher (der POODLE-Angriff), und die Browser entfernen die Unterstützung. TLS 1.0 ist allgegenwärtig, aber nur 60% der Websites unterstützen TLS 1.1 und 1.2 , ein trauriger Zustand.


Wenn Sie an diesem Zeug interessiert sind, empfehle ich Moxie Marlinspikes kluges und lustiges Gespräch unter https://www.youtube.com/watch?v=Z7Wl2FW2TcA


Ich erinnere mich an eine Usenet-Nachricht: comp.sources.unix mit dem Titel Secure Sockets Layer Ende der 1980er Jahre. Ich bezweifle, dass es eine große Beziehung zu dem gibt, was Netscape außer dem Namen getan hat.
Marquis von Lorne

10

tls1.0 bedeutet sslv3.1

tls1.1 bedeutet sslv3.2

tls1.2 bedeutet sslv3.3

Der RFC hat gerade den Namen geändert. Sie können feststellen, dass der Hex-Code von tls1.0 0x0301 ist, was sslv3.1 bedeutet


2

TLS behält die Abwärtskompatibilität mit SSL bei und daher ist das Kommunikationsprotokoll in jeder der hier genannten Versionen nahezu identisch. Die beiden wichtigen Unterschiede zwischen SSL v.3, TLS 1.0 und TLS 1.2 sind die Pseudozufallsfunktion (PRF) und die HMAC-Hashing-Funktion (SHA, MD5, Handshake), mit der ein Block symmetrischer Schlüssel für erstellt wird Anwendungsdatenverschlüsselung (Serverschlüssel + Clientschlüssel + IV). Der Hauptunterschied zwischen TLS 1.1 und TLS 1.2 besteht darin, dass 1.2 die Verwendung von "expliziter" IV zum Schutz vor CBC-Angriffen erfordert, obwohl hierfür keine Änderungen an PRF oder Protokoll erforderlich sind. TLS 1.2 PRF ist Cipher-Suite-spezifisch, was bedeutet, dass PRF während des Handshakes ausgehandelt werden kann. SSL wurde ursprünglich von Netscape Communications (historisch) entwickelt und später von der Internet Engineering Task Force (IETF, aktuell) verwaltet. TLS wird von der Netzwerkarbeitsgruppe verwaltet. Hier sind die Unterschiede zwischen PRF-HMAC-Funktionen in TLS:

TLS 1.0 und 1.1

PRF (Geheimnis, Etikett, Samen) = P_MD5 (S1, Etikett + Samen) XOR P_SHA-1 (S2, Etikett + Samen);

TLS 1.2

PRF (Geheimnis, Etikett, Samen) = P_hash (Geheimnis, Etikett + Samen)


0

"Wenn es nicht kaputt ist, fass es nicht an". SSL3 funktioniert in den meisten Szenarien einwandfrei (im Oktober wurde ein grundlegender Fehler im SSL / TLS-Protokoll festgestellt, dies ist jedoch eher ein Fehler von Anwendungen als von einem Procol selbst), sodass Entwickler sich nicht beeilen müssen, ihre SSL-Module zu aktualisieren. TLS bietet eine Reihe nützlicher Erweiterungen und Sicherheitsalgorithmen, die jedoch eine praktische Ergänzung und kein Muss darstellen. Daher bleibt TLS auf den meisten Servern eine Option. Wenn sowohl Server als auch Client dies unterstützen, wird es verwendet.

Update: In '2016 wurde festgestellt, dass SSL 3 und sogar TLS bis 1.2 anfällig für verschiedene Angriffe sind. Eine Migration auf TLS 1.2 wird empfohlen. Es gibt auch Angriffe auf Implementierungen von TLS 1.2, obwohl diese serverabhängig sind. TLS 1.3 befindet sich derzeit in der Entwicklung. Und jetzt ist TLS 1.2 ein Muss.


2
Nein, dies ist ein Protokollfehler, und Entwickler sollten ihre SSL-Stacks aktualisieren. Vor diesem Hintergrund gibt es Richtlinien für die Verwendung der Neuverhandlungserweiterung in RFC 5746 für SSLv3 sowie für TLS.
Bruno

Wenn Sie jemanden mit dem Messer töten, ist dies kein Messerfehler, sondern der Ihres Gehirns. Hier gilt das gleiche. Wenn das Protokoll so verwendet wurde, wie es nicht entwickelt wurde, ist es kein Fehler des Protokolls.
Eugene Mayevski 'Rückruf

1
Das Protokoll wurde so konzipiert, dass die Anwendung darüber es so weit wie möglich als normalen Socket behandeln sollte. Das Problem der Neuverhandlung ohne die neue Erweiterung erzwingt das Bewusstsein der Anwendungsschicht (z. B. HTTP). Es gibt einen interessierten Thread zu diesem Thema auf der IETF TLS-Mailingliste: ietf.org/mail-archive/web/tls/current/msg04000.html
Bruno

1
Ich bin damit einverstanden, dass ein Teil davon auf Anwendungsebene durchgeführt werden sollte, aber mir ist keine Implementierung bekannt, und das Protokoll berücksichtigt dies. Die Stapel können normalerweise mit Neuverhandlungen fertig werden, die sie legitim initiieren, aber nicht so sehr, wenn ein MITM sie initiiert (was das Problem ist). Aus diesem Grund hat sich die IETF-TLS-Gruppe entschieden, das Problem auf TLS-Ebene zu beheben, und aus diesem Grund sollten die Benutzer diese Erweiterung wirklich einschalten oder die Neuverhandlung insgesamt deaktivieren.
Bruno

1
In SSL 3.0 gibt es grundlegendere Probleme als das von Ihnen erwähnte. ZB CBC-Padding-Orakel sowie die Wiederverwendung der IV oder der vorherigen Aufzeichnung. Ersteres plagt TLS immer noch, kann aber umgangen werden, während letzteres auf TLS 1.1 behoben ist.
Nikos

0

https://hpbn.co/transport-layer-security-tls/ ist eine gute Einführung

Das SSL-Protokoll wurde ursprünglich bei Netscape entwickelt, um die Sicherheit von E-Commerce-Transaktionen im Web zu ermöglichen. Dies erforderte eine Verschlüsselung zum Schutz der persönlichen Daten der Kunden sowie Authentifizierungs- und Integritätsgarantien, um eine sichere Transaktion zu gewährleisten. Um dies zu erreichen, wurde das SSL-Protokoll auf der Anwendungsebene direkt über TCP implementiert (Abbildung 4-1), sodass die darüber liegenden Protokolle (HTTP, E-Mail, Instant Messaging und viele andere) unverändert funktionieren und gleichzeitig Kommunikationssicherheit bieten können Kommunikation über das Netzwerk.

Bei korrekter Verwendung von SSL kann ein Beobachter eines Drittanbieters nur die Verbindungsendpunkte, die Art der Verschlüsselung sowie die Häufigkeit und die ungefähre Menge der gesendeten Daten ableiten, jedoch keine der tatsächlichen Daten lesen oder ändern.

SSL 2.0 war die erste öffentlich veröffentlichte Version des Protokolls, wurde jedoch aufgrund einer Reihe entdeckter Sicherheitslücken schnell durch SSL 3.0 ersetzt. Da das SSL-Protokoll Eigentum von Netscape war, bemühte sich die IETF, das Protokoll zu standardisieren, was zu RFC 2246 führte, das im Januar 1999 veröffentlicht wurde und als TLS 1.0 bekannt wurde. Seitdem hat die IETF das Protokoll weiter durchlaufen, um Sicherheitslücken zu schließen und ihre Funktionen zu erweitern: TLS 1.1 (RFC 2246) wurde im April 2006 veröffentlicht, TLS 1.2 (RFC 5246) im August 2008 und die Arbeit ist jetzt läuft, um TLS 1.3 zu definieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.