Are you saying self signed certificates and custom certificate authorities are banned in HTTP/3? Because as far as I know, there's absolutely nothing stopping you from setting up your own crypto if you don't like certificate authorities.
I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio.
I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
Really? Are you sure about that? I'd love to believe you as it'd mean there's been progress on this front but the last time I checked it required compile time flags in Chrome and Firefox. The problem is that this is a function of the libraries these browsers use, it's not an option that is within the browser itself.
>removing easy ways for end users to do insecure things.
That's a legit pov as long as you think about browsers as in the for-profit way: as insecure virtual machines for customers to run your untrusted third party code. And that's certainly the zeitgeist. But that's not what the web is to many human people.
The web of documents still exists despite the last decade of the web just being a mechanism to distribute JS applications. I know that the for-profit point of view doesn't care about the web of documents (not profitable) but that doesn't make their use case the only use case. All you have to do to make accepting self-signed certs as secure (or more secure) than the "normal" web is to turn off automatic execution of untrusted code sent to you. I'd wager that a good fraction of the HN userbase already does this with their NoScript or uBlock or whatever anti-javascript protection extensions.
And in this particular exact scenario, you can use my .onion site for superkuh.com to verify the end-point identity if you're really worried that someone might change the text. A system that works without CAs.
Among other things a MitM can:
- insert ads in your page
- run miners on your user's browser
- change links or redirect the page (likely to an CA-signed malware site)
- insert malware in downloadable scripts on your site (http://superkuh.com/TkTTS.pl)
Software\Policies\Google\Chrome,SSLErrorOverrideAllowed,REG_DWORD,1
The thing I wonder: will this prevent Internet of Sh*t devices to spread or will they become fully reliant on cloud, thus dependent on the vendor (as the customer's browser won't talk to it)
How does requiring HTTPS turn into no more personal websites? Let's Encrypt offers free certificates with automated renewal and minimal hassle, and if you don't like them there are several free alternatives.
The second is more abstract but notice how literally everyone in this thread is recommending LetsEncrypt. That's great, and I love LE and I'm really glad they exist. But this is literally putting all our eggs in one basket. The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. Like, say, a website for an abortion clinic that is now against the law in Texas. Switching to comodo when this happens won't fix it.
Web serving has always had moving parts, and there has always been some maintenance required to keep sites up. I agree that HTTPS increases the burden here, but not from zero.
> at some point that complex stack of software (who's complexity is hidden from the user) will break
Sort of? People definitely screw up their HTTPS configuration from time to time, or run into bugs. But the acme software is very reliable, so this is rare, and if it does happen blowing your existing configuration away and starting fresh will fix it.
> And not only does it make them more fragile but it makes setting up a website for the first time much more complex.
If you want to set up a website with minimal steps you generally get someone else to host, at which point they are dealing with HTTPS. If you want to do it all yourself HTTPS does add a step, but it is small compared to all of the other steps involved in setting up a server.
> The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites.
The US legal system cannot currently compel Let's Encrypt to refuse service to lawbreaking sites, and even if the law changed here you could get a certificate from a CA in another country.
And you do understand the reason why having browsers verify that they're actually talking to who they think they're talking to is important, right?
HTTP/3 would break this.
These are very different. If need to convince your audience to get and install some alternate client with an alternate protocol, now you audience it at best only a few techies who can do that for themselves.
Whereas sending anyone an URL they can click on with any client, even if it identified by an IP address instead of a hostname, is as easy at it gets.
Let's Encrypt is awesome, I use them for all my personal sites (web and non).
Threat modeling covers more than just authenticity and confidentiality. For instance, denial of service is also something to evaluate. So why does this matter?
Today if Let's Encrypt suddenly disappears or goes evil and no longer wants to issue me a certificate, I can simply re-enable plan HTTP on my site and my content remains available. Sure there are drawbacks but there are pros and cons to everything. As a static site I'm comfortable with the cons of hosting it via HTTP if the only alternative is not being able to host at all. Important things is I can make that choice.
In a world where normal people (i.e. non-techies who can't be expected to build their own browsers from source or whatever) can only have access to a client that enforces public CA issued certificates, it becomes easier than ever to drop unwelcome people effectively off the internet.
HTTPS only, CA TLS only, leads to websites with lifetimes that max out around several years. This is fine for corporate/institutions as nothing of theirs lasts this long anyway. But it's a huge problem with personal sites which remain useful and valuable for longer time periods.
I can find some references to Chrome's QUIC not supporting self signed certificates, but I can't find any source that says that WebKit and Firefox made the same decision. Do you happen to know a self signed HTTP/3 URL that I can test this with?
Browsers choosing to break self signed certificates can happen even with HTTP 0.9. All they need to do is require the user to type the bypass phrase ("thisisunsafe" in the Chrome error screen) on any certificate validation error and enable HTTPS only mode. This has nothing to do with spec. Browsers have even removed spec implementations for HTTP/2 spec (HTTP push) after a few years.