Can't you sign your own certificates? I honestly haven't done any work with http/3 so it's a sincere question.

I could. But that wouldn't help make my website visitable for anyone. I'm not trying to access my own hosted site. I want a random person on the other side of the world who I've never met and will never meet to be able to visit my website. That's the point of public websites.

Generating my own root cert and using it does not help with this at all since no one else will have it installed nor install it unless I'm already good friends with them. Installing a root cert in the various trust stores is no simple task either.

The easier self-sign with no root cert also doesn't help because every current implementation of HTTP/3 does not support self-signed certs.

I mean you have to do that with https now if you don't go with one of the big guys? How is that any more dangerous to the end user than just going to an http site that they don't know personally? The risks are the same as far as malware.

>How is that any more dangerous to the end user than just going to an http site that they don't know personally?

Installing a random root cert to your trust store is a very dangerous thing to do but you're looking at this from the wrong end. I'm not talking about the dangers of a random user installing a random TLS root cert from me I send them over, what, email? That's just not going to happen. It shouldn't happen.

I'm talking about the ability for human persons to host visitable websites without corporate oversight and control. With HTTP/1.1 I can just host a website from my IP and it's good. Anyone can visit. With HTTP/3 before anyone can visit my website I first have to go ask permission every ~90 days from a third party corporation. And if I piss them off (or people who put pressure on them in certain political regions), say by hosting a pdf copy of a scientific journal article, or a list of local abortion clinics, they can revoke my ability to host a visitable website.

With HTTP/3, as a human person, the cure is worse than the "disease".

I think they meant, can't a visitor just ignore that your cert is self-signed and view the page anyway, _without_ adding it to the trust store. Firefox, at least, has this as the default "ignore the cert error" action.

Setting up a root cert in a trust store and accepting a non-root self-sign cert are very different things.

That said, "can't a visitor just ignore that your cert is self-signed and view the page anyway,"

No. They cannot. Not when it's HTTP/3. Even if the browser ostensibly supports it the HTTP/3 connection will fail because the HTTP/3 lib Firefox uses does not allow it.

Would that actually help your cause, since it would push people to build and distribute their own user agents which accepts self-signed certs/CA in a user-driven community without big corp oversight?

You'd have to get all the major browsers to trust that CA, it's not possible to do that without "corporate oversight".

That's the point the other poster is making, it adds a new level of control that becomes the de facto only way to do things if http 1.1 ever gets deprecated.

I have no opinion on the likelihood of any such deprecation but I fully understand the concern.

Thats mainly a problem with the browsers, no? Not saying it isn't an issue, obviously the big ones are going to drive a lot of this technology, but you could still use something like curl or whatever.

And where do you get that IP? From a corporate ISP? From a corporate host? From a politically pressurable entity like your local NIC?

Let's Encrypt and similar services will allow you to do exactly that though...?

Every visitor would have to manually trust them; provided they're using a browser that still allows them to do so.

This is literally the same as HTTP except that browsers don't (by default yet) put up a scary warning for that. But with a self-signed cert you get protection from passive attackers and once you press yes the first time it verifies if someone else tries to hijack your connection.

I think almost all protocols should have always-on encryption. You can choose to validate the other end or not but it is simpler and safer to only have the encrypted option in the protocol.

FWIW I have HTTPS-only mode enabled and I would prefer to be notified of insecure connections. To me a self-signed cert is actually better than HTTP.

I'm sure it will be a while until HTTPS-only is the default, but it seems clear that browsers are moving in that direction.

If you want a domain name, it was never possible to host your own webpage without involving someone else who owns the domain/name server side of things

But you don't need a domain name to host a webpage. It can be served over the IP address. You don't need a public IP either, a page can be for the local net.

But indeed, if you want a traditional webpage that is accessible over the net and possible to remember it's URL, then yes, you need a domain, and for that, you need (at some level, even if you're a registrar) the entity who runs the tld.

Hosting a HTTP/3 page for local net.....

I think we've gotten very theoretical

If HTTP/1.1 is deprecated from all browsers, and HTTP/3 eventually becomes the only way to view a web page, then it will be impossible to host a localnet web page (ex. a wifi router). The people pushing this standard through don't make routers, so they don't give a shit, and everyone on the planet will just be screwed. This is what happens when we let 1 or 2 companies run the internet for us

Pardon my knowledge. If we are to get very technical instead of for average people, surely you can self-sign a cert and setup your CA chain on the computers in your local network?

Or is there something else that prevents you from hosting HTTP/3 locally?

Knowing how to do that is quite a high barrier to entry.

Couldn't mkcert handle most of that process?

As far as I know, browsers don't allow self-signed certificates on HTTP/3. This was mentioned by people in comments here, and quick google seems to confirm.

You cannot use a certificate that was not signed by a trusted CA, but nothing keeps you from creating your own CA, making it trusted locally, and using it to sign your cert

Nothing except convenience and compatibility with dozens of operating systems that might operate on the network.

Can you even easily do it on Android? Without an Internet connection?

> making it trusted locally

