Hacker News Reader

Comment by janosdebugs | Hacker News Reader

Are you saying that you can't create a self-signed CA that Chrome will trust when configured to do so?

Personally, I'm using Letsencrypt with DNS validation for internal projects. A wildcard certificate that needs to be renewed every 3 months for a domain does the trick, the servers themselves don't need to be on the Internet, just have a domain-based name. (I have some Ansible automation behind it.)

View on HN

I can. My ex can't. My parents can't. My ex's parents either can. Strangely enough, normal people can't. And that's the issue.

And what services do these people need to access/run on the local network that can't possibly be encrypted? The average person shouldn't be doing any of these things.

My home router for example always throws up a big scary https warning. I'd also very much prefer it if more smart devices were local network only rather than relying on a vendors website being up in perpetuity.

I'm actually not against browsers pushing HTTPS, I'm all for it. But it is a fair criticism that there are real downsides that there currently isn't a good user friendly solution for.

These days most non-IT people I know log in to their wifi network with the credentials printed on the sticker on the bottom. They wouldn't touch the web interface if their life depended on it.

which just exposes the wifi as an unsecured network, leading to far worse outcomes!

Which is why having secure connections enforced for the typical use case is doubly important. We can't wish a more secure solution into existence, this is how internet providers handle it in a great many places. Make TLS enforcement a very well hidden setting to turn it off/bypass, but don't let the average user anywhere near this.

Use Caddy as your webserver, use the DNS01 challenge, and you're done?

Don't expose your local stuff over the internet without encryption. The ISP doesn't need to see that.

How is your home internet router going to retrieve a certificate from Let's Encrypt before you have logged in and configured it to connect to the internet?

Your preloaded root chain? I mean you can also trust on first use if you really want to.

My point is this.

I'm a consumer. I buy a new router. I need to log into its web interface to enter the PPPoE credentials from my ISP before it can go online. I plug it in, and browse to 192.168.0.1. Chrome says in big letters "PAGE IS NOT SECURE YOU ARE BEING HACKED DON'T VISIT THIS PAGE".

This situation means the router can't go online to generate a trusted certificate, and it's left with either HTTP or a self-signed certificate, both of which Chrome will present as inherently dangerous.

The solution that router manufacturers seem to be going with are "you must own an Apple or Google OS device, pray that we still have our app on the store in your country and support your router, and accept our onerous privacy terms"

> you can also trust on first use if you really want to

That's a totally acceptable solution! But one that Chrome does not seem interested in making look safe to users. They could do it for known-local IP ranges and hit 99% of the use cases (10., 192.168. etc)

“ This situation means the router can't go online to generate a trusted certificate, and it's left with either HTTP or a self-signed certificate, both of which Chrome will present as inherently dangerous.”

What are you on about? How does the router not having a valid certificate mean it “can’t go online”?

Curious: is this how routers are handled where you live? In Austria and the neighboring countries you typically get a device from the provider preconfigured, even if you don't want one.

Yeah. You're only guaranteed to get a free router if you also sign up for VoIP service which requires it and even then it will probably be wired-only and need a card to upgrade it to WiFi.

Ohwow, that's less than ideal. I wish I could convince my provider to let me use my own router so I can get rid of the double NAT, but I'm probably 1 in 10000.

I consider managing a CA at home to be a _much_ bigger security risk than having HTTP traffic on my home LAN.

Sign a certificate expiring in 2070 and delete the CA key. That's all management you need. And if anyone has access to your disk, it's much easier for them to add you their CA certificate than search for your CA key.

That may be so, but I from the perspective of a few billion people using Chrome, the percentage of people that need to and should access something on the local network without encryption is probably a few magnitudes smaller than the same audience on Hacker News.

This doesn't make sense unless you use the CA for something in addition / more critical for HTTP.

Sure, you could leak said CA, but it's only going to leave you in the same position as HTTP.

You can generate CA certs that are only allowed to sign certs for specific domains, but _nothing_ respects that self limitation.

That means that if the CA keys get out, someone could use it to sign their own cert for google.com, [mybank].com, or [mypasswordmanager].com. Every device with my CA cert on it will trust those.

That's a fair point.

Yes, that would work.

