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

161–170 of 237 posts

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

#161

Post by freeone3000 »

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…

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

They learned the lesson of IPv6 here.

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

#163

Post by casper14 »

bux93 wrote: post #154
ozim wrote: post #151

Earlier quoted context omitted.

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.

Until you TLS a tcp connection of course

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

#164

Post by sjducb »

kevincox wrote: post #140
sjducb wrote: 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.

How do you agree a protocol to encrypt the message to agree the protocol?

This is the message that returns a list of supported ciphers and key exchange protocols. There’s no data in this first packet.

Alice: I’d like to connect Bob: Sure here is a list of protocols we could use:

You modify bob’s message so that bob only suggests insecure protocols.

You might be proposing that Alice asks Trent for Bob’s public key … But that’s not how TLS works.

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

#165

Post by ekr____ »

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…

This seems like a truly unreasonable level of political skill for nearly any setting. We're talking about changing every endpoint in the Internet, including those which can no longer be upgraded. I struggle to think of any entity or set of entities which could plausibly do that.

Moreover, even in the best case scenario this means that you don't get the benefits of deployment for years if not decades. Even 7 years out, TLS 1.3 is well below 100% deployment. To take a specific example here: we want to deploy PQ ciphers ASAP to prevent harvest-and-decrypt attacks. Why should this wait for 100% deployment?

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

I don't think this is really that accurate, especially on the Web. The actual widely in use options are fairly narrow.

TLS is used in a lot of different settings, so it's unsurprising that there are a lot of options to cover those settings. TLS 1.3 did manage to reduce those quite a bit, however.

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

#166

Post by ekr____ »

pcthrowaway wrote: post #114
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.

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")

This has a number of negative downstream effects.

First, recall that links are very often inter-site, so the consequence would be that even when a server upgraded to TLS 1.2, clients would still try to connect with TLS 1.1 because they were using the wrong kind of link. This would relay delay deployment. By contrast, today when the server upgrades then new clients upgrade as well.

Second, in the Web security model, the Origin of a resource (e.g., the context in which the JS runs) is based on scheme/host/port. So httpt would be a different origin from HTTPS. Consider what happens if the incoming link is https and internal links are httpt now different pages are different origins for the same site.

These considerations are so important that when QUIC was developed, the IETF decided that QUIC would also be an https URL (it helps that IETF QUIC's cryptographic handshake is TLS 1.3).

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

#167

Post by ekr____ »

dotancohen wrote: post #156
account42 wrote: post #144

Earlier quoted context omitted.

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?

There used to be, though it's less true now. However, the reason to treat them distinctly (as different origins, technically) is that HTTPS provides integrity whereas HTTP does not. So, consider the case where the client enters an HTTP URL and is redirected, just as you say above. If the attacker injects their own JS and it is cached in an origin that is just `example.com`, then they control the user's experience of the site, even if later the user securely goes to the site with HTTPS.

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

#168

Post by Sophira »

ekr____ wrote: post #165
upofadown wrote: post #159

Earlier quoted context omitted.

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…

This seems like a truly unreasonable level of political skill for nearly any setting. We're talking about changing every endpoint in the Internet, including those which can no longer be upgraded. I struggle to think of any entity or set of entities which could plausibly do that. Moreover, even in the best case scenario this means that you don't get the benefits of deployment for years if not decades. Even 7 years out…

> This seems like a truly unreasonable level of political skill for nearly any setting. We're talking about changing every endpoint in the Internet, including those which can no longer be upgraded. I struggle to think of any entity or set of entities which could plausibly do that.

Case in point: IPv6 adoption. There's no interoperability or negotiation between it and IPv4 (at least, not in any way that matters), which has led to the mess we're in today.

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

#169

Post by ekr____ »

aoetalks wrote: post #150
LukeShu wrote: post #41

Earlier quoted context omitted.

No? The "transport" layer is layer 4 in the 7-layer OSI model (physical/datalink/network/transport/session/presentation/application) and 5-layer IP model (physical/network/internetwork/transport/application). That is: the "transport" provides reliable continuous data-stream abstraction over the lower-layers' discreet and unreliable packets; e.g. TCP. And that data-stream the interface that TLS provides; to the higher…

I was about to agree with you, and then I read the article on DTLS. > And that data-stream the interface that TLS provides That’s exactly the problem. You might lose a UDP packet. That would corrupt data encrypted with stream cipher. With DTLS, each packet is encrypted individually. https://en.m.wikipedia.org/wiki/Datagram_Transport_Layer_Sec...

Just on a technical note, TLS 1.3 only uses AEAD ciphers where the nonce is determined by the record numbers, so it actually is in principle possible to decrypt the packets even if they are received out of order by trial decrypting with different record numbers. You don't do this in TLS (as opposed to DTLS) because it runs over TCP and therefore you are guaranteed in-order delivery.

DTLS, by contrast, provides a record number hint (the low order bits of the record number and epoch) to assist in record number reconstruction: https://www.rfc-editor.org/rfc/rfc9147.html#name-reconstruct....

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

#170

Post by mcpherrinm »

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.

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.

Post reply on HN