Hacker News Reader

Comment by pmlnr | Hacker News Reader

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.

View on HN

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.

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)

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

Just use a proper browser

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

> 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.

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...

Reply on news.ycombinator.com