Live data from Hacker News

Why SSL was renamed to TLS in late 90s (2014)

tim.dierks.org

181–190 of 237 posts

Re: Why SSL was renamed to TLS in late 90s (2014)

#181

Earlier quoted context omitted.

Well, my only real point is that it’s not the version negotiation in TLS that’s broken. It’s the workaround for intolerance of newer versions that had downgrade attacks. Fortunately that’s all behind us now, and transitioning from 1.2 to 1.3 is going much smoother than 1.0 to 1.2 went.

One of the big differences was in attitude. The TLS 1.3 anti-downgrade feature was not compatible with some popular middlebox products. Google told people too bad, either your vendor fixes it (most shipped free bug fixes for this issue, presumably "encouraged" by the resulting customer anger) or you can't run Chrome once this temporary fudge goes away in a year's time. Previously (in earlier protocol versions) nobody…

The service providers were the worst offenders here because they wanted to be the MIM to be able to look at the data and “add value” to their networks some how. Moving to TLS 1.3 took a lot of that away from them and it was only Google’s market power that could break them.

Re: Why SSL was renamed to TLS in late 90s (2014)

#182
post #61

The situation is additionally confused by the fact that the version numbers do not give a good clue to how different the protocols were. Specifically: SSLv2 was the first widely deployed version of SSL, but as this post indicates, had a number of issues. SSLv3 is a more or less completely new protocol TLS 1.0 is much like SSLv3 but with some small revisions made during the IETF standardization process. TLS 1.1 is a r…

They still should have just called it TLS v4.0 instead of v1.0.

I'm halfway convinced that they have made subsequent versions v1.1, v1.2, and v1.3 in an outrageously stubborn refusal to admit that they were objectively incorrect to reset the version number.

Re: Why SSL was renamed to TLS in late 90s (2014)

#183
post #61

The situation is additionally confused by the fact that the version numbers do not give a good clue to how different the protocols were. Specifically: SSLv2 was the first widely deployed version of SSL, but as this post indicates, had a number of issues. SSLv3 is a more or less completely new protocol TLS 1.0 is much like SSLv3 but with some small revisions made during the IETF standardization process. TLS 1.1 is a r…

TLS1.0 introduced modularity via the concept of "extensions". It's everything but a minor evolution of the protocol. One of the many things it brought is session tickets, enabling server-side session resumption without requiring servers to keep synced-up state. Another is Server Name Indication, enabling servers to use more than one certificate.

FWIW, these aren't actually in TLS 1.0.

