The mechanism by which https rendered the old device inoperable does not change the fact that https rendered the old device inoperable.
One may argue that the problem is essentially unavoidable because the alternative is untenable (delivering any sort of communication without both encryption and authentication to ensure the veracity of the data) but that doesn't make the observation any less true. https is in fact a pain in the ass and introduces a lot of overhead and grief and shortened the useful life of countless things, relative to the time before https.
> The mechanism by which https rendered the old device inoperable does not change the fact that https rendered the old device inoperable
This is one of those many cases on the internet where people make an unfounded statement and then just move on as if it's accepted as true. How does the mechanism not change the fact???
The mechanism in this case is outdated software; upgrading or changing the software on the device makes the device operable (you absolutely can install modern TLS on Windows XP, alternatively you could also install a modern OS on most devices that came with Windows XP). That fact seems to make the mechanism extremely relevant in whether the device is operable.
You seem to be redefining the "built to last" to encapsulate backward compat, which is an odd definition, but let's go with it.
The only aspect of HTTPS that isn't backward compatible in the way you're talking about is, effectively, the algorithms keeping up with modern attack vectors. That's not an aspect of HTTPS the spec, it's an aspect of the arms race in network security. So pinning this issue on HTTPS is odd.
The reason you can't use outdated software to connect to modern servers isn't due to protocol design, it's due to threat actors.
> You seem to be redefining the "built to last" to encapsulate backward compat, which is an odd definition, but let's go with it.
What other definition there is? A protocol that has absolutely no backward compatibility, not even with itself, and by design, is "built to last"? Or that a protocol that is frequently rewriting its core algorithms in its base specs is "built to last" ?
> That's not an aspect of HTTPS the spec, it's an aspect of the arms race in network security.
It is an aspect of the spec. There is literally no HTTPS without SSL/TLS. If there was, you could have an argument there, but: the very definition of HTTPS is "HTTP + SSL".
Really, there is no color. Ethernet, IP, HTTP still allow an unmodified client from 25 years ago to work with practically full functionality. HTTPS does not. Whether this is because HTTPS has more ambitious goals (which it obviously has), or whether the designers were smoking something better, or because computer security requires an arms race (that's another debate), the effective result is that HTTPS is not built to last.
Everything you build on top of it will require continuous rearchitecturing every couple of years. And I'm not talking about changing some certificates or the like. I am talking spec changes. I'm talking most of the algorithms having changed significantly.
Or maybe TLS 1.3 will be the good one this time. Who knows.
One may argue that the problem is essentially unavoidable because the alternative is untenable (delivering any sort of communication without both encryption and authentication to ensure the veracity of the data) but that doesn't make the observation any less true. https is in fact a pain in the ass and introduces a lot of overhead and grief and shortened the useful life of countless things, relative to the time before https.