Should you use Let's Encrypt for internal hostnames? • Hacker News Board

Re: Should you use Let's Encrypt for internal hostnames?

#181

Post by mac-chaffee » Thu, Jan 06, 2022, 3:56 AM UTC

toddnni wrote: post #157

Maybe a dump question, but was it so, that it is not only Let's Encrypt that uses Certificate Transparency Log, but all the other providers too? If so, then the decision is more like, whether to use a public or private certificate for an internal service.

Yep, we recently moved from DigiCert to LE and someone was alarmed at the certificate transparency logs, until we scrolled down the page to reveal the same logs from DigiCert.

Wildcards hide it somewhat, but DigiCert charges per subdomain now, and every user thinks they need their own subdomain for some reason. So LE it is.

Re: Should you use Let's Encrypt for internal hostnames?

#182

Post by SturgeonsLaw » Thu, Jan 06, 2022, 6:41 AM UTC

tomlx wrote: post #178

KronisLV wrote: post #169

Earlier quoted context omitted.

> Several comments here mention running your own CA. You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/ In comparison, have a look at…

I never got why people think using tar is hard. Specify your archive File with f. want to eXtract it? add a x. want to Create it? add a c. Want it to be Verbose while doing that? add a v. if it's gZiped add a z. Granted, j for bzip2, t for listing is less obvious, but with that it's about everything you need for everyday usage and that more than suffices to disarm that bomb.

tar -xzvf filename.tar.gz

The mnemonic I use:

x - extract

z - ze

v - vucking

f - files

Re: Should you use Let's Encrypt for internal hostnames?

#183

Post by rswail » Thu, Jan 06, 2022, 7:18 AM UTC

So people seem to be conflating the requirements of a CA (the thing that signs certificates and is considered the authority) and an RA (the registration authority).

Running a CA that issues certificates isn't that hard. There are off-the-shelf solutions and wraparounds for openssl as well.

Running an RA is hard. That's the part that has to check who is asking for a certificate and whether they're authorized to get one and what the certificate restrictions etc are.

Then there's the infrastructure issue on the TLS users (clients & servers) that need to have the internally trusted root of the CA installed and need the RA client software to automagically request and install the necessary leaf and chain certificates.

AWS has private CAs for $400/month, but if you want a root and then some signing intermediates, that's $400 for each (effectively the PCA is just a key stored in an AWS HSM and an API for issuing certificates).

A real HSM will cost roughly a year of that service, but the management of that hardware and protecting it and all the rigmarole around it is very expensive.

Every mobile phone and most desktops have a TPM that could be used for this, but having an API to access it in a standard way isn't that available.

Re: Should you use Let's Encrypt for internal hostnames?

#184

Post by KronisLV » Thu, Jan 06, 2022, 7:54 AM UTC

tomlx wrote: post #178

KronisLV wrote: post #169

Earlier quoted context omitted.

> Several comments here mention running your own CA. You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/ In comparison, have a look at…

I never got why people think using tar is hard. Specify your archive File with f. want to eXtract it? add a x. want to Create it? add a c. Want it to be Verbose while doing that? add a v. if it's gZiped add a z. Granted, j for bzip2, t for listing is less obvious, but with that it's about everything you need for everyday usage and that more than suffices to disarm that bomb.

Here's an example of better UX (subjectively):

  zip my-archive.zip my-directory
  unzip my-archive.zip

(disclaimer: zip/unzip won't be a reasonable alternative for all of the use cases of tar)

Good software doesn't beg that much explanation. And when it does, then either "--help" or just the command with no parameters e.g. "zip" or "unzip" should provide what's necessary. I don't believe that tar does that, but instead overwhelms the user, whereas "tar --usage" is overwhelming.

Here's another comment of mine which serves a precise example of why tar is problematic in my eyes: https://news.ycombinator.com/item?id=29339018

I don't feel like it follows the UNIX philosophy that well either, though i won't argue that it should be much smaller (because it is powerful, although someone might argue that), but that its commands should be grouped better.

That said, maybe things would be more tolerable if we used the full parameters instead of memorizing silly mnemonics, here's an excerpt from the linked comment:

  $ tar --verbose --create --gzip --file=new-archive.tar.gz ./files-i-want-to-archive

Re: Should you use Let's Encrypt for internal hostnames?

#185

Post by nickf » Thu, Jan 06, 2022, 8:34 AM UTC

mmalone wrote: post #173

nickf wrote: post #147

Earlier quoted context omitted.

Wish it were as simple - ultimately having a name-constrained and publicly-trusted CA is the same as having any publicly-trusted CA and comes with a ton of wonderful burdens like audits. You're essentially running a public CA at that point, and that isn't easy.

This is not a technical limitation though. It's a policy limitation. In theory, a name-constrained intermediate for `.example.com` has no more authority and poses no greater risk than a wildcard leaf certificate for `.example.com`. In both cases the private key can be used to authenticate as any subdomain of `example.com`. But, name constraints are verified by relying parties (the clients and servers that are actuall…

CABF and root programs allow NC'd CAs - they're just a pain to operate.

The infra itself, keeping up with compliance and root program changes (which happen with more frequency now!), CT logging, running revocation services (not easy at scale). Plus then things to consider like rotation of the NC'd CA. You'd have to rotate at least once a year, perhaps less given domain validation validity periods. You'd also likely need to have the chain ('chain' used loosely, we know it's not really a linear chain) be four deep like: root->CA->your NC'd CA->leaf, 'cos the root should be offline and unless you're not doing these in much volume I assume you'd want to automate issuance and not gather your quorum of folk to sign from the offline roots. That might not be an issue for many, but it certainly is for some.

