Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tim.dierks.org

Post reply on HN
Print view View original

171–180 of 237 posts

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

#171

Post by meepmorp »

frollogaston wrote: post #103
mcpherrinm wrote: post #92

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…

If a protocol is widely used wrongly, I consider it a flaw in the protocol. But overall, SSL standardization has gone decently well. I always bring it up as a good example to contrast with XMPP as a bad example.

> I always bring it up as a good example to contrast with XMPP as a bad example.

Could you expand a bit here? Do you just mean how extensions to the protocol are handled, etc., or the overall process and involved parties?

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

#172

Post by nkapias »

JdeBP wrote: post #33
oc1 wrote: post #17

Earlier quoted context omitted.

Same. I feel so dumb now. After 15 years in this industry i finally figured out that ssl and tls are the same.

Back closer to the time, there were some people around who insisted that SSL specifically meant the old versions and it was all TLS now. I recall a couple of occasions where people were talking about UCSPI-SSL and someone stepped in to explain that We Don't Do SSL Now. As the headlined article says, that contrived distinction seems silly with the hindsight of decades. The nomenclature was complicated in people's mind…

'It didn't help that RFC 2487 explained that STARTTLS negotiated "TLS more commonly known as SSL"'

> Good catch, it misled me for years !

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

#173

Post by -t0mm »

jedberg wrote: 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.

1. TLS 2. 22. Started in 2024, but the SSL terminology is still widely used in the systems that I currently work with :p

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

#175

Post by ekr____ »

sjducb wrote: post #126
mcpherrinm wrote: post #92

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…

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.

Yes, this is a seriously difficult problem with only partial solutions.

The basic math of any kind of negotiation is that you need the minimum set of cryptographic parameters supported by both sides to be secure enough to resist downgrade. This is too small a space to support a complete accounting of the situation, but roughly:

- In pre-TLS 1.3 versions of TLS, the Finished message was intended to provide secure negotiation as long as the weakest joint key exchange was secure, even if the weakest joint record protection algorithm was insecure, because the Finished provides integrity for the handshake outside of the record layer.

- In TLS 1.3, the negotiation messages are also signed by the server, which is intended to protect negotiation as long as the weakest joint signature algorithm is secure. This is (I believe) the best you can do with a client and server which have never talked to each other, because if the signature algorithm is insecure, the attacker can just impersonate the server directly.

- TLS 1.3 also includes a mechanism intended to prevent against TLS 1.3 -> TLS 1.2 downgrade as long as the TLS 1.2 cipher suite involves server signing (as a practical matter, this means ECDHE). Briefly, the idea is to use a sentinel value in the random nonces, which are signed even in TLS 1.2 (https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3).

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

#176

Post by icedchai »

jedberg wrote: 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.

SSL. Started working in the mid 90's.

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

#177

Post by dylan604 »

ozim wrote: post #151
webprofusion wrote: post #70

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.

People still say Twitter instead of X. Of course people are going to continue using the name used when something was first introduced and engrained into their day to day vs the rebrand. It would be funny if ssl.com just redirects to tls.com and get upset when people still refer to it as ssl. The only successful rebrand attempts have been company names like when Comcast became Xfinity or MCI becoming Worldcom type situations

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

#178

Post by commandlinefan »

ozim wrote: post #151
webprofusion wrote: post #70

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.

TLS is also awkward to _say_, whereas SSL just sounds right.

Plus the most popular implementation of TLS remains the OpenSSL implementation.

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

#179

Post by commandlinefan »

oc1 wrote: post #17
ahofmann wrote: post #11

Oh wow, I just discovered that my brain unconsciously had a hard time to differentiate between SSL and TLS. And now, after two friggin decades I find out, why!

Same. I feel so dumb now. After 15 years in this industry i finally figured out that ssl and tls are the same.

In reality, you may never have actually used SSL, and if you're old enough to have, you haven't used it in decades (I hope).

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

#180

Post by drob518 »

upofadown wrote: post #159
ekr____ wrote: 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.

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…

That’s a great theory but in practice such a “flag day” almost never happens. The last time the internet went through such a change was January 1, 1983, when the ARPANET switched from NCP to the newly designed TCP/IP. People want to do something similar on February 1, 2030, to remove IPv4 and switch totally to IPv6, but I give it a 50/50 chance of success, and IPv6 is already about 30 years old. See https://ipv4flagday.net/
Post reply on HN