Would it be possible for routers to run Let's Encrypt?

#discuss #networking #security

Would it be possible for routers to run Let's Encrypt? Should they? Connections to 192.168.1.1 should be secure too, especially if browsers are going to become more strict about TLS adoption.

Top comments (7)

Phil Ashby • Jun 24 '18

Good question, especially if widened to 'how do I secure services in my local private network?' The article @nektro links to below regarding localhost (letsencrypt.org/docs/certificates-...) provides a lot of good advice while making some assumptions that readers understand how certificates work, so let's recap those assumptions :)

Certificates enable encrypted communication, by containing and transporting the public key of an asymmetric key pair, with the private key being held by the service that needs to be encrypted. This is the bit provided by local software (eg: certbot), generating key pairs and building certificates from them to be used by services on the local system (eg: web server).
Certificates can also be part of a tree of trust, known as a public key infrastructure (PKI), that assures communicating parties are who they say they are. This is the bit provided by LetsEncrypt, who perform checks against services exposed on the public internet to assure that a claimed domain name is owned by the claimant, before digitally signing the claimants certificate. This signature can be checked by a client system receiving a certificate (eg: web browser) as having been signed by an already trusted entity (aka a trust root), in this case LetsEncrypt. Importantly this only works for public internet domains.

So what can we do for private networks? The LetsEncrypt article has a few suggestions, as does the ASUS article linked by @bgadrian with varying levels of hacky-ness vs. complexity:

Use public certificates (ASUS), give your local devices public internet names (and possibly make them accessible from the 'net). This breaks the 'private' bit in the question somewhat, and could be re-phrased as "don't run a private network" - hmmn.
Sign your own certificates (aka self-signed), usually at the point where they are generated: LetsEncrypt provide a sample openssl command for this. We get the encryption, but there is no tree of trust for client devices to check, so typically users will have to 'permit' or 'add an exception' to use a service with a self-signed certificate. The LetsEncrypt articles points out another risk here, where the self-signed certificate is manually added to the client as a root of trust to avoid unwanted user interaction, and frequently includes the private key as well as the public one - thus leaking private keys to users. Doh! This also becomes difficult to manage (it doesn't scale well) in larger environments.
Run your own certificate authority (aka CA), using freely available software (LetsEncrypt suggest minica), to sign all the certificates you use in your private network, while adding the CA's root certificate as a root of trust to client devices. This becomes more scalable at the cost of running a CA, but packages like minica make this reasonably easy. You typically find the IT services team in larger organisations do this already, including the local CA cert(s) in gold builds of operating systems used by the staff, so they can operate secure internal services (eg: webmail) easily. This is also how my organisation secures the internal networks of deployed products, typically using obviously private domain names like .local.

Hope this helps!

Meghan (she/her) • Jun 24 '18

Thanks for the amazing response!

Frederik 👨‍💻➡️🌐 Creemers • Jun 21 '18

I'm not really sure how that would work. The router would need to request an address for 192.168.1.1, but the LetsEncrypt servers would require proof that you own that address, but since it's a local address, they can't do a dns lookup, or send an http request to do the veriication.

Meghan (she/her) • Jun 21 '18

I've since seen here that they aren't able to produce certificates that aren't a part of public DNS. So names like localhost and 192.168.x.x are currently not possible for Let's Encrypt. Do you think they'll add this in the future? Or potentially create "global" certs that any service running on a local network could use?

Oliver Cole • Jun 24 '18

Breaking this down:
Do you think they'll add this in the future

How would you propose that Let's Encrypt validate my ownership of 192.168.1.1? They need to contact that IP address to check I own it - but their 192.168.1.1 doesn't refer to the same machine as mine.
Does that make sense?

Or potentially create "global" certs that any service running on a local network could use
So now, I open 192.168.1.1 in my browser, or let's say 10.45.214.12. I get back a valid Let's Encrypt TLS certificate for that IP. I'm certain that I'm talking to the machine on my LAN, or corporate WAN, with that IP address, right?
Not quite - how do I know someone hasn't rerouted the traffic to a machine they control - say some kind of hacker who already has a foothold in the network.
If Let's Encrypt publicly post private keys and certificates for all the private IP addresses in existence, I can never be sure if I'm talking to the machine I want to talk to, or another machine that happens to have the same private key downloaded from Let's Encrypt!