Extensions (including SNI) are in later spec but introduces in RFC 3546 (https://www.rfc-editor.org/rfc/rfc3546). Session tickets are in RFC 4507.

What TLS 1.0 did was to leave the door open for extensions by allowing the ClientHello to be longer than what was specified. See https://www.rfc-editor.org/rfc/rfc2246.html#section-7.4.1.2 (scroll to "Forward Compatibility Note")

Re: Why SSL was renamed to TLS in late 90s (2014)

#184
post #99

Earlier quoted context omitted.

Moreover, there's not really much in the way of choices here. If you don't have this kind of automatic version negotiation then it's essentially impossible to deploy a new version.

You could deploy a new version, you'd just have older clients unable to connect to servers implementing the newer versions. It wouldn't have been insane to rename https to httpt or something after TLS 1.2 and screw backwards compatibility (yes I realize the 's' stands for secure, not 'ssl', but httpt would have still worked as "HTTP with TLS")

You mean like the way we use h2:// everywhere now? Oh wait, we don't.

Re: Why SSL was renamed to TLS in late 90s (2014)

#185
post #61

The situation is additionally confused by the fact that the version numbers do not give a good clue to how different the protocols were. Specifically: SSLv2 was the first widely deployed version of SSL, but as this post indicates, had a number of issues. SSLv3 is a more or less completely new protocol TLS 1.0 is much like SSLv3 but with some small revisions made during the IETF standardization process. TLS 1.1 is a r…

They still should have just called it TLS v4.0 instead of v1.0. I'm halfway convinced that they have made subsequent versions v1.1, v1.2, and v1.3 in an outrageously stubborn refusal to admit that they were objectively incorrect to reset the version number.

As I noted below, there was real discussion around the version number for TLS 1.3. I don't recall any such discussion for 1.1 and 1.2.

Re: Why SSL was renamed to TLS in late 90s (2014)

#186

Considering that Microsoft was a completely different beast in that time, I'm not surprised it does not seem that silly. M$ (appropriate name for that time) of the day was doing its best to own everything and the did not let up on trying to hold back the open source internet technologies until the early 2010's I believe. Its my opinion that they were successful in killing Java Applets, which were never able to improv…

I don't think it was Microsoft that killed Java applets. I mean, for one thing, they always worked in IE, which was really the only avenue through which MS could have affected them. No, Java applets failed because they became the poster child for "Java is slow" take. Even though it wasn't exactly true in general, it was certainly true of applets, what with waiting for them to download and then waiting for the JVM to…

Another reason Java applets ultimately failed was the never-ending stream of sandbox escapes, which is inherent to their design of running trusted and untrusted code in the same VM and trying to keep track of which is which. It turns out it's much more straightforward to sandbox the whole VM.

A representative vulnerability is "trusted method chaining". You (the attacker) construct a chain of standard library objects that call each other in unexpected ways. You can make use of the fact that you can subclass a standard library class and implement a standard library interface, in order to implement the interface methods with the base class's implementations, to construct more unusual pathways. Then you get some standard library entry point to call the first method in the chain. Since your code doesn't appear on the call stack at any point (it's just the standard library calling the standard library) whatever is at the bottom of the call stack, at the end of the chain, infers a trusted context and can access files or whatever. Of course, finding a method chain that's possible to construct and does something malicious is non-trivial.

Re: Why SSL was renamed to TLS in late 90s (2014)

#188
post #31
post #4

“Transport Layer Security” really is a better name though. I also like to say “TLS”. Two Ses in a row makes you sound like a snake.

“SSL” is easier to pronounce, because the tongue barely changes position between the three letters, compared to “TLS”.

This is objective, but ai find TLS rolls more easily off the tongue.

Re: Why SSL was renamed to TLS in late 90s (2014)

#189

Considering that Microsoft was a completely different beast in that time, I'm not surprised it does not seem that silly. M$ (appropriate name for that time) of the day was doing its best to own everything and the did not let up on trying to hold back the open source internet technologies until the early 2010's I believe. Its my opinion that they were successful in killing Java Applets, which were never able to improv…

I don't think it was Microsoft that killed Java applets. I mean, for one thing, they always worked in IE, which was really the only avenue through which MS could have affected them. No, Java applets failed because they became the poster child for "Java is slow" take. Even though it wasn't exactly true in general, it was certainly true of applets, what with waiting for them to download and then waiting for the JVM to…

Even prior to HTML5 stuff, Flash was just a better UX than applets, which always felt like your browser was loading an application, vs being an element in a page.

Re: Why SSL was renamed to TLS in late 90s (2014)

#190

Earlier quoted context omitted.

I don't think it was Microsoft that killed Java applets. I mean, for one thing, they always worked in IE, which was really the only avenue through which MS could have affected them. No, Java applets failed because they became the poster child for "Java is slow" take. Even though it wasn't exactly true in general, it was certainly true of applets, what with waiting for them to download and then waiting for the JVM to…

Java Applets also froze the entire browser when loading. Even more so than the Windows Media / QuickTime / Real Player plug-ins. Only the Flash plug-in didn't noticeably freeze the browser. It was heavily CPU optimized and even used AVX for rendering, as far as I remember.

> > No, Java applets failed because they became the poster child for "Java is slow" take.

> Java Applets also froze the entire browser when loading.

More than just "poster child", I believe Java applets are the origin of the "Java is slow" meme. The first time many people heard of Java would be when it locked up their browser for a whole minute while loading an applet, with a status bar message pointing to Java as the culprit.

Post reply on HN