7 ms·

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 d

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.

Dylan16807 1y ago
Depends on what you mean by "this kind" because you want a way to detect attacker-forced downgrades and that used to be missing.
pcthrowaway 1y ago
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")
- josephg 1y ago
  > 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:// http:// implicitly use TLS when TLS is available. Having http://.../x http://.../x and https://.../x https://.../x be able to resolve to different resources was a huge mistake.
  - cpach 1y ago
    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.
    - account42 1y ago
      It doesn't solve the problem of a client having to treat https:// https:// and http:// http:// URLs with the same string after the :// as distinct resources.
      - dotancohen 1y ago
        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?
        ekr____ 1y ago
        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.
        dotancohen 1y ago
        Thank you. That really is a novel attack that I didn't think of.
  - pcthrowaway 1y ago
    > 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
    - josephg 1y ago
      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.
      - pcthrowaway 1y ago
        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:// 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.
- tgma 1y ago
  TLS is one of the best success stories of widely applied security with great UX. It would be nowhere as successful with that attitude.
- account42 1y ago
  Yes it would absolutely have been insane.
- ekr____ 1y ago
  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).
- immibis 1y ago
  You mean like the way we use h2:// everywhere now? Oh wait, we don't.
upofadown 1y ago
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.
- freeone3000 1y ago
  > 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.
- ekr____ 1y ago
  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.
  - 1y ago

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.

Dylan16807 1y ago

Depends on what you mean by "this kind" because you want a way to detect attacker-forced downgrades and that used to be missing.

pcthrowaway 1y ago

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

josephg 1y ago
> 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:// http:// implicitly use TLS when TLS is available. Having http://.../x http://.../x and https://.../x https://.../x be able to resolve to different resources was a huge mistake.
- cpach 1y ago
  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.
  - account42 1y ago
    It doesn't solve the problem of a client having to treat https:// https:// and http:// http:// URLs with the same string after the :// as distinct resources.
    - dotancohen 1y ago
      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?
      - ekr____ 1y ago
        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.
        dotancohen 1y ago
        Thank you. That really is a novel attack that I didn't think of.
- pcthrowaway 1y ago
  > 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
  - josephg 1y ago
    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.
    - pcthrowaway 1y ago
      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:// 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.
tgma 1y ago
TLS is one of the best success stories of widely applied security with great UX. It would be nowhere as successful with that attitude.
account42 1y ago
Yes it would absolutely have been insane.
ekr____ 1y ago
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).
immibis 1y ago
You mean like the way we use h2:// everywhere now? Oh wait, we don't.

upofadown 1y ago

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.

freeone3000 1y ago
> 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.
ekr____ 1y ago
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.
- 1y ago