5 ms·

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

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?

LinuxBender 6y ago
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-private-network https://serverfault.com/questions/964119/enable-https-on-a-p... [2] - https://security.stackexchange.com/questions/103524/lets-encrypt-for-intranet-websites https://security.stackexchange.com/questions/103524/lets-enc... [3] - https://cabforum.org/internal-names/ https://cabforum.org/internal-names/
- JulianMorrison 6y ago
  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.
  - LinuxBender 6y ago
    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/ https://smallstep.com/blog/private-acme-server/ [2] - https://community.letsencrypt.org/t/private-acme-server-in-organisation/130755 https://community.letsencrypt.org/t/private-acme-server-in-o...
    - JulianMorrison 6y ago
      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/ 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/ https://iotdevice.lan/ - The connection is successful because it presented a HTTPS certificate signed by one of the browser's trust roots
      - LinuxBender 6y ago
        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.
thatha7777 6y ago
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.
- JulianMorrison 6y ago
  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.

LinuxBender 6y ago

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-private-network https://serverfault.com/questions/964119/enable-https-on-a-p... [2] - https://security.stackexchange.com/questions/103524/lets-encrypt-for-intranet-websites https://security.stackexchange.com/questions/103524/lets-enc... [3] - https://cabforum.org/internal-names/ https://cabforum.org/internal-names/

JulianMorrison 6y ago
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.
- LinuxBender 6y ago
  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/ https://smallstep.com/blog/private-acme-server/ [2] - https://community.letsencrypt.org/t/private-acme-server-in-organisation/130755 https://community.letsencrypt.org/t/private-acme-server-in-o...
  - JulianMorrison 6y ago
    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/ 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/ https://iotdevice.lan/ - The connection is successful because it presented a HTTPS certificate signed by one of the browser's trust roots
    - LinuxBender 6y ago
      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.

thatha7777 6y ago

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.

JulianMorrison 6y ago
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.