Comment by josephg

Comment by josephg 6 months 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:// implicitly use TLS when TLS is available. Having http://.../x and https://.../x be able to resolve to different resources was a huge mistake.

cpach 6 months 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.

Reply View 4 replies

account42 6 months ago

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.

Reply View | 3 replies
- dotancohen 6 months 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?
  
  Reply View | 2 replies
  
  ekr____ 6 months 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.
  
  Reply View | 1 reply
  
  dotancohen 6 months ago
  
  Thank you. That really is a novel attack that I didn't think of.
  
  Reply View | 0 replies

pcthrowaway 6 months 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

Reply View 2 replies

josephg 6 months 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.

Reply View | 1 reply
- pcthrowaway 6 months 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://), 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.
  
  Reply View | 0 replies