That is precisely the problem. Most proprietary systems don't let you touch the trust store at all. Even "open" platforms like Android have been locking down the ability to do anything to the trust store.[1]

With that said, if we assume the user is only using Google Chrome and not an alternative browser, then typing "thisisunsafe" on the TLS error page should let one elide trust store modifications entirely. I cannot guarantee this is the case for HTTP/3 since the reverse proxies I deal with still use HTTP/2.

[1] https://httptoolkit.com/blog/android-14-breaks-system-certif...

One might then ask: why not just let the user click a button in the browser to see the page, without jumping through all those hoops? How does increased human toil make it better? (Spoiler: it doesn't)

Impossible because you'd need a server certificate? But you can issue it yourself and add a trust anchor to your browsers.

Look for routers that run an ssh server or have a serial console I guess.

Just use a proper browser

> If HTTP/1.1 is deprecated from all browsers

If HTTP/1.1, HTTP/2, and HTTP/3 is deprecated from all browsers the World Wide Web would shut down.

WWW is in danger! /s

Routers today are already dealing with this problem because Chrome throws major security warnings for any unencrypted HTTP traffic. The current solutions I've seen are to use things like Let's Encrypt/ACME certificates for wildcard sub-domains *.routercompanylocal.tld and a bit of secure handshake magic to register temporary A/AAAA records for link-local IP addresses (DNS has no problem advertising link-local addresses) and pass the private parts of the certificate down to the local hardware. Several major consumer routers I've seen will auto-route users to something like https://some-guid.theircompanyrouterlocal.tld and everything just works including a CA chain usually up to Let's Encrypt.

Doing Let's Encrypt/ACME for random localnet web pages is getting easier all the time and anyone can use that wildcard domain loophole if they want to build their own secure bootstrap protocols for localnet. It would be great if the ACME protocol more directly supported it than through the wildcard domain name loopholes currently in use, and that may come with time/demand. I imagine there are a lot of hard security questions that would need to be answered before a generally available "localnet ACME" could be devised (obviously every router manufacturer is currently keeping their secure handshakes proprietary because they can't afford to leak those certificates to would be MITM attacks), but I'm sure a lot of smart minds exist to build it given enough time and priority.

for routers there's a simple and easy workaround. Let's say your router answers on "router.lan". All they would have to do is redirect this name via the router's DNS resolver to, say, 192-168-0-1.company.com, which would be an officially-registered domain that resolves back to ... wait for it... 192.168.0.1!

If you control company.com you can run wildcard DNS for any amount of "private" IP addresses, complete with an official and valid trusted certificate. For an internal IP address. Problem solved.

(and no, this is not theoretical, there were appliances some 10+ years ago that did exactly that...)

Yeah, that is mostly what I was describing. There's some rough security benefit to using more transient A/AAAA records under a GUID or other pseudo-random DNS name than a DNS zone that just encodes common link local addresses. There are definite security benefits to a company using mycompanyrouters.com instead of their home company.com (XSS scripting attacks and the like). So some things have changed over 10+ years, but yes the basic principles at this point are pretty old and certainly working in practice.

Google actually makes a router?

Sci hub often needs to be accesses by a random IP and/or without a corporate-blessed TLS cert. The same goes for many counter-esrablishment sites across the world (China, Iran, ...).

The premise of the Internet was distributed dissemination of information for the mass public. There is a real fear that we are walking through practical one-way doors, ever increasing the barrier of access to disruptive counter-corporate/counter-state information.

It doesn't take a huge leap to relate these concerns to America's future political discourse.

Security and accessibility/simplicity are almost always at odds with each others. It's a tradeoff that needs to be made. You are entitled to dislike the current trend and prefer making security optional. But you can't possibly be surprised if most people are happy to prioritize their privacy and security over "the barrier of access to disruptive counter-corporate/counter-state information".

This is disingenuous.

The "most" in your strawman here is just companies like Google who want to a) bend to those who want to DRM the entire web b) hide and lock away their tracking traffic from those being tracked c) make ad blocking impossible.

Please explain why OC "can't be surprised."

HTTP 1 is on a depreciation path and HTTP3 requires TLS, which would mean getting the blessing of a trusted (typically corporate) root cert every 90 days to continue letting random people access my website.

In the US, states recently passed anti-abortion laws which also banned aiding and abetting people seeking the procedure. That would cover domain names and certs if any relevant tech companies had headquartered in those states - or if passed as federal law.

Trans rights are actively heading in that direction, and supporters are the very same that lambasted NYT and others as "fake news" that needed to be banned while pushing narratives of contrived electoral processes.

Fear of political regression is real in America, without even looking internationally.

Societal and technical systems evolve together. With the depreciation of HTTP1, future cheap middleware boxes will likely effectively enforce using HTTP3 and consolidate the tech landscape around a system that is far more amenable to authoritarian control that the prior generation of protocols.

It's fair and valid to call out such scenarios when discussing international technical standards. These protocols and the consequences will be around for decades in an ever evolving world.

> It’s fair and valid to call out such scenarios

Your whataboutism is utter nonsense.

You have no idea what you’re talking about, do you?

Not local net, more like samizdat net.