It still sucks that if I want a browser on my LAN to talk with a server on the same LAN, I now somehow still need internet access (to renew the cert), need at least two accounts on 3rd part cloud services (the domain registrar and Let's Encrypt) and have to continuously pay for the domain.

Oh, and also have to mess around with the DNS configuration on the router, so the domain is correctly resolved to your LAN IP inside the network, but does not have A/AAAA records on the internet.

Also, this solves this problem for geeks with some knowledge of network protocols, but it still leaves everyone stranded who would like to run a local server but has no deep technical knowledge.

Finally, it's impossible to solve this problem in a large-scale manner, i.e. for devices you want to sell. Which is why the access menus for home routers will probably still stay on plaintext HTTP.

Funnily enough, some companies managed to solve the router problem. The Unifi Dream Machine is perfectly first-time configurable from a mobile app. Simpler routers don't really need any configuration these days and most people get routers from their provider anyway, whether they like it or not.

When talking about smart home devices, much of these are configured via their own apps, it's not like you are accessing a web interface much. If you are... well, there have been a number of remote code executions in these, so I'm not sure that bypassing a certificate warning is the biggest problem here.

Generally, I believe if someone can't set up a certificate then they don't have any business running web services for other people. The big problem is that it's not trivial for a browser to decide what's on "the local network" and what isn't.

Yeah, I think the general trend is that all those devices either assume you have an app or only talk to the vendor's cloud service anyway.

It's working, it just ensures that absolutely everything needs internet access.

We had a few decades to come up with a viable trust model for the local network. We didn't and it's not like we can install software without internet access anymore, so maybe it's time to move on.

I don't think you need to pay for a domain, nor do you need internet access to renew the certificate. You could either just have the cert point to an IP, or you could have the domain resolve to something at the router level/ configure our DNS however you like so that it resolves to the other device.

Or you can just disable the strict HTTPS settings, which this post addresses?

> We know that enterprises and education networks have unique needs. These features can be turned on early, customized, or turned off entirely via the HttpsOnlyMode, HttpsUpgradesEnabled, HttpAllowlist, and InsecureContentAllowedForUrls policies.

> I don't think you need to pay for a domain, nor do you need internet access to renew the certificate. You could either just have the cert point to an IP, or you could have the domain resolve to something at the router level/ configure our DNS however you like so that it resolves to the other device.

If I use a custom root CA, I don't need a domain. However, then my local server will only be accessible on devices where I can install the custom CA, i.e. usually, my own devices only.

If I want the server accessible to other people, I need a cert from a real CA - and those are basically forbidden from granting certs for 192.168.* IPs or really anything that is not a properly registered internet domain:

https://www.globalsign.com/en/blog/certificates-for-internal...

> Or you can just disable the strict HTTPS settings, which this post addresses?

That as well works for my own device, but not for devices of other people.

So the situation is that someone is in your home with their own device and you don't want them to click through the "HTTP" warning? Seems niche tbh but I can understand that I guess.

The HTTP warning may become progressively harder and more confusing to click through, if chrome continues its strategy as they announced in the OP.

Usecases would be more something like "shared server in a student dorm / local server for family and friends / art installation where people are supposed to connect their phones to / smart device with a local web server for configuration", etc.

Niche indeed compared to the public internet, but still substantial.

How substantial are the situations really where you can't afford a 10-15$ domain and running a trivially simple tool to obtain a certificate? What kind of an art installation has the budget to set up a wifi network, set up servers, etc but then doesn't have internet? (Most phones won't even connect to a wifi network without internet if I remember correctly.)

Is there a way to do this for default Chrome installs? The whole point of hosting something for LAN is so family members can use the site on a whim from their iphone.

AFAIK Chrome uses the OS certificate store, so you should just need to provision your CA in the OS itself.

For iPhones you may be able to use configuration profiles, which are also useful if you want to set up stuff like email accounts, etc. However, it's been a while since I made on of those, so I don't know if you can use it for certificates. You may have better luck with Letsencrypt instead.

You can use it for certificates, it just looks like there's an extra step to say that you really trust it as a root: https://support.apple.com/en-us/HT204477

That extra step is only required when you deploy the certificates through one of the less secure methods:

> You must manually turn on trust for SSL/TLS when you install a profile that is sent to you via email or downloaded from a website.

The more secure deployment methods do not require this:

> Apple recommends deploying certificates via Apple Configurator or Mobile Device Management (MDM). Certificate payloads are automatically trusted for SSL when installed with Configurator, MDM, or as part of an MDM enrollment profile.

Both of these quotes are from the link you provided.

I figured most people looking to do this at home wouldn't have a home MDM solution to deploy it with. You're right though that it could probably be done with Apple Configurator fairly easily.

I’m planning and in process of doing the same. I am trying to figure out how to easily automate it, though.

Pork bun offers automatic ssl, but I’m not sure how that works. My servers would still all need to download a PEM or w/e right? So while support for that sort of feature is neat, I still need to automate pulling the certs. May as well just do it directly from LetsEncrypt and modify the DNS .. maybe.

I dunno, still exploring.

Yes, you need a way to distribute the certificate PEM to your servers. The key PEM you have to generate yourself. However, nothing mandates that the server using it needs to have direct internet access, see my explanation here: https://news.ycombinator.com/item?id=37153485

That sounds intriguing, could you please elaborate?

I assume you are interested in the Letsencrypt part. Basically, I'm running an Ansible script on my computer, which creates an account key, the server key and requests a certificate. The server key and the certificate are then distributed to the servers that need them, leaving the original account key only on my machine. The Letsencrypt verification happens via my DNS provider, which happens to have an Ansible module.

Here's the source code: [link redacted]

Reply on news.ycombinator.com