(Full disclosure, I work for a CA for almost 2 decades and have pretty intimate knowledge in this area, sadly).

Re: Should you use Let's Encrypt for internal hostnames?

#186

Post by dolmen » Thu, Jan 06, 2022, 9:28 AM UTC

mojzu wrote: post #35

meepmorp wrote: post #2

I've used https://smallstep.com/docs/step-ca/ as a CA internally, works well.

I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses

Tailscale+TLS: isn't it two strong layers of encryption?

Re: Should you use Let's Encrypt for internal hostnames?

#187

Post by quicksilver03 » Thu, Jan 06, 2022, 9:41 AM UTC

mcgeez wrote: post #37

I like the wildcard certificates option, however I have not been able to find an easy solution to distribute those certificates to every host I have internally. Is this usually done manually? is there some equivalent to acme.sh? The kind of hosts I have are OPNSense router, traefik servers, unifi controller etc.

At my last job I implemented the certificate generation as a scheduled job, which pushes the generated certificates to a private S3 bucket.

Then, our standard Ansible playbooks set up on each node a weekly systemd timer which downloads the needed certificates and restarts or reloads the services.

Re: Should you use Let's Encrypt for internal hostnames?

#188

Post by eternityforest » Thu, Jan 06, 2022, 11:38 AM UTC

I just finished writing a long proposal: https://github.com/WICG/proposals/issues/43

PKI is fairly awful and bad for internal anything, unless you have a full IT team and infrastructure.

A much simpler solution would be URLs with embedded public keys, with an optional discover and pair mechanism.

Browsers already have managed profiles. Just set them up with a trusted set of "paired" servers and labels, push the configs with ansible(It's just like an old school hosts file!), and don't let them pair with anything new.

If you have a small company of people you trust(probably a bad plan!), or are a home user, just use discovery. No more downloading an app to set up a smart device.

The protocol as I sketched it out(and actually prototyped a version of) provides some extra layers of security, you can't connect unless you already know the URL, or discovery is on and you see it on the same LAN.

We could finally stop talking to our routers and printers via plaintext on the LAN and encrypt everywhere.

We already use exactly this kind of scheme to secure our keyboards and mice, with discovery in open air not even requiring being on the same LAN.

We type our sensitive info into Google docs shared with an "anyone with this URL" feature.

It seems we already trust opaque random URLs and pairing quite a bit. So why not trust them more than the terrible plaintext LAN services we use now?

Re: Should you use Let's Encrypt for internal hostnames?

#189

Post by mojzu » Thu, Jan 06, 2022, 12:39 PM UTC

dolmen wrote: post #186

mojzu wrote: post #35

Earlier quoted context omitted.

I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses

Tailscale+TLS: isn't it two strong layers of encryption?

Yeah, it's probably overkill but I think the multiple layers would help in cases I misconfigured something or if an account someone uses to log into Tailscale was compromised. For example when I ran the containers on a linux host I discovered later docker was bypassing the firewall rules and allowing all connections, but it probably wasn't a big deal because of the MTLS (and the server was behind a NAT router anyway so it was only addressable within the local network)

Re: Should you use Let's Encrypt for internal hostnames?

#190

Post by southerntofu » Thu, Jan 06, 2022, 12:54 PM UTC

So the problem is our naming scheme is insecure so we ask untrustworthy 3rd-party entities to vet our certificates. The CA mafia isn't gonna give up their hard-earned monopoly easily (remember CACert?), and most client companies are happy to have for-profit CAs for insurance/policy compliance. Something like DNSSEC+DANE[0] is more reasonable but unfortunately unsupported by most programs.

[0] https://datatracker.ietf.org/doc/html/rfc6698