> HTTP+HTTPS is definitely the way to go so that people can chose the HTTPS endpoint if they want,
This opens up the way to downgrade attacks.
Imho there should not be any unencrypted traffic on the net. Not even the technical possibility for that as long as you're using std. software. Call me an old school crypto-nerd but I just don't see any alternative. Everything else is going to get exploited. There is just too much initiative form very powerful fractions. So crypto needs to be enfoced at a very fundamental level. Security by design, privacy by design!
> HTTP/3 on QUIC does make it much, much more of a problem because only 0.000001% of worldwide users are going to be passing `--ignore-certificate-errors-spki-list=${CERT_HASH}` to chrome after their browser first prevents the link from working.
I agree that the requirement for CA signed certs is sub-optimal.
I for my part only care about the (forced) encryption.
And that's actually all QUIC requires. The protocol does not force checking certificate chains. (Otherwise the above mentioned switch wouldn't be possible while having a complaint implementation.)
The check of the cert chain is a implementation detail of the HTTP/3 stack in browsers AFAIK. (I could be wrong here and HTTP/3 may require "WebPKI" trusted certs; I didn't read all of the spec until now.)
I would love it of course if the CA based "WebPKI" would get replaced by something decentral with self service options.
Having CA certs you didn't install yourself in your browser (after sorrow consideration!) is a mayor security risk, imho. Just look at the list… You're "trusting" in the end more of less everybody with money and power on this planet. That's not how it should be. But I don't know how an alternative could look like. (And I guess nobody really knows. Maybe you?)
But something like Let's Encrypt, which only checks the part that actually matters—namely whether you own the domain for which you like a cert, no further questions asked—is imho as close to "decentralized self-service" as it could get at the moment.
> I know too many late 90s/early 2000s websites to count that haven't been touched in the last decade+. And I know they would not exist not if they relied on HTTPS only or HTTP/3.
Why do you think HTTP/3 would have prevented the sites to last as long as they did?
Getting and renewing certs is an one-time setup. I'm pretty sure it will just work for the years to come once up and running.
Yes. A website run by a human person is vulnerable to downgrade attacks in the same way that a human person is vulnerable to rocket artillery. In some contexts, like say, active war zones or hosting a cryptocurrency market, it matters. But in most cases human people don't actually have to worry at all. Especially since the downgrade "attack" is not really an attack at all. And you're only "vulnerable" to it if you execute javascript. Othwerwise there's no intrinsic damage to using HTTP. That only applies to commercial/money exchanging contexts and things like hospitals.
>Why do you think HTTP/3 would have prevented the sites to last as long as they did?
If the site was HTTP/3 only then their cert would have expired or their update system broken and browsers would not be able to access the site.
This opens up the way to downgrade attacks.
Imho there should not be any unencrypted traffic on the net. Not even the technical possibility for that as long as you're using std. software. Call me an old school crypto-nerd but I just don't see any alternative. Everything else is going to get exploited. There is just too much initiative form very powerful fractions. So crypto needs to be enfoced at a very fundamental level. Security by design, privacy by design!
> HTTP/3 on QUIC does make it much, much more of a problem because only 0.000001% of worldwide users are going to be passing `--ignore-certificate-errors-spki-list=${CERT_HASH}` to chrome after their browser first prevents the link from working.
I agree that the requirement for CA signed certs is sub-optimal.
I for my part only care about the (forced) encryption.
And that's actually all QUIC requires. The protocol does not force checking certificate chains. (Otherwise the above mentioned switch wouldn't be possible while having a complaint implementation.)
The check of the cert chain is a implementation detail of the HTTP/3 stack in browsers AFAIK. (I could be wrong here and HTTP/3 may require "WebPKI" trusted certs; I didn't read all of the spec until now.)
I would love it of course if the CA based "WebPKI" would get replaced by something decentral with self service options.
Having CA certs you didn't install yourself in your browser (after sorrow consideration!) is a mayor security risk, imho. Just look at the list… You're "trusting" in the end more of less everybody with money and power on this planet. That's not how it should be. But I don't know how an alternative could look like. (And I guess nobody really knows. Maybe you?)
But something like Let's Encrypt, which only checks the part that actually matters—namely whether you own the domain for which you like a cert, no further questions asked—is imho as close to "decentralized self-service" as it could get at the moment.
> I know too many late 90s/early 2000s websites to count that haven't been touched in the last decade+. And I know they would not exist not if they relied on HTTPS only or HTTP/3.
Why do you think HTTP/3 would have prevented the sites to last as long as they did?
Getting and renewing certs is an one-time setup. I'm pretty sure it will just work for the years to come once up and running.