3 ms·

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 i

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.

AshamedCaptain 5y ago
> 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.

AshamedCaptain 5y ago

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