Official HPKP support from Let's Encrypt

#1

I’d like to call upon Let’s Encrypt to publish the necessary values for their users to pin against their intermediate and root keys with a minimum time commitment for each.

Pinning against an intermediate and/or root key is much safer if done with assistance from the CA itself. Let’s Encrypt will have full visibility of all possible trust paths and advanced knowledge of events such as a change in the intermediate certificate (excluding a compromise scenario).

What I’d suggest is the pin value and a recommended max-age value for all intermediates and roots.

Let’s Encrypt Authority X3
pin-sha256=“YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=”; max-age=2592000

DST Root CA X3
pin-sha256=“Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=”; max-age=2592000

This will allow sites to benefit from the protection of HPKP with less risk and also reduce the administrative overhead of pinning their own keys exclusively whilst still affording a large level of protection. As a backup a site owner can pin their own backup key and/or the keys of another CA.

Thoughts and comments welcome!

#2

I would love to see official HPKP support, will be watching this thread.

#3

Agreed that this would be an useful addition to the documentation. The Chain of Trust page might be a good place for this, as it already contains a lot of related info.

I keep pondering on whether the values for the issuer certs should be included. Wondering what others think about this. The only upside to pinning to Let’s Encrypt Authority X3/X4 rather than the DST and ISRG roots would be that your pin would reject end-entity certs issued by other DST/IdenTrust intermediates. On the other hand it would mean that Let’s Encrypt would have to commit to some sort of policy regarding intermediate key rotation (as well as potentially cause more havoc in case of a compromise). You’d also end up with a relatively large set of pins at some point, especially if Let’s Encrypt adds the ability to issue from ECC keys (that would already put it at 4 plus at least one backup pin).

I feel like root-based pinning more closely reflects the design of ACME, which does not really give clients a whole lot of control over issuer certificate selection (or any long-term guarantees regarding those). Multi-trust-path-issues are easily addressed by pinning to both the DST and the ISRG root in Let’s Encrypt’s case. Care would have to be taken to ensure users don’t wrongly assume one of these two qualifies as a backup pin (no one else issues end-entity certificates to the general public from the DST root AFAIK, so Let’s Encrypt would effectively be a SPOF), but that should be doable with some warnings and a reference to the existing HPKP best practices thread.

#4

It would be useful if certbot simply creates and updates the HPKP pins in the configs.

it can also pre-generate the new private key and CSR which is used for the next renewal. This way HPKP works with certificates on the host and everything is working fine, because you don’t have to care about cross-signed certificates.

Has the down side that it results in case of dieing servers. But that’s not a problem of certbot it’s a problem of the people.

#5
  1. DST Root CA X3 ->
  2. IdenTrust Commercial Root CA 1 ->
  3. TrustID Server CA A52 ->
  4. 240 certificates

Only $99 a year for your verified organization! :wink:

#6

Good catch, missed that cross-sign. Good news for anyone only pinning to ISRG and DST, I guess. :wink:

#7

Tagging @jsha, who’s probably the right person to own this. We have a ticket for this against Certbot; we haven’t prioritized it yet because we’ve wanted our installer plugins to be out of beta before we’d support potentially dangerous security features like this.

#8

Here’s what we’ve said about this in the past: HPKP best practices

#9

I can see a value in HSTS being configured automatically but I’m not sure how Certbot could do HPKP with backups?

Anyway, to clarify, I would simply like the information to be available somewhere for HPKP and not be implemented in Certbot itself.

#10

One way to do backups is to write a backup key to disk somewhere, make the user promise they’ve backed it up off-system, then deploy that pin.

Another way would be to get the user to pick a different CA as their fallback CA.

#11

If a solution involves “make the user promise” then I’d never count it as a solution :wink:

I do like the idea of selecting other CAs but that requires their cooperation.

#12

We can probably talk some premium CAs into doing this, but it’s a cost risk for users :slight_smile:

As for making the user promise: we could make the user type “I promise I have already backed up /etc/letsencrypt/pins/FILE.pem”, or provide --promise-I-have-backed-up $FILE.

#13

(With an explanation about the potential consequences of lying, of course :))

#14

We also should really add ACME layer pinning support at the same time…

#15

It’s possible, but I’d guess the work to implement the feature balanced against how many people would use it would be a bad return. I think those who want to use it, like me, would be happy with just some assurance on the values and rolling it ourselves. I could also be completely wrong, it’d be interesting to see what others think.

#16

It’s part of the general objective of “removing all non-cryptographic attack surfaces from TLS”. I think a lot of people might want that feature if we support it in a fairly safe and convenient fashion.

#17

Thanks for posting about this. It’s something I’ve been thinking about a bunch, especially in relation to Symantec’s recent emergency issuance to a customer that had hardcoded a specific intermediate, which became obsolete.

I’d like to take the advice in HPKP best practices if you choose to implement and make it an official documentation page, but with similarly many caveats and warnings. I think if we did so, I would want to say “Let’s Encrypt does not officially support HPKP, but here’s how to do it in the safest way if you choose to.” As folks have pointed out here, safe HPKP deployment involves two important choices that require thought and care: Which two non-LE CAs are you going to pin, and how are you going to generate and safeguard your backup key? I think neither of those is amenable to copy-and-paste coding, and providing off-the-shelf hashes may encourage people to deploy HPKP unsafely and brick their site.

Peter, to your objective of “removing all non-cryptographic attack surfaces from TLS:” Do you mean from all TLS, for every web site? Or for a subset of sites? I think we should definitely scope it to the latter. The consequences of HPKP-bricking your site are so high that I can’t in good conscience recommend it for any site that isn’t meant to be high security.

BTW, @ScottHelme, your example suggests you’re pinning the intermediate, which the HPKP best practices post recommends against. The recommendation is pretty oblique, I admit. But in short: Pin the roots, plus your current end-entity, plus a backup, plus roots of two other CAs. Don’t pin intermediates, they can change without warning.

#18

@jsha yes I just mean, providing a set of tools and options that specific sites can use to remove non-cryptographic attack surfaces from their own websites (or eventually, other TLS-based services).

#19

HPKP-Support in certbot would be really nice. I’ve made a proposal for that some time ago regarding some sort of automated key archival system, basically pinning at server certificate level and storing some encrypted private keys for latter retrieval by an authorized admin should the need arise.

I know, uploading your private keys to the CA shouldn’t be something you do regularly, but that’s the best idea i had regarding HPKP.

My original post was here: Project Proposal: Automating HTTP Public Key Pinning

closed #20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.