5 ms·
You're against HTTP/3 because it makes security mandatory? Have you been completely asleep at the wheel over the past 20 years as ISPs around the world have st
by dmazzoni 3y ago
You're against HTTP/3 because it makes security mandatory?
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?
That's great that you want to host a simple website that other people around the world can visit using simple HTTP. Maybe if your website is completely benign and harmless, that's not unreasonable.
But a lot of us want to share information that's important, or sensitive - and we want sites where people can interact privately. I don't want the content of my site manipulated by third-parties along the way, and I don't want them snooping on traffic as people interact with my site.
- superkuh 3y agoYes, 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.
- afiori 3y ago> If the HTTP/3 implementations allowed self-signed certs Is it forbidden at the protocol level or by the implementations?
- treesknees 3y agoIt'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-deployment-options-part3/ https://www.smashingmagazine.com/2021/09/http3-practical-dep...
- remram 3y agoYou can add trusted CAs to your system though...
- treesknees 3y agoThat 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.)
- tambre 3y agoRFC 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 https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2
- paulddraper 3y agoHTTP/3 allows self-signed certs. Chrome does not. But that choice is orthogonal, could happen with any protocol.
- vinay_ys 3y agoI didn't know chrome didn't allow self-signed certificates. Since when?
- giantrobot 3y ago> 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.
- superkuh 3y agoYeah, 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".
- paulddraper 3y agoThe 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.
- PH95VuimJjqBqy 3y agoFor 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.
- cortesoft 3y agoYou can use self signed certs, you just have to add your CA as a trusted CA.
- Dylan16807 3y ago"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)
- poizan42 3y agoThat'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)
- Dylan16807 3y agoI 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.
- dharmab 3y agoIf 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.
- wredue 3y agoDude. 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. Ah. I see the “it’s easier to reason about” crowd of hype driven developers are here, as indicated by how the voting is going.
- ric2b 3y agoWhich home blogs even take any user input?
- dang 3y ago> 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 https://news.ycombinator.com/newsguidelines.html.
- mrighele 3y ago> 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...)
- deleted 3y ago[deleted]
- jasonjayr 3y agoThe 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?
- the8472 3y ago> 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.