Warum SSL Ende der 90er in TLS umbenannt wurde
(tim.dierks.org)- Als während der Browserkriege Mitte der 1990er-Jahre die Gefahr wuchs, dass Netscapes SSL und Microsofts PCT auseinanderdriften würden, versuchte die Branche, sie in einem offenen Standard zusammenzuführen
- Das frühe SSL wurde wegen Mängeln nie veröffentlicht, und auch die erste tatsächlich eingesetzte Version, SSL 2, war zwar einige Jahre in Gebrauch, hatte aber kryptografische und praktische Einschränkungen
- Microsofts PCT war eine eigene, auf SSL 2 basierende Erweiterung, zugeschnitten auf IE und IIS; Netscape reagierte mit SSL 3.0, um die Führung bei der Standardisierung nicht zu verlieren
- Netscape und Microsoft einigten sich auf das offene Standardisierungsverfahren der IETF, doch die IETF musste vermeiden, den Eindruck zu erwecken, sie würde Netscapes Protokoll unverändert absegnen
- Am Ende wurden an SSL 3.0 einige Änderungen vorgenommen und auch der Name geändert; TLS 1.0 startete faktisch in einer Form, die eher SSL 3.1 entsprach
SSL und PCT während der Browserkriege
- Der Browserwettbewerb zwischen Netscape und Microsoft Mitte der 1990er-Jahre beeinflusste auch die Standardisierung von Sicherheitsprotokollen
- Netscape entwickelte das SSL-Protokoll
- Die frühen Versionen wurden wegen kryptografischer Schwächen schnell gebrochen und nie veröffentlicht
- Die erste Produktionsversion war SSL 2 und wurde einige Jahre genutzt
- SSL 2 hatte kryptografische und praktische Schwächen, stellte aber keine so dramatische Krise dar, dass es sofort hätte ersetzt werden müssen
- Microsoft modifizierte SSL 2, ergänzte eigene Erweiterungen und definierte damit PCT
- PCT war ein von SSL 2 abgeleitetes Protokoll
- Die Unterstützung war auf IE und IIS beschränkt
- Netscape wollte ebenfalls die Probleme von SSL 2 beheben, wollte aber nicht, dass Microsoft die Führung oder Eigentümerschaft des Standards übernimmt
- Daraus entstand SSL 3.0 mit größeren Änderungen
IETF-Standardisierung und der Name TLS
- Viele Menschen in Branche und Community wollten vermeiden, dass das Protokoll geforkt wird
- Consensus Development organisierte ein Treffen mit Vertretern von Netscape und Microsoft
- Tim Dierks arbeitete damals zusammen mit Christopher Allen bei Consensus Development
- Im Auftrag von Netscape schrieb er die Referenzimplementierung von SSL 3.0
- Bruce Schneier nahm an dem Treffen teil; vermutlich war auch Paul Kocher, der das SSL-3-Protokoll entworfen hatte, dabei, und Microsoft wurde durch Barbara Fox vertreten
- Als Ergebnis der Verhandlungen einigten sich Microsoft und Netscape darauf, dass die IETF das Protokoll übernimmt und in einem offenen Verfahren standardisiert
- Dieser Prozess führte dazu, dass Tim Dierks den RFC redigierte
- Im Zuge der Standardisierung wurden an SSL 3.0 einige Änderungen vorgenommen
- Ziel war es, den Eindruck zu vermeiden, die IETF würde Netscapes Protokoll einfach nur absegnen
- Aus demselben Grund wurde auch der Name des Protokolls geändert
- Das so entstandene TLS 1.0 war tatsächlich eher eine Version, die SSL 3.1 nahekam
1 Kommentare
Meinungen auf Hacker News
Die Versionsnummern machen die Protokollunterschiede nicht besonders deutlich und sorgen daher eher für Verwirrung.
SSLv2 war die erste breit ausgerollte SSL-Version, hatte aber viele Probleme, und SSLv3 war praktisch ein fast neues Protokoll.
TLS 1.0 ähnelt SSLv3, wurde im Zuge der IETF-Standardisierung aber leicht angepasst; TLS 1.1 ist eine sehr kleine Revision, die ein Problem bei der Verwendung von Blockchiffren behob.
TLS 1.2 ist eine mittelgroße Überarbeitung, die als Reaktion auf die Schwächen von MD5 und SHA-1 neue Hashes und AEAD-Cipher-Suites wie AES-GCM hinzufügte, während TLS 1.3 zwar einige Elemente aus der Zeit vor TLS 1.2 wiederverwendet, aber größtenteils eher einem neuen Protokoll entspricht.
All diese Protokolle wurden so entworfen, dass sie die Version automatisch aushandeln können, sodass Clients und Server unabhängig voneinander upgraden konnten, ohne die Konnektivität zu verlieren.
Eine davon waren Session Tickets, die serverseitige Session-Wiederaufnahme ohne synchronisierten Zustand zwischen Servern ermöglichten; eine andere war Server Name Indication, womit ein Server mehr als ein Zertifikat verwenden konnte.
Dass spätere Versionen dann v1.1, v1.2 und v1.3 hießen, wirkt auch wie Sturheit, um nicht eingestehen zu müssen, dass das Zurücksetzen der Versionsnummer objektiv falsch war.
Microsoft war damals ein völlig anderes Biest, deshalb wirkt die Verwirrung um die Bezeichnungen SSL/TLS nicht allzu seltsam.
Das M$ jener Zeit wollte alles kontrollieren, und ich glaube, es hat bis in die frühen 2010er hinein nicht aufgehört, Open-Source-Internettechnologien ausbremsen zu wollen.
Es war erfolgreich darin, Java Applets zu töten, und meiner Meinung nach hat es auch JavaScript und CSS insgesamt um Jahre zurückgeworfen.
Anfang der 2000er wurde ich in der Firma gedrängt, die neuesten „Technologien“ des IE zu unterstützen, aber sobald ein zentraler JS-Bug behoben war, begannen wir sofort, Mozilla 3.0 zu unterstützen; später erwies sich das als gute Entscheidung, als ein Fortune-500-Unternehmen Mozilla/Firefox für interne Apps einsetzte, lange bevor das allgemein üblich wurde.
Im IE funktionierten sie immer, und das war fast der einzige Weg, auf den Microsoft Einfluss nehmen konnte.
Applets scheiterten, weil sie zum Paradebeispiel für „Java ist langsam“ wurden; auch wenn das allgemein nicht unbedingt stimmte, traf es auf Applets wegen der Wartezeit beim Download und beim Start der JVM zu.
Am Ende konnte HTML/JS die dynamischen Funktionen, für die früher Applets nötig waren, besser erledigen, und die übrigen Bereiche, in denen HTML nicht reichte, übernahm Flash — damit verschwanden sie.
Selbst für eine kleine Animation war die Startzeit der JRE absurd lang, die Speicheranforderungen und Abstürze waren für damalige Verhältnisse gravierend, und die Kompatibilitätsprobleme der frühen Releases der Java-Plattform waren ebenfalls seltsam.
Auch das Sicherheitsmodell, das auf der Annahme beruhte, wer ein CA-Zertifikat bekommen könne, werde schon gutartig sein, war lächerlich, und die Sandbox-Technik war nicht nur im IE, sondern browserübergreifend unausgereift.
In s2n wurden große Hoffnungen gesetzt, aber außerhalb von AWS scheint es sich nicht wirklich breit durchgesetzt zu haben.
Wer TLS und SSL strikt unterscheidet, weiß um den Unterschied und erwartet, dass das Gegenüber ihn ebenfalls kennt; praktisch ist es aber ähnlich wie der Unterschied zwischen .doc und .docx.
Grundsätzlich sind sie verschieden, aber für normale Nutzer wirken sie austauschbar, und in der Praxis interessiert man sich meist nur dafür, ob HTTPS funktioniert, nicht besonders für die internen Abläufe.
Ich erinnere mich an ziemlich viele Diskussionen mit Leuten, die dachten, eine größere Zahl bedeute automatisch besser.
Es wäre viel einfacher, modernen verschlüsselten Netzwerkverkehr durchgehend TLS zu nennen und nur dann SSL zu sagen, wenn wegen wirklich alter Legacy-Systeme tatsächlich SSL verwendet wird.
Ich habe gerade gemerkt, dass mein Kopf unbewusst Schwierigkeiten hatte, SSL und TLS auseinanderzuhalten.
Erst nach 20 Jahren verstehe ich, warum.
Erst nach 15 Jahren in dieser Branche ist mir richtig klar geworden, dass ssl und tls im Grunde dasselbe sind, und ich komme mir wie ein Idiot vor.
Der Auslöser war, dass man in Java zum Starten einer verschlüsselten Verbindung selbst dann noch SSLSocket verwendet, wenn heute TLSv1.3 genutzt wird.
„Transport Layer Security“ ist als Name tatsächlich besser.
Auch „TLS“ zu sagen ist angenehm, während SSL mit den zwei aufeinanderfolgenden S-Lauten wie eine Schlange klingt.
Transport Layer Security ist weithin als ab 1999 entstanden dokumentiert, während es zu „Thread Local Storage“ Quellen gibt, die mindestens bis 1996 zurückreichen.
Damals war der Begriff eher im Microsoft-Umfeld, vielleicht auch bei IBM/OS/2, verbreitet; bei Pthreads und im Unix-Umfeld insgesamt sagte man eher „thread-specific data“.
Die Itanium-ABI-Dokumentation von 2001 könnte den Begriff in der weiteren Unix-Welt verbreitet haben, aber offenbar nutzte auch Sun ihn in Solaris und Java schon vorher.
Theoretisch könnte TLS ein Sicherheitsmechanismus auf der Transportschicht sein, auf den man wie bei IPSec beliebige Protokolle aufsetzt; in der Praxis ist es aber fast immer an TCP-Sockets gebunden.
Die UDP-Variante DTLS und auch QUIC sind nicht Teil der TLS-Spezifikation, und es gibt zwar Kernel TLS unter Linux sowie ähnliche Infrastruktur unter Windows, aber es ist nicht so einfach, TLS mit einem einzigen Socket-Flag einzuschalten.
Mich würde interessieren, was ihr normalerweise sagt, wenn ihr jemandem sagen wollt, dass er sicher auf eine Website zugreifen soll, oder in Situationen, in denen man den Begriff TLS/SSL verwenden würde:
Lange Zeit wusste ich nicht einmal, dass TLS „dasselbe“ ist, und selbst jetzt, wo ich es weiß, sage ich in 9 von 10 Fällen immer noch SSL.
Ich bin 38 und habe 2011 angefangen zu arbeiten, aber Netzwerkprogrammierung habe ich zum ersten Mal etwa 2004–2005 gemacht.
Ich habe gerade auf einen anderen Bildschirm geschaut: Eine Funktion, der ich vor ein paar Minuten ein if-Statement hinzugefügt habe, heißt ebenfalls
sslCertNotBefore.Ein Teil des Problems scheint auch zu sein, dass Programmierer TLS normalerweise nicht direkt anfassen.
Ich habe ein System gebaut, das detaillierte Zertifikatsinformationen aus HTTPS-Verbindungen extrahiert, und es war ziemlich mühsam, die nötigen Informationen aus der Java-Standardbibliothek herauszubekommen.
Wenn alles automatisch unsichtbar erledigt wird, macht man zwar schwerer Fehler, aber diese Black-Boxisierung hilft wenig dabei, ein tieferes Verständnis dafür zu verbreiten, wie TLS tatsächlich funktioniert.
Dazu gehören das dominierende OpenSSL sowie BoringSSL, LibreSSL, wolfSSL usw.
Bibliotheken mit TLS im Namen sind GnuTLS, mbedTLS, s2n-tls und RustTLS, werden aber relativ weniger genutzt.
Es wird eher verstanden als das genauere TLS, und echtes SSL 3.0 verwendet heute ohnehin niemand mehr.
Auch klassische Bibliotheksnamen wie OpenSSL enthalten SSL.
Allerdings könnte das auch eine Gewohnheit aus der Zeit der Crypto Wars in den 1990ern sein, als ich SSL gelernt habe und man sich die „US only“-Version von Netscape besorgen musste, wenn man richtige SSL-Verschlüsselung wollte.
Weil auch normale Nutzer manchmal wissen, was das bedeutet.
Trotzdem rutscht mir gelegentlich noch SSL heraus.
Ich bin 51 und habe Mitte der 90er in der IT angefangen.
Ich meine, TLS 1.0 enthielt doch eine ziemlich große Verbesserung gegenüber SSL 3.0.
Wenn man den Artikel liest, wirkt es so, als hätten sie nur ein paar Dinge geändert, um anders auszusehen.
Als vorab bekannt wurde, dass der POODLE-Angriff nur SSL3 betrifft und nicht TLS1.0, konnte man allein daraus vorhersagen, dass es ein Padding-Oracle sein würde.
Die beiden sind recht ähnlich, und es ist fair zu sagen, dass ein paar „Bugfixes“ eingeflossen sind.
Es ist lange her, daher habe ich vielleicht ein paar Dinge vergessen; außerdem habe ich SSL3 und TLS1.0 immer zusammen implementiert, weshalb mir Details entgangen sein könnten.
Im Großen und Ganzen war es eher so, dass die IETF das SSL-3.0-Protokoll nicht einfach unverändert absegnen wollte und ihr Revier markiert hat.
Ein verwandter Artikel ist „Randomness and the Netscape Browser“ aus dem Dr. Dobb's Journal vom Januar 1996.
https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
Der Artikel stammt aus dem Jahr 1996, und die verwendete Sprache fühlt sich schon ziemlich anders an als in heutigen Publikationen; das lässt einen alt fühlen.
Wie schon 1996 lesen sich etwa heutige LWN-Artikel [1] stilistisch ziemlich ähnlich.
Sie sind vielleicht etwas stärker auf ein allgemeineres Publikum ausgerichtet und daher ein bisschen weniger steif.
[1] https://lwn.net/
Ich erinnere mich, dass Eric Rescorlas „SSL and TLS: Designing and Building Secure Systems“ wirklich nützlich war, um die Geschichte von TLS und den Weg bis heute zu verstehen.
Das Buch erschien 2001, warnte bereits vor einigen Problemen, die später zu CVEs wurden, und ist gebraucht für ein paar Dollar zu bekommen.
Um 2014 herum war der Konsens meiner Meinung nach sehr gefestigt, dass SSL 2.0 gravierende Mängel hatte.
Nicht einmal der Handshake wurde richtig authentifiziert.