Comment by pcthrowaway a day 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")
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?
> 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
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.
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.
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).
> 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.