Live data from Hacker News

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

tim.dierks.org

221–230 of 237 posts

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

#221
post #126

Earlier quoted context omitted.

Man in the middle interfering with TLS handshakes? The handshake is unencrypted so you can modify the messages to make it look like the server only supports broken ciphers. Then the man in the middle can read all of the encrypted data because it was badly encrypted. A surprising number of servers still support broken ciphers due to legacy uses or incompetence.

No: while the handshake is unencrypted, it is authenticated. An attacker can’t modify it. What an attacker can do is block handshakes with parameters they don’t like. Some clients would retry a new handshake with an older TLS version, because they’d take the silence to mean that the server has broken negotiation.

well, unless both client and server have sufficiently weak crypto enabled that an attacker can break it during the handshake.

Then you can MITM, force both sides to use the weak crypto, which can be broken, and you're in the middle. Also not really so relevant today.

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

#222

Earlier quoted context omitted.

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…

Any chance that can be used to undo lots of the ossification that made QUIC a UDP based hack rather than it's own level 4 protocol?

It's probably too hard to get NATs to agree on a new L4 protocol.

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

#223

Earlier quoted context omitted.

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.

Similar thing has been happening with email sender auth, with Gmail and other big providers enforcing things

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

#224

Earlier quoted context omitted.

> It wouldn't have been insane to rename https to httpt or something after TLS 1.2 and screw backwards compatibility That would have been at least little bit insane, since then web links would be embedding the protocol version number. As a result, we'd need to keep old versions of TLS around indefinitely to make sure old URLs still work. I wish we could go the other way - and make http:// implicitly use TLS when TLS…

> As a result, we'd need to keep old versions of TLS around indefinitely to make sure old URLs still work Wouldn't we be able to just redirect https->httpt like http requests do right now? Sure it'd be a tiny bit more overhead for servers, but no different than what we already experienced moving away from unencrypted http

You’re thinking about it from the perspective of a site operator. Yes, individual websites could do that. But not all websites would use such a redirect.

But think about it from the perspective of a web browser or curl. You can’t rely on all web servers having such a redirect for their URLs. Web browsers would need to support old versions of TLS to make old URLs work. They’d need to support old versions of tls indefinitely so as to not break old URLs.

Using an old version of tls isn’t like using an old version of the C compiler. Old versions of tls have well documented problems with security implications. That’s why we made new versions. Maintaining lots of versions of TLS multiplies the security surface area for bugs, and makes you vulnerable to downgrade attacks.

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

#225
post #8

> As a part of the cutthroat competition, Microsoft decided to revise the SSL 2 protocol with some additions of their own, and specified a protocol called "PCT" that was derived from SSL 2. It was only supported in IE and IIS. > Netscape also wanted to address SSL 2 issues, but wasn't going to let Microsoft take leadership/ownership in the standard, so they developed SSL 3.0, which was a more significant departure. I…

Microsoft was the bad guy in a movie where you have a war right before aliens invade and you figure out that there's bigger enemies. FSF hated Microsoft because they released binaries without source code, they were THE enemy, nowadays, you are lucky if you get a binary to study and modify! The standard from any competitive developer is to hide the binary and source behind a server. Try to study and modify that!

[deleted]

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

#226
post #67
post #63

Earlier quoted context omitted.

For the FSF, Microsoft releasing binaries without source was reason enough to hat them but it was not the only reason why people, including those in the FSF, hated them. Microsoft was very much a company that used their dominant market position to lock customers in and the competition out. (Remember embraced, extend, extinguish?) The Microsoft of today looks like a cuddly teddy bear in comparision.

Microsoft's motto then was "We set the standards".

Worse, it was "we set the standards, and you can't use them".

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

#227

Earlier quoted context omitted.

> As a result, we'd need to keep old versions of TLS around indefinitely to make sure old URLs still work Wouldn't we be able to just redirect https->httpt like http requests do right now? Sure it'd be a tiny bit more overhead for servers, but no different than what we already experienced moving away from unencrypted http

You’re thinking about it from the perspective of a site operator. Yes, individual websites could do that. But not all websites would use such a redirect. But think about it from the perspective of a web browser or curl. You can’t rely on all web servers having such a redirect for their URLs. Web browsers would need to support old versions of TLS to make old URLs work. They’d need to support old versions of tls indefi…

Like, you're right that some, perhaps many, sites would continue using https, just like in the current situation, many sites continue supporting http (instead of just setting up a redirect)

No site needs to do this though, and I can't recall seeing a site with sensitive user info that supports http in recent years. And in the current situation, many sites are still supporting old versions of https (SSL2). A protocol name upgrade would give you more certainty that you're connecting over a secure connection, and perhaps a better indication if you've accidentally used a less-secure connection than intended.

I mean actually your exact argument could be made about http vs https, that http+SSL should have become the default (without changing the protocol name of http://), and by changing the protocol name it made it so that some websites still accept http. I guess in practice there's a slight difference since http->https involved a default port change and ssl2 -> tls did not, so in the former case the name change was important to let clients know to use a different default port; but ignoring that, the same argument could be made, and I would have disagreed with it there too.

Specifying the protocol... in the protocol portion of the URL... can be useful for users.

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

#228

Earlier quoted context omitted.

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…

Any chance that can be used to undo lots of the ossification that made QUIC a UDP based hack rather than it's own level 4 protocol?

Basically none.

First the success rate of any new IP-based protocol through most devices is incredibly low, especially now that NAT is so common.

Second, part of why QUIC runs over UDP is because the operating system generally won't let applications send raw IP datagrams.

Even running over UDP, QUIC has nontrivial failure rates and the browsers have to fall back to TLS over TCP.

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

#229
post #27

Curious, when you tell someone they need to access a website securely (or any other case where you might use the term TLS or SSL), do you: 1. Say SSL or TLS? 2. How old are you (or did you start working before 1999?) I'll reply with my answer too.

I say "https" because sometimes even regular people know what that means.

And it's a bit more precise to say HTTPS if you're talking about HTTPS.

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

#230
post #12

Earlier quoted context omitted.

The problem is that TLS was already in widespread use for "thread local storage". Transport Layer Security is widely documented as beginning in 1999. I can find references to "Thread Local Storage" going back to at least 1996. That particular term seems more common in the Microsoft (and maybe IBM, does anyone have an OS/2 programming manual?) world at the time; Pthreads (1995) and Unix in general tended to call it "t…

I don’t doubt that, but I never heard Thread Local Storage until much later than that. While it might well’ve been common within its ecosystem, I don’t think it was widely known outside it.

SMP took a long time.
Post reply on HN