> Your devices can get letsencrypt certs

I don't want all my internal network hosts exposed on a certificate transparency log.

I want my http connections to work without scary warnings in my local home network. Because if you show me scary warnings, and no meaningful way to implement the http connection securely, I will just start to ignore them. And if I ignore them in my lan, I will ignore them on the internet too. And that would be a net security loss.

So either use something else entirely inside a lan, like ToFU like ssh, or allow http connections without tls and without scary warnings. But I think deprecating http in local home lans with no meaningful way to make them secure is not a step in the right direction.

There are three options

1. All your systems are provisioned to trust your CA, which can have any rules you like. This counts as "Secure". Almost certainly your rules are garbage, but I don't use your systems or trust your CA so I don't care

2. Your local systems which you refuse to be transparent about are marked "Not Secure" because there's no reason for a client to have any confidence in their identity

3. You offer transparency so that everyone (e.g. me) can see that there aren't any shenanigans with the global public systems we all trust.

The fact that you don't like any of these options doesn't mean there are no options, just that you didn't like them.

Removing the 4th option, do nothing, is the issue here. Action is being forced that has no impact to GP.

Your "Fourth option" is still there, but this universe has time's arrow, so you get the second outcome I described.

Because of time's arrow, it's mistake to assume that if you do nothing then nothing will happen, you're literally up against the Laws of Thermodynamics. The only people who think you might win that fight are crackpots building perpetual motion machines.

Note that this is just the "not secure" display on the address bar - it isn't the full blocking page you would see for HTTPS with an invalid certificate.

I think the assumption is that for internal hosts you know the risks and can selectively ignore them but you should be warned about the issue on external hosts out of your control.

letsencrypt now supports wildcards, so that plus appropriate DNS setup should make it possible to use HTTPS on internal resources that you create so users other than you and other admins shouldn't need to worry. If you don't want to use an external resource for certificates then you could install your own CA key on the machines that connect to your network and then sign your own internal certificates though this is more work.

For things you really can't do much about, configuration pages for modems and routers for instance, your base users don't need to care, and you as an admin know the score.

I'm happy to have a little extra hassle as an admin so that the default for man-on-the-street users is as helpful as possible. We still need to properly educate people on exactly what "secure" means though, which is a grand task... "Don't put personal or login details into anything marked as not secure" is a starting point but that is a bit too simplistic as the transport being secure does not necessarily imply that the code at the other end is in any way trusted.

Sounds like a startup idea, make privacy with CA transparency easier.

You might start a CA without transparency. Browsers would not include it by default, but at least you would only have to install it once and wouldn't have to run a CA yourself. (Or a CA service that would give everyone their own CA - I suppose these exist but there might not be a SOHO targeted one).

Or you could make a DNS zone provider that by default sets up a bunch of nondescript domain names with LE integration, so outsiders can't tell their purpouse or activity level from the CT log. This could also be sold to the router/printer vendors as the vendor-provided DNS, advertising that it's GDPR compliant.

Or put everything behind the same domain name, with different services using different ports.

Let's Encrypt now offers wildcard certs, so you don't have to expose specific internal domains in the certificate transparency logs anymore (just the top-level one).

You're right but nobody cares - the market share of people with your problem is small and software vendors like Google will probably not spend too much money catering for people like you.

Harsh but true.

> the market share of people with your problem is small

I don't have stats or data, but I don't think the households with devices that have web interfaces like a nas, routers, media centers, and stuff like this are small.

Yes it is and if you look at something like routers, most people will never look at the web interface (or know it exists). You are overestimating the general publics technical savvy and accessing a web interface counts as technical savvy.

Do we want that companies making NAS (for example) starting making them work from a cloud based interface (and thus externalize some of your private datas) to avoid Chrome alerts ?

Personally I’d rather not.

My NAS, firewall, wifi AP and all 5 of my Raspberry Pi all serve proper https pages. It is absolutely doable and scriptable. I haven't had to manually update a LE cert all year.

