Hacker News Reader

Comment by jjkeddo199 | Hacker News Reader

This globally-enforced move to HTTPS is killing the security and privacy for home projects and intranet-hosted websites. If Google forces HTTPS everywhere, and refuses to accept "self signed HTTPS certs", then there is no path left for security-camera/home-automation/staticIP-family-websites without being forced into going over the internet. I can't even show my projects to my non-technical friends without looking like some scammer because of these dumb warning messages plastered all over their browsers on my own wifi!

Chrome team: Either start accepting self-signed certs for LAN, or drop forced HTTPS for intranet altogether -- I DO NOT want to put my family's or my personal-project data on the internet!

View on HN

>I DO NOT want to put my family's or my personal-project data on the internet!

DNS-01 challenges addresses this, the webserver never needs to be exposed to the internet.

>I can't even show my projects to my non-technical friends without looking like some scammer

How would the alternative work? If https enforcement can be disabled server side without a notification to the user, what is the point of https? If it's something that can be set on the user side, how would it be substantively different than the user accepting a self-signed certificate?

> How would the alternative work?

It's not an easy problem to solve, but I think it would be possible to extend PKI to make it work for local networks without internet access.

An approach could work as follows:

Dedicate a special TLD for "local-only domains". Such domains are only expected to be valid inside a specific LAN, analogous to 192.168.* IP addresses. (In fact, several TLDs with that kind of intended use already exist [1])

Specify some way how a local network can announce a CA specifically for that network (maybe through a DHCP extension, a special "well-known" hostname or IP address or a field in a wifi beacon message)

When a user navigates to a local-only domain, the site's cert is validated using the network's CA. The CA is only valid for local-only domains and only while connected to that specific network.

This would allow using PKI and encrypted connections inside a LAN, would not require internet access or 3rd party services and would also not compromise the security of domains on the internet.

[1] https://unix.stackexchange.com/questions/92441/whats-the-dif...

Several problems with this proposal:

1. Who defines what the local network is and why should this environment be trusted more? The IP address doesn't guarantee that the packets won't be going round the globe 3 times.

2. You are proposing a whole new, as of yet unresearched verification mechanism to TLS, which won't be supported by a whole lot of devices for a long time. I just had to downgrade a server of mine to TLS 1.2 because a high profile software couldn't deal with 1.3.

3. DHCP is inherently insecure and setting up a rogue AP is also not too difficult outside of an enterprise environment where certificate rollout is already not a problem. Ideal for hijacking an intranet connection covertly.

4. The proposed CA would not have the benefit of public transparency logs, so it would not meet the minimum requirements currently set forth by the browsers to trust a CA.

5. What happens if you are connected to more than one network at a time? Which one gets authority over the special TLD?

6. Who guarantees that the connected client uses the mandated DNS servers to resolve the special domain?

This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.

1 + 3:

DHCP, wifi identification or what you can reach with a broadcast would be examples. If that's too insecure, out-of-band identification would also be possible, i.e. a QR code that contains a SSID, a hostname/IP address where the CA cert can be downloaded and a hash of the cert.

I don't see why it's important how the packet is actually routed as long as you have established a root of trust.

2: Yeah. So?

The worst that can happen to a device that doesn't have support is that it sees an invalid certificate.

I don't think widespread support would be necessary. The only software where support would be essential would be browsers.

4: Neither is a local root CA today. The entire point of the proposal is that it doesn't require any third parties. To make up for this, the CA is only valid for local domains, so you can't generate rogue certificates for google.com anyway.

5: That's a good point, but strictly speaking, the problem already exists today: what happens if you're connected to two networks which route the same IP address range? Or which reuse the same hostnames?

One option would be to add some sort of network identifier to the hostnames to make them unique. This might make the domains unwieldy to use though.

6: The same thing that "guarantees" that the client uses the network's CA for validation: The client itself, that hopefully correctly implements the spec.

You have the same problem with the "split DNS + LE with DNS validation" approach: If a client has 1.1.1.1 hardwired for DNS resolution and you only serve A/AAAA records inside the network, the client won't see your server. That's why even DoH will fall back to the network's DNS servers if it can't resolve a domain over the DoH server.

> This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.

Local-only hosts may be less secure than internet hosts, granted - but how would this reduce the security of everyone else?

>out-of-band identification would also be possible, i.e. a QR code

Any out-of-band method of enabling what you are talking about is necessarily going to prompt the user with the same kind of serious-looking security prompt they would see when adding a self-signed cert to the OS certificate store.

