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…
Why SSL was renamed to TLS in late 90s (2014)
181–190 of 237 posts
Re: Why SSL was renamed to TLS in late 90s (2014)
#182The 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…
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)
#183The 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.
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)
#184Earlier 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")
Re: Why SSL was renamed to TLS in late 90s (2014)
#185The 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)
#186Considering 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…
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)
#187Re: Why SSL was renamed to TLS in late 90s (2014)
#188“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”.
Re: Why SSL was renamed to TLS in late 90s (2014)
#189Considering 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…
Re: Why SSL was renamed to TLS in late 90s (2014)
#190Earlier 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.
> 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.