Yes, because it's mandatory. If the HTTP/3 implementations allowed self-signed certs it'd be okay. But they don't. Or if HTTP/3 allowed the option of connections without TLS but defaulted to TLS, that'd be okay. But it doesn't.

> If the HTTP/3 implementations allowed self-signed certs

Is it forbidden at the protocol level or by the implementations?

It's an implementation limit that at least Chrome (and possibly other browsers) are enforcing for QUIC connections. The TLS certificate must be signed by a trusted CA. [1]

There does appear to be cli flags to change the behavior, but I don't see how you'd do that on mobile or embedded browsers.

[1]https://www.smashingmagazine.com/2021/09/http3-practical-dep...

You can add trusted CAs to your system though...

That is true. But an actual self-signed certificate is not signed by any CA, so it still can't be used with QUIC connections (with specific clients such as Chrome, anyway.)

RFC 9114 §3.1 ¶2 [0] requires TLS certificates, but I imagine you can easily modify existing implementations to remove this restriction. And even if the spec didn't require it I'd expect all major implementors (web browsers) to still impose this. I imagine something like curl has an opt-out for this (-k?).

Note that the spec essentially says "if verification fails don't trust this connection". What not trusting means is up to the application. For browsers that's probably equivalent to not allowing the connection at all.

[0] https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2

HTTP/3 allows self-signed certs.

Chrome does not. But that choice is orthogonal to protocol.

I didn't know chrome didn't allow self-signed certificates. Since when?

The user can add self-signed certificates. Random websites using self-signed certificates won't work without that extra configuration from the user.

I'm pretty sure the old "thisisunsafe" trick will still work ...

> Chrome does not. But that choice is orthogonal to protocol.

Which means HTTP/3 de facto doesn't support self-signed certificates. Once Chrome disables HTTP 1.1/2 which it will at some point in the name of security or performance, you'll only be able to exist on the web with a CA signed certificate.

Yeah, it's difficult for me to always add the qualifer, "HTTP/3 allows self-signed certs but no implementation that exists in any browser allows self signed certs".

The original comment was opposition to HTTP/3 because of mandatory secure connections.

In reality, the opposition is misdirected; it is Chrome that requires secure connections, not HTTP/3.

Plenty of browsers allow self-signed certs—Firefox and Safari, to the best of my knowledge, treat HTTP/3 certs exactly the same as they treat HTTP/2 and HTTP/1.1 certs. Chrome has taken the position that it will no longer allow self-signed Root CAs for HTTP/3 websites, to prevent SSL interception with companies intercepting all of your traffic. For personal use, you can always whitelist an individual certificate using a CLI flag without allowing a trusted root CA

My testing in the past seems to indicate you're wrong. Firefox does not support setting up HTTP/3 connections without CA TLS. Unless they've changed it since version 115 esr. While the neqo lib they use for HTTP/3 does technically allow it unless you compile it yourself with all the flags required for it FF ships with neqo having CA TLS required and no support for self-signed certs when setting up HTTP/3 connections.

I'd love to be wrong or shown a newer version that does allow these things. It'd be a huge load off my mind.

For some reason I wasn't aware of that, but I agree with you.

There's no reason for to mandate TLS for everything just because of a protocol.

You can use self signed certs, you just have to add your CA as a trusted CA.

"A self-signed certificate is one that is not signed by a CA at all – neither private nor public. In this case, the certificate is signed with its own private key, instead of requesting it from a public or a private CA."

This definition sounds right to me. Do you disagree with it?

I get what you're saying, that you can set up a certificate yourself. But you can't accept a certificate someone else set up. (in Chrome)

That's definitely the wrong definition. A self-signed certificate is a certificate that is signed by the private key corresponding to the public key contained in that certificate - in other words it's signed by itself.

In fact every CA root are by necessity self-signed and therefore signed by a CA (i.e. itself)

I don't think they were talking about certificates that were also CAs. It's not wrong, it's insufficiently precise.

Anyway, your definition is clearer, but it still supports the point I was trying to make. You don't "add your CA" in order to use self-signed certs. You do that to use a private CA that will sign all your certs. And doing so only allows you to use websites you signed, not websites other people signed. It would be a terrible idea to add anyone else's CA, and you can't easily use your CA to slap your signature onto websites other people signed. Adding your own CA is a completely different situation from trying to visit a self-signed site.

If you need certs for local dev, use a local CA. Tools like mkcert automate this.

If you need certs if a private network, either use Let's Encrypt/ACME or run your own CA and add the CA cert to your machines.

Dude. Everyone is asleep.

The largest, most frequent, and easiest to exploit but also easiest to fix issue continues to DOMINATE hacks:

Not sanitizing user entered inputs.

Not saying this is an excuse to rid of TLS, but TLS is not really where the main focus of people hosting home blogs needs to be.

Which home blogs even take any user input?

> Have you been completely asleep at the wheel

Can you please edit out swipes like that? Your comment would be just fine without that bit.

This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

> Have you been completely asleep at the wheel over the past 20 years as ISPs around the world have started injecting ads in people's unencrypted HTTP traffic?

Now finally those that forced HTTPS on everybody have a monopoly on that :-) (joking, but only in part...)

The crux of people's objections is that to bring up a "secure" site with this mechanism, you need the blessing of an unaffiliated 3rd party.

And yea, for the last 20 years ISP's have been doing stupid stuff with people's connections, but companies have been trying harder and harder to lock down the internet and put the genie back in the bottle.

(This is the core of the objection to PassKeys, FWIW)

If HTTP/3 let users run their own secure site, without any 3rd party parts, then we are good. Why not a trust-on-first-use mechanism, but with a clear UX explaining the implications of accepting the certificates?

> Have you been completely asleep at the wheel over the past 20 years as ISPs around the world have started injecting ads in people's unencrypted HTTP traffic?

ISPs are in my local jurisdiction, under regulators I may have voted for and I have a contract which them which I could get checked by courts if it's important enough to me. And I've voted with my feet by switching to a different ISP when the previous one did even a hint of nefarious DNS things (they never injected something into HTTP ftws, "merely" NXDOMAIN hijacking).

I can't say the same about google, cloudflare, let's encrypt and so on.

Trading a cacophony of some local good and bad ISPs to a quite US-centric dubious companies is hardly an improvement.

Also, it's a general sign that things are in a low-trust equilibrium when all this extra complexity is needed. HTTP is perfectly fine if you live in a nicer pocket.