You are making excellent points for using globally resolvable DNS + Letsencrypt. :) None of these problems exist with that solution. Unless you enable AXFR, your hostnames won't be easily visible to the outside world and wildcard certificates are a thing too.

Specifically:

1,3,4,6: You want a seamless experience for the user and are assuming that the user is capable of making the decision to trust a network operator. This is not a decision an average user can make. Say, I set up a rogue AP for your university network which uses this special TLD. You connect to my AP, log in to your uni account on the special TLD, and now I have your credentials because you went through my reverse proxy. Very easy to pull off, almost impossible to reconstruct after the fact. QR codes, etc don't offer any protection here.

5. AFAIK the problem doesn't exist as far as domain names are concerned, search domains work across multiple networks. mDNS can also work across multiple networks to resolve host names. For IP addresses this is a problem, which the abundance of possible locally admininstered addresses with IPv6 will hopefully solve (ULA address ranges).

If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment. You'll have to jump through the hoops of making that environment trusted on the endpoint devices too. Any attempts of making peer to peer trust a thing have failed miserably over the last decades and nobody really seems to put any effort into writing, implementing and proving these standards anymore. It's too easily abused and determining trust is beyond the capabilities of the layperson, heck it often trips up experts too.

Yeah, you have a point. The fundamental problem is always: How can I keep an adversary from cloning/proxying a legitimate site then trickung users into visiting it. It's a hard problem even if there is a centralized authority and pretty much still open for decentralized systems.

I still think however that there are some properties of local networks that make this less risky:

- an attacker needs to be physically close to their victims in some way (or at least get devices into physical proximity): The rogue access point has to be located somewhere, someone has to tape over the QR codes, someone has to plug into the local network or connect to WLAN to send spoofed ARP/DHCP/DNS replies, etc. Compare that to phishing/typosquatting attacks on the internet where an attacker can be anywhere on the globe and can make their site look legitimate with a simple LE cert.

- an attacker is more at risk of being exposed. i.e. if someone keeps spoofing the university network, people might start to try and locate the wifi signal and knock on doors. That's a lot more risk than phishing/typosquatting for a lot less reward: Even if the attack works perfectly, you can only impersonate the local-only domains, not internet domains. (In fact, we don't currently live in an HTTPS-only world, so there would actually be some value for an attacker to spoof some campus wifi right now. I haven't heard of any incidents in that regard, so that leads me to believe that the risks are to high compared to the rewards)

- there are lots of situations where spoofing the CA information would require you to do a full supply-chain attack, such if I connect directly to a device using a cable or NFC connection; QR code stickers put directly on the device; if I manually add the device of another person to a wifi network I know, etc. (Those are slightly different use cases than "art installation" etc. I'd say they are still valuable though, e.g. for frictionless setup of local-only IoT devices)

> If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment

But that's the point, I don't want them to fully trust my environment. It's perfectly reasonable that there is no way to override the CA of say, google.com without an extremely scary security warning.

However, I'd like a way to offer some sort of website from a local network without causing a huge hassle for everyone who wants to use it or having to pretend I it's an internet domain.

The problem is that even if we assume this (or anything similar) is a good thing, we can't simply wish it into existence. The world is going into a different direction, everything is ever-more connected and apart from a very small minority, most local network admins are fine with Letsencrypt certificates or rolling their own CA.

If someone would want to put in the advocacy and development work, this would need to be written up in a formal fashion, probably in a scientific journal and/or an RFC published. Then there would need to be an implementation for at least one of the major OSes so security researchers can get their hands dirty with it and iron out the bugs. Once all this is done, you still need to convince Microsoft, Apple and Google to ship it in their OS because this is not a browser-only solution and needs OS support. And at this point the thing is probably pretty dead because their big customers are happy to run their own CA infrastructure, which leaves only a tiny minority of sysadmins for small systems that could ask for it. Not enough for these big companies to care because these small customers moving to Linux won't affect their bottom line. I would rather spend my time to advocate for simpler CA management or other verification methods with LE.

Honestly, I think the FQDN and Letsencrypt solution is fine. I've been using FQDNs for server names for a good 15 years now and I never had a problem with it. The people who didn't, however, had a bunch of pain to deal with, from having to merge networks to weird trust issues. I still remember the headless running around when .dev became a TLD and suddenly there was a conflict with oh so many folks' internal hostnames. Nothing about DNS says it has to be on the Internet. If you really want, you can even run a split DNS to make it only available in your own network, you just need to make the Letsencrypt verification work over the Internet.

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

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]

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

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

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.

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.

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.

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.

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

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

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)

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.