Still, you can always add private trust anchors and still have a samizdat net.

I have HTTP/3 on my local network using traefik + let’s encrypt and an internal zone. I didn’t actually go out of my way to set up HTTP/3 it was pretty much just a few extra lines of configuration so why not?

But I assume you have an officially-registered domain for that? That's the main issue people are having, that without an official domain (i.e. with only "foo.local" or whatever) it's hard to use HTTP/3

AFAIK Let's Encrypt won't sign certificates for internal domains?

Yep, you can get any cheap or seemingly random domain and just have the zone set to your internet device(s).

There’s nothing stopping you, pushing your own internal CA, though, if you’re big enough to warrant that

I know, I run two domains at home on a Raspberry Pi, I know that it's easy, but I also don't have an issue with paying 10€/year for a domain name. I guess this is the thing people are angry about, that by buying a domain you're funding the very corporate greed that will one day destroy the internet, or something...

Just to be pedantic, you only need a registrar to globally register the domain name and associate it with DNS records. You could choose to point your system at a locally-controlled DNS server, or edit the local /etc/hosts file, to use user-friendly names without depending on registering the domain with any authority.

That's not a great analogy. Your registrar is bound by a strict contract, in some countries it may even be telecom legislation, and your domain is legally yours (again, within contract bounds). While they need to delegate it to you, they cannot arbitrarily suddenly give it to someone else.

BBC.co.uk belongs with the Beeb, anything else would be considered an attack on Internet infrastructure and treated as such. You cannot compare that with the power Google has over Chrome. It is theirs to do what they wish with.

That's why Gnu Name System (GNS) and GNUnet are here

https://www.gnunet.org/en/

GNUnet helps building a new Internet

GNUnet is a network protocol stack for building secure, distributed, and privacy-preserving applications. With strong roots in academic research, our goal is to replace the old insecure Internet protocol stack.

https://www.gnunet.org/en/applications.html

The GNU Name System

The GNU Name System (GNS) is a fully decentralized replacement for the Domain Name System (DNS). Instead of using a hierarchy, GNS uses a directed graph. Naming conventions are similar to DNS, but queries and replies are private even with respect to peers providing the answers. The integrity of records and privacy of look-ups are cryptographically secured.

This was an HTTP/2 issue as well. IMO it was a big miss to not specify some kind of non-signed mode with opportunistic encryption. That is, if you set up an HTTP/2 (or /3) connection to a server that did not have a signed cert, it would do an ECDH exchange and provide guarantees that nobody was passively snooping on the traffic. Of course this would not protect against an active MITM but would be better than falling back to pure plain text.

Exactly. Unauthenticated encryption increases the costs of pervasive dragnet surveillance at a minimal cost/hassle.

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.

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.

As opposed to decades of stonewalling and sluggish progress just because a few big corporations didn't want to have a harder to manage IT system?

Literally most of the complaints against http3 are from corporate network engineers that now have a harder time controlling their networks. And more importantly, harder to implement mitm and monitoring. Which sure, that sucks for them but that's a massive upside for the vast majority of other internet users.

> Once Chrome drops HTTP/1.1 support say goodbye to just hosting a website as a person free from any chains to corporate ass-covering.

Is that even possible? It will effectively brick billions of consumer electronics that people have today (e.g. Routers, NAS Appliances, etc).

what do you think happened when browsers killed java,silverlight and flash?

Some of the hardware I have received a last minute firmware update to replace java applets with a minimal JavaScript fallback.

Your beef is with Google and the Chrome team, then. QUIC itself is a good protocol, and at the library level you can just tell it to trust any cert it sees.

Google doesn't need to enable QUIC to disable self-signed certs in Chrome.

it makes more sense than HTTP/2, which is retarded, but still widely adopted.

It's incredible how many servers can't do pipelining when queried with HTTP/1, but do it fine with HTTP/2.

For someone who complains about web stuff so much, it's weird that you don't have a better understanding of the technology. No amount of pipelining can fix HTTP/1's request-per-connection model enough to make it competitive with HTTP/2.

I would say I have a pretty good understanding of Ethernet, IP, TCP, and also HTTP, having written implementations of that full stack several times -- including pretty sophisticated ultra-low-latency tricks.

HTTP/2 implements multiplexing on top of TCP, which is just plain stupid. TCP is not meant to be used for this, and doing this is actively harmful; the correct thing to do is to establish multiple TCP connections. That sort of thing is not surprising since most of web and cloud tech is all about re-implementing low-level components on top of inadequate high-level abstractions.

The main reason to use HTTP/2 is simply that when a server provides both 1 and 2, the backend quality will typically be much better on 2.

Exhibit A

> I would say I have a pretty good understanding of ... HTTP

Exhibit B

> HTTP/2 implements multiplexing on top of TCP, which is just plain stupid ... the correct thing to do is to establish multiple TCP connections

> It's a terrible protocol for the human person web. You can't even host a visitable website for people who use HTTP/3 without getting the permission of a third party corporation to temporarily lend you an TLS cert.

Um, so many parts of web hosting require willing actions of corporations. Network, servers, etc. Why are you singling out just one part?