Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you use Let's Encrypt for internal hostnames?

shkspr.mobi

Post reply on HN
Print view View original

191–198 of 198 posts

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

#191

Post by tptacek »

southerntofu wrote: post #190

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…

No, the reasoning here is broken. Even with a secure naming scheme, you'd still need certificates, because you have to verify the authenticity of the secure channel you bring up (usually TLS), not just the security of the name. Any way you slice it, you end up with a third party vouching for your TLS certificate.

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

#192

Post by southerntofu »

tptacek wrote: post #191
southerntofu wrote: post #190

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…

No, the reasoning here is broken. Even with a secure naming scheme, you'd still need certificates, because you have to verify the authenticity of the secure channel you bring up (usually TLS), not just the security of the name. Any way you slice it, you end up with a third party vouching for your TLS certificate.

In the case of DNSSEC keys are distributed with the zone, so the trust anchor is the DNS root. Of course, your parent zone could lie about your keys (just like it could lie about your other records), but don't you think since DNS is already an attractive attack vector (as it can vouch for CAs to publish a trusted certificate), relying on it exclusively for certificate distribution would reduce the overall attack surface?

I'm not saying no trusted parties is the end goal (though Tor's onion or the GNU Name System work in this area), but maybe giving dozens of corporations/institutes the power to impersonate your server (from a client UX perspective) isn't the best we can do.

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

#193

Post by tptacek »

southerntofu wrote: post #192
tptacek wrote: post #191

Earlier quoted context omitted.

No, the reasoning here is broken. Even with a secure naming scheme, you'd still need certificates, because you have to verify the authenticity of the secure channel you bring up (usually TLS), not just the security of the name. Any way you slice it, you end up with a third party vouching for your TLS certificate.

In the case of DNSSEC keys are distributed with the zone, so the trust anchor is the DNS root. Of course, your parent zone could lie about your keys (just like it could lie about your other records), but don't you think since DNS is already an attractive attack vector (as it can vouch for CAs to publish a trusted certificate), relying on it exclusively for certificate distribution would reduce the overall attack surf…

DNSSEC does the same thing (tradeoff: fewer corporations, but most of the important ones de jure controlled by governments, and no transparency logs†) --- you're just handing the CA role off to TLD operators.

To the extent DNS is an attractive attack vector, DNSSEC doesn't actually do much to mitigate those attacks. Most DNS corruption doesn't come from the on-the-wire cache corruption attacks DNSSEC was designed to address, but from attacks directly on registrars. There's nothing DNSSEC can do to mitigate those attacks, but not having CAs tied directly to DNS does mitigate them: it means the resultant misissued certificates are CT-logged.

If there was a huge difference in security from switching to DANE, this would be a different story. But in practice, the differences are marginal, and sometimes they're in the wrong direction.

Two really big things happened in the last decade that influenced the calculus here:

1. WebPKI certs are now reliably available free of charge, because of LetsEncrypt and the market pressures it created.

2. Chrome and Mozilla were unexpectedly successful at cleaning up the WebPKI, to the extent that some of the largest CAs were summarily executed for misissuance. That's not something people would have predicted in 2008! But WebPKI governance is now on its toes, in a way that DNS governance is unlikely ever to be.

(Cards on the table: I'd be a vocal opponent of DANE even if 1 & 2 weren't the case.)

† Not only is there no CT for DANE, but there's unlikely ever to be any --- CT was rolled out in the WebPKI under threat of delisting from Mozilla and Chrome's root cert programs, and that's not a threat you can make of DNS TLD operators.

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

#194

Post by infogulch »

nickf wrote: post #185
mmalone wrote: post #173

Earlier quoted context omitted.

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 n…

It's interesting to hear that there's already a NC protocol today, but most in this thread are aiming at "should" not "can". The point is that a 90-day, name-constrained CA has no more authority than 90-day wildcard cert if both are issued via DNS-01 validation (modulo nested subdomains), so it shouldn't be subject to the same regulations as a public CA with no restrictions (which require CT logging, audits, revocation services, security requirements, etc as you enumerated), or really any more restrictions than those necessary to be issued a wildcard cert. This would be very beneficial for private networks and would have even better security properties than wildcards. Is there any reason why this shouldn't be possible?

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

#195

Post by southerntofu »

tptacek wrote: post #193
southerntofu wrote: post #192

Earlier quoted context omitted.

In the case of DNSSEC keys are distributed with the zone, so the trust anchor is the DNS root. Of course, your parent zone could lie about your keys (just like it could lie about your other records), but don't you think since DNS is already an attractive attack vector (as it can vouch for CAs to publish a trusted certificate), relying on it exclusively for certificate distribution would reduce the overall attack surf…

DNSSEC does the same thing (tradeoff: fewer corporations, but most of the important ones de jure controlled by governments, and no transparency logs†) --- you're just handing the CA role off to TLD operators. To the extent DNS is an attractive attack vector, DNSSEC doesn't actually do much to mitigate those attacks. Most DNS corruption doesn't come from the on-the-wire cache corruption attacks DNSSEC was designed to…

