- Mitte der 1990er entstand das SSL-Protokoll im Zuge des Browser-Wettbewerbs zwischen Netscape und Microsoft
- SSL 2 hatte kryptografische und praktische Schwächen, woraufhin Microsoft das PCT-Protokoll einführte
- Netscape entwickelte als Gegenmaßnahme SSL 3.0, um die Führung zu behaupten
- Branche und Community wollten die Kompatibilität zwischen Browsern erhalten und übertrugen dem IETF die Rolle der Standardisierung
- In diesem Prozess wurde der Protokollname in TLS 1.0 geändert, was bis heute so fortgeführt wird
Hintergrund: Browser-Wettbewerb und die Entstehung von Sicherheitsprotokollen
- Mitte der 1990er lieferten sich Netscape und Microsoft einen erbitterten Wettbewerb auf dem Browsermarkt
- In diesem Konkurrenzkampf entwickelte Netscape das SSL-Protokoll
SSL 2 und seine Probleme
- Die erste Version von SSL wurde wegen kryptografischer Schwächen sofort verworfen und nicht veröffentlicht
- Das tatsächlich ausgelieferte SSL 2 wurde einige Jahre lang verwendet, hatte jedoch mehrere kryptografische und praktische Schwächen
- Diese Mängel bedeuteten zwar keine sofortige katastrophale Gefahr, doch der Bedarf an Verbesserungen wurde immer wieder betont
Microsofts Reaktion: das PCT-Protokoll
- Mit der Verschärfung des Wettbewerbs ergänzte Microsoft SSL 2 um eigene Funktionen und führte das Protokoll PCT ein
- PCT wurde nur von Internet Explorer (IE) und IIS unterstützt
Netscapes neue Strategie: SSL 3.0
- Auch Netscape wollte die Probleme von SSL 2 beheben, wollte Microsoft aber nicht die Führung überlassen
- Daher entwickelte das Unternehmen SSL 3.0 und strebte Veränderungen an, die sich klar vom Bestehenden unterschieden
Standardisierungsgespräche in der Browserbranche
- Branche und Community wollten keine Aufspaltung des Protokolls (um einen Fork zu vermeiden)
- Bei Consensus Development (dem Arbeitsplatz des Autors) wurde ein Treffen von Vertretern von Netscape und Microsoft organisiert
- An diesem Treffen nahmen unter anderem Bruce Schneier (noch bevor er berühmt wurde), Paul Kocher (Designer von SSL 3) und Barbara Fox (Vertreterin von Microsoft) teil
Standardisierung durch das IETF und die Umbenennung
- Sowohl Netscape als auch Microsoft stimmten zu, dass das IETF (Internet Engineering Task Force) den Standardisierungsprozess des Protokolls führen sollte
- Der Autor war für die Redaktion des IETF-Standarddokuments (RFC) zuständig
- Als Teil eines politischen Kompromisses mussten an SSL 3.0 einige Änderungen vorgenommen und auch ein neuer Name vergeben werden (um nicht den Eindruck zu erwecken, das IETF würde das bestehende Protokoll einfach „durchwinken“)
- So entstand letztlich die Bezeichnung TLS 1.0; tatsächlich entspricht das Protokoll SSL 3.1
Schlusswort
- Rückblickend wirkt dieser gesamte Prozess rund um Benennung und Standardisierung etwas absurd
1 Kommentare
Hacker-News-Kommentare
Erläuterung einer verwirrenden Situation, in der man allein anhand der Versionsnummern kaum erkennen kann, wie stark sich die Protokolle unterschieden: SSLv2 war die erste breit eingesetzte SSL-Version, hatte aber mehrere Probleme. SSLv3 war ein fast vollständig neu entwickeltes Protokoll. TLS 1.0 war SSLv3 sehr ähnlich, wurde aber im Zuge der IETF-Standardisierung leicht überarbeitet. TLS 1.1 war eine kleinere Korrekturversion, um Probleme bei der Verwendung von Blockchiffren in TLS 1.0 zu beheben. TLS 1.2 war eine Version mit mittelgroßen Änderungen entsprechend dem Fortschritt der Kryptografie, darunter Unterstützung für moderne Hashes als Reaktion auf Schwachstellen in MD5 und SHA-1 sowie für AEAD-Cipher-Suites wie AES-GCM. TLS 1.3 ist größtenteils ein neu entwickeltes Protokoll, übernimmt aber einige Merkmale von TLS 1.2 und älter. Jedes Protokoll wurde mit automatischer Versionsaushandlung entworfen, damit Clients und Server unabhängig voneinander aktualisiert werden können, ohne die Konnektivität zu verlieren.
Wenn man bedenkt, dass Microsoft damals ein völlig anderes Unternehmen war als heute, wirkt das selbst nach heutigen Maßstäben gar nicht ungewöhnlich. Damals setzte „M$“ alle Mittel ein, um Open-Source-Internettechnologien auszubremsen, und diese Haltung hielt bis in die frühen 2010er Jahre an. Ich denke, das hat dazu beigetragen, dass Java-Applets sich nicht weiterentwickelten und letztlich vom Markt verschwanden. Auch die Entwicklung von JavaScript und CSS fühlte sich über Jahre hinweg gebremst an. Mein Arbeitgeber drängte auf die neuesten IE-Technologien, aber ich entschied mich stattdessen für Mozilla 3.0, und nachdem ich JS-Bugs behoben hatte, setzte ich Mozilla für die Entwicklung von Enterprise-SPAs ein. Später wurde Mozilla/Firefox sogar in Fortune-500-Unternehmen vermehrt für interne Apps eingeführt, und rückblickend war das die richtige Entscheidung.
Meinung dazu, ob man den Namen der nächsten Version nicht einfach wieder auf SSL zurücksetzen könnte. Es wird argumentiert, dass ohnehin noch jeder die Bezeichnung „SSL“ verwendet, also könne man sie auch weiter benutzen.
Es wird darauf hingewiesen, dass auch die Bezeichnung „TLS“ bereits an vielen Stellen verwendet wird. Änderungen an Konfigurationen und Funktionssignaturen seien äußerst mühsam, daher sei das eine Abwägung.
Es wird betont, dass man mit solchen Ideen niemanden inspirieren möchte.
Wenn ich jemandem erkläre, wie er den Zugriff auf eine Website absichern soll, also wenn ich die Begriffe TLS/SSL verwende, frage ich normalerweise, welche Bezeichnung andere verwenden. Außerdem interessiert mich, wie alt sie sind und ob sie vor 1999 gearbeitet haben. Ich werde meine eigene Antwort gleich ebenfalls posten.
Ich sage „SSL“ (27 Jahre). Im Code verwende ich allerdings
tls, und in Dokumentationen bevorzuge ich zur Vermeidung von Verwirrung die Schreibweise SSL/TLS.sslCertNotBefore. Vielleicht liegt das daran, dass Programmierer TLS meist nicht direkt anfassen. Auch mein Code musste Zertifikatsinformationen aus HTTPS parsen, was ziemlich umständlich war. Durch all die Automatisierung und Abstraktion lässt sich das zwar fehlerfrei erledigen, aber sie erschweren zugleich ein tiefes Verständnis dafür, wie TLS eigentlich funktioniert.Die meisten implementieren sichere Kommunikation mit Bibliotheken, in deren Namen
sslvorkommt, etwa OpenSSL, deshalb verwenden viele auch die Bezeichnung SSL. Neben OpenSSL gibt es auch BoringSSL, LibreSSL und wolfSSL. Bibliotheken mit TLS im Namen sind weniger bekannt, zum Beispiel GnuTLS, mbedTLS, s2n-tls und RustTLS.Der Hauptgrund, warum ich den Begriff SSL verwende, ist, dass er offenbar besser verstanden wird. Streng genommen ist TLS korrekt, denn SSL 3.0 nutzt in Wirklichkeit niemand mehr, aber da selbst in den wichtigsten Bibliotheken der Begriff SSL erhalten geblieben ist, benutze ich ihn weiter. Ich habe die Bezeichnung SSL tatsächlich in den Krypto-Kriegen der 90er gelernt, und weil man damals für echte SSL-Verschlüsselung Netscape in der „US only“-Version illegal herunterladen musste, ist mir der Begriff einfach vertraut geblieben.
Ich sage normalerweise „https“. Das verstehen auch Laien oft ungefähr, deshalb bevorzuge ich es.
Mir ist gerade erst bewusst geworden, dass ich SSL und TLS unbewusst gar nicht sauber voneinander unterschieden habe. Faszinierend, nach 20 Jahren den eigentlichen Grund zu erfahren.
„Transport Layer Security“ ist eindeutig der bessere Name. Ich mag auch das Wort TLS. Zwei S-Laute hintereinander klingen wie eine Schlange, was ich irgendwie lustig finde.
Allerdings ist TLS auch als Abkürzung für „Thread Local Storage“ weit verbreitet. „Transport Layer Security“ ist zwar seit 1999 offiziell in Gebrauch, aber „Thread Local Storage“ existierte schon vor 1996 in Entwicklungsumgebungen von MS oder IBM. In der Unix-Welt wurde seit dem Auftauchen von pthread 1995 eher der Begriff thread-specific data bevorzugt. Möglicherweise hat auch das Itanium-ABI-Dokument von 2001 dazu beigetragen, dass „TLS“ sich stärker verbreitete, und vielleicht verwendete Sun Microsystems den Begriff ebenfalls schon. Falls jemand noch ein OS/2-Handbuch besitzt, wären entsprechende Referenzen interessant.
Ich finde eher, dass SSL der passendere Name ist. Theoretisch müsste TLS ein allgemeiner Sicherheitsmechanismus sein, der auf mehreren Schichten funktioniert und sich etwa auch mit IPSec kombinieren ließe, praktisch wird es aber fast nur für TCP-Sockets verwendet. Varianten für UDP gibt es mit DTLS und QUIC, aber sie gehören nicht zu TLS selbst. Inzwischen gibt es auch Linux-Kernel-TLS und Windows-spezifische Infrastrukturen, aber sie lassen sich nicht einfach so leicht wie ein Socket-Flag aktivieren. Und ehrlich gesagt klingt das zischende S wie bei einer Schlange einfach cool.
„SSL“ lässt sich leichter aussprechen als „TLS“. Bei S-S-L muss sich die Zunge beim Aussprechen kaum neu positionieren, daher geht es schneller und natürlicher.
Wenn Kaa aus dem Dschungelbuch über TCP-Sicherheit sprechen würde, würde ein Name wie S~S~L perfekt passen. Eigentlich wäre es sogar lustig, einfach noch ein S draufzulegen und es SSSL zu nennen.
Menschen, die TLS und SSL strikt unterscheiden, wollen oft zeigen, dass sie den Unterschied genau kennen, oder wünschen sich, dass man genauso spricht. Die tatsächliche Unterscheidung ist ein bisschen wie bei .doc und .docx: technisch verschieden, aber für normale Nutzer fast austauschbar. Den meisten ist nur wichtig, dass HTTPS funktioniert; für interne Struktur oder Funktionsweise interessieren sie sich kaum.
Relevanter Link: der 1996 geschriebene Artikel „Randomness and the Netscape Browser“ (Dr. Dobb's Journal) https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html. Da der Text von 1996 ist, unterscheidet sich schon die sprachliche Grundstimmung stark von heutigen Papers oder Artikeln. Er wirkt spürbar gealtert.
Frage, ob TLS 1.0 gegenüber SSL 3.0 in Wirklichkeit nicht doch viele Verbesserungen gebracht habe. Im Artikel klang es eher so, als sei es nur als kleine Anpassung zur Abgrenzung beschrieben worden.
Im Internet unterstützen noch immer mehr als 300.000 Dienste SSLv2. Link: https://shodan.io/search/report/…. Trendgrafik: https://trends.shodan.io/search?query=ssl.version%3Asslv2#overview. Die Zahlen sind über die Jahre deutlich gesunken, aber bis es ganz verschwunden ist, dürfte es noch dauern.