Live data from Hacker News

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

tim.dierks.org

151–160 of 237 posts

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

#151

People who make a strong distinction between TLS and SSL are indicating that they know the difference and think you should too, but at a practical level it's the difference between .doc and .docx (fundamentally different but interchangeable to the layman). The boots on the ground mostly care about getting https to work and have minimal consideration for it's inner workings.

It is like ages since SSL was obsoleted but people still refer to the name meaning encrypted network traffic.

Would be much easier if everyone just talks about TLS to mean modern encrypted network traffic. Mention SSL if you really use it because you have legacy system running.

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

#152

Earlier quoted context omitted.

No no, they're not. They're names of specific protocols with specific capabilities and versions. "SSL 1.0" and "TLS 1.0" are very different. (see https://aws.amazon.com/compare/the-difference-between-ssl-an... ) The important bits: - "SSL" is a set of protocols so ridiculously old, busted and insecure that nobody should ever use them. It's like talking about Sanskrit; ancient and dead. - "TLS" is way better than "SSL…

Right, but they accomplish the same thing and people move monotonically from SSL to TLS. It’s not like choosing between React and Angular, but like choosing between React version 5 and React version 10 for a new project. SSL and TLS are the same in all meaningful respects from this perspective.

Well nope SSL and TLS is more like Angular and AngularJS.

No one should use SSL or AngularJS in 2025 unless they have to maintain some legacy stuff for important reasons.

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

#153
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.

TLS (outside dealing with PG options named like sslmode)

No

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

#154
post #151

People who make a strong distinction between TLS and SSL are indicating that they know the difference and think you should too, but at a practical level it's the difference between .doc and .docx (fundamentally different but interchangeable to the layman). The boots on the ground mostly care about getting https to work and have minimal consideration for it's inner workings.

It is like ages since SSL was obsoleted but people still refer to the name meaning encrypted network traffic. Would be much easier if everyone just talks about TLS to mean modern encrypted network traffic. Mention SSL if you really use it because you have legacy system running.

I've taken to saying HTTPS, which is far more widely understood and usually accurate enough.

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

#156
post #135

Earlier quoted context omitted.

Regarding your last paragraph: Isn’t that pretty much solved thanks to HSTS preload? A non-technical author of a small recipe blog might not know how to set it up, but a bank ought to have staff (and auditors) who takes care of stuff like that.

It doesn't solve the problem of a client having to treat https:// and http:// URLs with the same string after the :// as distinct resources.

Are there any real world online resources where, modulo redirect, a different resource is presented on the HTTP and the HTTPS protocols? Or alternatively, on ports 80 and 443?

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

#157
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.

You could encrypt the handshake that you recieved with the server's certificate and send it back. Then if it doesn't match what the server thought it sent it aborts the handshake. As long as the server's cert isn't broken this would detect a munged handshake, and if the server's cert is broken you have no root of trust to start the connection in the first place.

The fine man in the middle could still intercept that.

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

#158

Earlier quoted context omitted.

I think most people call it SSL because they use OpenSSL library to deal with secure communication have SSL in their names. Openssl being the most dominant one). Other libraries are BoringSSL, LibreSSL, wolfSSL etc. Libraries with TLS in their names are less frequently used GnuTLS, mbedTLS, s2n-tls and RustTLS.

The Rust library is possibly funnily, possibly confusingly called RusTLS (1). It makes pronunciation a tad harder. (1) https://crates.io/crates/rustls

My apologies.

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

#159
post #99

Earlier quoted context omitted.

The downgrade attacks on TLS are only really present in the case of client behaviour where, on failing to achieve one version, they retry a new connection without it. This was necessary to bypass various broken server side implementations, and broken middleboxes, but wasn’t necessarily a flaw in TLS itself. But from the learnings of this issue preventing 1.2 deployment, TLS 1.3 goes out of its way to look very simila…

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.

Well you can, but that would require a higher level of political skill than normally exists for such things. What would have to happen is that almost everyone would have to agree on the new version and then implement it. Once implementation was sufficiently high enough then you have a switchover day.

The big risk with such an approach is that you could implement something, then the politics could fail and you would end up with nothing.

The big downside of negotiation is that no one ever has to commit to anything so everything is possible. In the case of TLS, that seems to have led to endless bikeshedding which has created a standard which has so many options is is hardly a standard anymore. The only part that has to be truly standard is the negotiation scheme.

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

#160
post #123
post #51

Earlier quoted context omitted.

I usually say SSL, because it has a greater chance of being understood than the more correct TLS (nobody uses SSL 3.0 anymore). It's also in the name of many SSL (I mean, TLS) libraries, like the classic OpenSSL. But yeah, I learned about SSL back in the crypto wars days of the 1990s, back when you had to pirate the so-called "US only" version of Netscape if you wanted decent SSL encryption, so I might be just using…

That's wild, where would you get that "US" netscape version from?

You click the other button on the download page.

https://web.archive.org/web/19990911233949/http://www73.nets...

The US had some strange ideas about cryptography:

https://en.wikipedia.org/wiki/Crypto_Wars#PC_era

https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_i...

Post reply on HN