> not having CAs tied directly to DNS does mitigate them: it means the resultant misissued certificates are CT-logged. (...) Not only is there no CT for DANE, but there's unlikely ever to be any

Since DNS is public data that anyone can archive, isn't it easy to build a CT log from that for a list of domains? I mean regularly probing for DANE records on your domains can be done fairly easily in a CRON job. I'm personally very skeptical to trust CT logs from CAs in the first place and would much rather welcome a publicly-auditable/reproducible system.

> (Cards on the table: I'd be a vocal opponent of DANE even if 1 & 2 weren't the case.)

Why and what's the alternative? Is your personal recommendation to use a specific CA you trust over all the others and setup CAA records on your domain? Otherwise i believe DNS remains a single point of failure and hijacking it would make it easy to obtain a certificate for your server from pretty much any CA, so i don't see any security benefits, but i do see the downside that any CA can be compelled (by legal or physical threat) to produce a trusted certificate for a certain domain which of course could be said of TLD operators as well, but i believe reducing the number of critical operators your security relies on is always a good thing.

If you have a link to a more detailed read on your thoughts on this topic, i'd be happy to read some lengthier arguments.

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

#196

Post by tptacek »

southerntofu wrote: post #195
tptacek wrote: post #193

Earlier quoted context omitted.

DNSSEC does the same thing (tradeoff: fewer corporations, but most of the important ones de jure controlled by governments, and no transparency logs†) --- you're just handing the CA role off to TLD operators. To the extent DNS is an attractive attack vector, DNSSEC doesn't actually do much to mitigate those attacks. Most DNS corruption doesn't come from the on-the-wire cache corruption attacks DNSSEC was designed to…

> not having CAs tied directly to DNS does mitigate them: it means the resultant misissued certificates are CT-logged. (...) Not only is there no CT for DANE, but there's unlikely ever to be any Since DNS is public data that anyone can archive, isn't it easy to build a CT log from that for a list of domains? I mean regularly probing for DANE records on your domains can be done fairly easily in a CRON job. I'm persona…

The premise of certificate transparency is that the CAs themselves (generally) submit certificates to be logged. CAs generate pre-certificates, which are signed by CT logs, generating SCTs, which accompany the certificate in the TLS handshake. The SCT is a promise from a CT log (not the CA) that the cert has been recorded; the CT logs themselves are cryptographically append-only. The system is designed not to simply trust the CA to log.

You can't replicate that clientside by monitoring domains. A malicious authority server can feed different data selectively.

Could you replicate this system in the DNS? Well, it'd be impossible to do it with DNSSEC writ large (because there's no way to deliver SCTs to DNS clients), but you could do it with extensions (that don't exist) to DANE itself, and tie it into the TLS protocol. But that system would require the cooperation of all the TLD operators, and they have no incentive to comply --- just like the commercial CAs didn't, until Mozilla threatened to remove them from the root certificate program unless they did. But Mozilla can't threaten to remove .COM from the DNS.

So, no, the situations aren't comparable, even if you stipulate that DANE advocates could theoretically design something.

I'm hesitant to answer the second question you pose at length, because you have some misconceptions about how CT works, and so we're not on the same page about the level of transparency that exists today.

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

#197

Post by tatersolid »

0xbadcafebee wrote: post #100

Running your own private CA is a great way to cause problems for yourself down the road (just ask anyone with a 5 year and 1 day old Kubernetes cluster). But I also don't want to be dependent on a 3rd party for my internal services. I want a better solution: not as annoying as a private CA, and not dependent on 3rd parties. I want to deploy apps that use certs that don't expire. When they should be rotated, I want to…

> Security is not more important than reliability.

Yes, it is. In most cases Confidentially > Integrity > Availability. Systems should fail-safe.

There are some scenarios such as medical devices where integrity or availability trump confidentiality. But most information systems should favor going offline to prevent a breach of confidentiality or data integrity.

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

#198

Post by flatiron »

throw0101a wrote: post #114
infogulch wrote: post #57

Earlier quoted context omitted.

Maintaining golden container/vm images with root cert customizations is a pretty complex task that needs constant maintenance and customizations for new runtimes. Also this does nothing for unofficial devices (byo laptops, byod smartphones, ceo's ipad, guest laptops).

> Maintaining golden container/vm images […] I was under the impression that 'golden images' aren't generally encouraged as a Best Practice™ nowadays. The general momentum seems to me to be use a vendor-default install image (partitioning however you want), and then go in with a configuration management system once it's on the network. Basically: you keep your config 'recipes' up-to-date, not your image(s).

at least at apple the dockerfile for their images were < 50 lines. Like super tweaks on the AL2 image. Every 60 days you need to pull it in. So you are right they just keep it up-to-date and keep it to the vendor images as well.
Post reply on HN