> Your devices can get letsencrypt certs just like before

Parent comment was talking about routers and network printers. No CA (except for if you're your own CA) would provision a certificate for "192.168.0.1" or "hp-laserjet".

Insecure LAN resources should be probably treated differently from just "secure/insecure".

Just keep your routers and printers in the DNS. Or someone, such as your printer/router vendor, can do it for you.

If you are talking about networks that are air gapped from the internet, you would have a problem anyway with the short letsencrypt expiration times, and you will in any case need to do all kinds of hoops that are bigger problems than installing a local CA or settling for a "insecure" browser warning.

(Also LAN doesn't automatically mean rfc1918 addresses for many people, and getting less so all the time with IPv6 deployment coverage)

Are you seriously proposing that I expose my printers to the public Internet just so that they can use HTTPS on a local LAN?

If I must choose between the possibility that an attacker with local access might snoop/change my printed documents, and a possibility that my printer will become part of the next botnet through some firmware exploit, I'll definitely choose the former.

Addressability != reachability. This is how the internet used to work before people got stockholm syndrome with NAT :)

Letsencrypt doesn't require you to run a public facing web server on that domain, you can use DNS challenge validation where you prove control by putting a TXT record in your domain.

  printer-level0.printers.coorp IN A 10.10.10.10

Not a problem in any sane DNS, not a problem for your issuer (who doesn't care about the IP) - though it could leak data outside. So to fix it, you could just solve the challenge in outside-facing DNS and only resolve the IP address if the request came from inside the corporate LAN.

Also, my school has so many IPs that they do give public IPv4 addresses to all machines, printers, etc. but block access with a firewall.

> Are you seriously proposing that I expose my printers to the public Internet

Adding a name->address mapping for a private address doesn't magically make the private address globally routable.

You being able to see that my.internal.web.server.domain.tld maps to 192.168.43.123 doesn't mean that you can see that web server from your location.

Even if it was actually a directly routable address rather then one sat behind NAT it wouldn't be accessibly unless I'd expressly added a rule for that in my firewall to override the default "no access from outside unless some other rule has stepped in" rule. And this isn't a DNS issue either: even without the name that address would still be exposed with a bad firewall setup.

> Parent comment was talking about routers and network printers. No CA (except for if you're your own CA) would provision a certificate for "192.168.0.1" or "hp-laserjet".

hp could get a cert for 15327c5ba80d1b8933.hp.com and make it resolve to 192.168.0.5 (your printer).

What if someone else uses 192.168.0.5 for their printer too? This just seems incredibly insecure, where I'll have to keep a public record of the private addresses of my devices. Welcome to the Fishbowl.

Yes, RFC1918 addresses are ambiguous, and generally they have this problem, independent of using DNS. You should use IPv6 if you can.

But now you are running TLS, so the address conflict would just yield a cert error. (If the other guy plugged his network or printer into yours, that is)

Yes, I'm running TLS behind my NAT, where unsecured traffic should be safe. Or should we be using VPN tunnels within our private networks?

And at the same time, I've introduced an internet connection dependency and a 3rd party dependency. What happens when they decide to stop updating that cert, to save money?

You shouldn't treat a SOHO or home network, NAT or not, as secure. There are good reasons why we don't trust the network. Getting compromised is not an "if", it's a "when".

But then what about when the printer’s IP address changes because it’s dynamic?

ddns?

Or use addresses like https://192-168-1-1.hp.net (https://192-168-43-123.hp.net, https://10-20-30-40.hp.net, and so on) and a wildcard cert. No harder to document than telling people to go to http://192.168.1.1.

Though they should be more careful than to use to top-level domain as they need to include the private key in the device unless they have the devices call out to have a new certificate generated, perhaps 192-168-1-1.internaldevices.hp.net and so forth.

It would be necessary to use a different private key on each device for it to be secure, so something like 192-168-1-1.internaldevices1489420.hp.net

DNS got fixed to handle dynamic updates in the early 2000's.