Ask HN: Idea for LAN local Let's Encrypt, what do you think? | Hacker News Reader

Ask HN: Idea for LAN local Let's Encrypt, what do you think?

3 pointsJulianMorrison9 comments

This is an attempt at a solution to the problem of "I have a LAN service or an IOT device, and it can't serve HTTPS because it isn't on the open internet to reach Let's Encrypt".

It's becoming increasingly troublesome these days to run a service on insecure HTTP. Doubly so to run a service with a self signed certificate, which gets treated as a sign of evil intent by all browsers. Creating your own CA cert and installing it as a trust root is possible, but bothersome. It's implausible for non technical people to learn to do this.

Servers on the open internet can use Let's Encrypt to prove that they control their site, and obtain a certificate. This isn't true if the service is on a LAN-local IP and not accessible from outside. For example, a device that puts itself on your Wi-Fi.

New idea: suppose there is a service that exists on your LAN, perhaps normally living in your router the same way that DHCP does, and it exposes two operations:

- get a CA cert: used by browsers accessing HTTPS sites when they are on the LAN, the CA cert is included among the trust roots for this one operation.

- get a signed HTTPS cert: used by services in a similar way to Let's Encrypt to obtain a certificate that identifies them as a secure service on the LAN. Might either be open access (on a home Wi-Fi router) or whitelisted (in an office).

Over to you HN, do you think this is a good idea?

This will give a creepy feeling to many security experts, but here's my two cents:

The only issue with this scheme is that any device that trusts your "internal CA" can be MITM'd as easily as someone can use/abuse your "get a signed HTTPS cert" functionality.

Assuming your LAN is truly not connected to the internet in any form or way, it seems like the benefits outweigh the risks --- no connection to the internet, fewer chances to MITM to begin with...

As an additional security measure, you could use a PKIX name contraint [?] to restrict your CA to be trusted only for *.myinternal.lan, so even if your internal CA issued a cert for mail.google.com, it would be rejected by the cert chain verification. ([?]: not entirely sure this works everywhere)

Alternatively, if this is a limited internet scenario, and not a truly no uplink whatsoever, maybe you could get a wildcard LetsEncrypt cert, and share that across your IOT devices.

Part of the idea is that browsers just won't even bother looking at the CA cert as a trust root unless the IP is in the private network IP address space. So it will look for a 10.x.x.x IP, but ignore it for *.google.com.

Do you mean, have a shared signing cert that permits signing anything on the RFC1918 address space and using IP's as names? I think that has has been proposed a few times and shot down each time. Or do you mean something else? CA's won't create signing certs for random/fake/internal domain names. Similar question on serverfault [1] and security.stackexchange.com [2] and here is the Cab Forum's requirements on internal names [3].

For networks that are partially isolated, but have outbound DNS, one method (of data exfil) that may work would be if you could convince LetsEncrypt to have a DTLS API gateway so that certs could be registered/renewed over encrypted DNS. This won't help for fully isolated networks however, even if they agreed to make such a thing.

[1] - https://serverfault.com/questions/964119/enable-https-on-a-p...

[2] - https://security.stackexchange.com/questions/103524/lets-enc...

[3] - https://cabforum.org/internal-names/

I mean having a process, that lives somewhere on the LAN (in your router, for a home network), that has its own CA cert (self signed) and uses it to sign certs for services that live on the LAN.

Services can request the CA cert, and they can ask for a cert signed with it for their own use.

Ah ok, since you mentioned IoT I assumed the device would not be able to use a self signed CA cert. I've seen a few platforms made to automate self signed certs, and DogTag was one of them. I think that was deprecated. It looks like this person made a self hosted ACME server [1] and some discussion on LetsEncrypt [2] about it.

[1] - https://smallstep.com/blog/private-acme-server/

[2] - https://community.letsencrypt.org/t/private-acme-server-in-o...

I think you're still missing the intent, so I'll go through it in small pieces.

- Service starts up, makes itself a CA cert signed by itself.

- IoT device starts up.

- IoT device says to service, "please may I have a HTTPS certificate?"

- Service makes a HTTPS certificate, and signs it using the CA that it made, above.

- Service replies "yes you may have a HTTPS certificate and here it is"

Later, in the browser:

- user visits https://iotdevice.lan/ which is the public page for the IoT device

- browser says, "oh hey, this is on a LAN IP"

- browser says to service, "please may I have a copy of your CA cert?"

- Service says "sure here is a copy of my CA cert"

- Browser installs it as a trust root for the LAN only

- Browser sets up a HTTPS connection to https://iotdevice.lan/

- The connection is successful because it presented a HTTPS certificate signed by one of the browser's trust roots

What bootstraps all of the steps that talk to this service? DHCP + wpc_url in DHCP options? How would the IoT and the browser know about this service and make use of it? If it's manual steps, then the self hosted ACME service should suffice. If you need the IoT and browser to just figure this out, then all IoT's and browsers would need some form of service discovery. ssdp, dhcp+wpad_url, etc... or captive portal perhaps for wifi. Even then we are talking about amendments to RFC's and getting everyone to adopt this.

I'm presuming there's some standard way to discover this service, like it's on a standard broadcast address.

Yes, it would need to be supported by browsers.

some standard way

Browsers and IoT today have no standard way to do this today aside from corporate managed workstations like active directory policies. The mechanisms could include broadcast packets like ssdp, or DHCP options with some mangled use of wpad_url, but the browsers and IoT today don't have such a mechanism for certs. So it will be on you or a team you build to write the RFC's for this, create standard client libraries that can be used in IoT and browsers, then get everyone to adopt them. Maybe a smaller baby-step would be to see if there is a way to write the client as a browser addon. Assuming this is even possible with the sandboxing of addons today, if it became popular enough, maybe browser vendors would uptake your code as a standard function in the browser. IoT manufacturers are all over the board on standards and seldom agree on one thing. Maybe you could start with high end enterprise IoT devices that live on corporate networks. Some generic IoT devices today work around this by just accepting any cert but you can't predict what devices will do this.

Reply on news.ycombinator.com