“ 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”?

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.

“Not Self-signed” and “on the internet” are not the same thing.

You can get a cert for a domain that you only use on your intranet. The only public thing about it is the domain registration.

You can even use Lets Encrypt to get that cert for no cost. You just need to own a domain

This is interesting to me. How would the DNS work without touching the internet? Or do you mean to say that only DNS touches the internet and rest of the site would be offline?

If I made some cool security-camera image-recognition project with YOLO and wanted to sell installs to my friends in the area, would I need touch their DNS settings too? Personally: I feel uncomfortable changing settings on other folk's routers. If I could get away with helping them set a static IP without touching anything else, I'd much prefer it.

The site can be served only within your local or private networks and use HTTPS. The certificate is issued using a DNS challenge, for a domain that you own.

You can buy a domain, put public NS servers on it for the only purpose of doing Letsencrypt DNS validation. Hint: Create root and wildcard (eg domain.ca and *.domain.ca) so you aren't leaking internal DNS records (not that it matters much).

You run an internal DNS server (Pihole + unbound is my combo of choice) which becomes authoritative for your internal LAN.

You can have a local DNS server that tells computers on your network where to find intranet-hosted applications. I use my Pihole for that purpose, but you can set up a regular DNS server just as easily.

In my case, my router just has a setting for what DNS server to use, and I point it at my local DNS instead of 1.1.1.1 or whatever.

This is one of the concerns that lead me to build getlocalcert.net. You don't need to expose your home network to the Internet, you don't need to buy your own domain name, you don't need to convince your friends to install a private CA, and it doesn't cost any money.

Check us out: https://www.getlocalcert.net/

Blog post author here.

I didn't talk about this in the post mostly for brevity, but the challenge of HTTPS on local networks is absolutely on our radar. We're still evaluating what the right strategy is for addressing it, but we definitely _are not_ going to show big scary warnings on all local network access or otherwise make them inaccessible.

They also updated Chrome a long time ago to stop showing which protocol you are using on the address bar, which IMO is a very stupid decision. I want to know if the site I'm accessing has HTTPS by looking at the URL, I never asked someone to hide the protocol part of it. Okay, there's the green padlock, but still, I want my full URL, I don't want my browser to hide my URLs.

You can right click on the address bar and check the option "Always show full URLs" if you want to see the protocol still.

They're making these changes for the average user who doesn't know the difference and who can't tell if a site is secure or not based on the protocol part (or who misinterpret what it means in terms of security vs trustworthiness). The padlock is no longer green in Chrome and will be going away next month too. The states will just be secure (no warnings) or not secure (displaying a warning). It shouldn't be something people have to think about in this day and age unless there is a problem (e.g. cert expired, cert mismatch, not encrypted at all) as sites should just be secure by default.

If you own a domain it's trivial to request a certificate for it using just DNS. There's no need to expose anything to the internet.

This. Also, plain old http is appropriate for many project is and many websites. Sure, https first, but let's not make it https only.

"HTTPS only" is Google's end goal though. There is already the rule that all new web features are only enabled for https. As they write in the OP, it's possible that plaintext http will even lose features in the future that are still supported currently, like long-lived cookies.

> I DO NOT want to put my family's or my personal-project data on the internet!

Use Firefox?

Its not as easy as you think to convince your friends/family to install new web browsers. Websites should just work

Websites do just work, the browser doesn't. "You can't access the internal LAN because your browser is bad" should be a compelling reason for them to change.

A non-technical user doesn’t know that. They just know a site isn’t displaying correctly.

"Why do I need to change my internet thing?"

"Because Chrome is enforcing security standards that--"

"I don't care anymore. I'll keep using the internet I use now."

"You can, you just can't use that site any more."

If you don't want TLS warnings then just create the certificates from a single (self-signed) root CA and deploy the CA certificate in your local Chrome, Windows, etc.

As an added bonus you get actual security. Since anyone can just recreate your self signed certificates currently because no one bothers to check them.

For example something like this: https://arminreiter.com/2022/01/create-your-own-certificate-...

So somebody who doesn’t know what they’re doing should roll out PKI, which if compromised would result in the ability to inspect encrypted payloads for all websites they visit, including banking. Because there’s no excuse for not TLS. Got it.

Yes, that's nice and all if you only want to access the server from your personal phone/laptop/etc.

It doesn't help at all if you want to show the server to others.

Reply on news.ycombinator.com