Hacker News Reader

Comment by Gasparila | Hacker News Reader

This article (and others I have read disliking HPKP) generally take an all or nothing approach. That is to say, they see HPKP as either "pin the key of my certificate" or "don't use HPKP at all"

In reality, you can have a valid HPKP setup as long as any keys in your certificate chain match the key in the HPKP header. This means that you can pin the intermediate certificate (or even the root CA if you want) key. By doing so, you are no longer vulnerable to losing your SSL keys, but now other CAs cannot issue certificates for your site

View on HN

No, you're wrong. There are no guarantees that you'd be able to get a fresh certificate from the same intermediate certificate. CAs rotate the intermediates all the time, for various reasons.

Of course, CAs can choose to make such guarantees ("the public key behind this intermediate will continue to be available for N years"), which would make the pinning much less dangerous.

That's why it's nice of Let's Encrypt to publish their current and backup intermediate CAs (X3 and X4) https://letsencrypt.org/certificates/. That's what I pin for my sites.

It's worth noting that Let's Encrypt makes no guarantees regarding the ability to sign under either key[1]. Both keys could be rotated without prior notice (though that would admittedly be unlikely unless there's an emergency).

[1]: https://community.letsencrypt.org/t/official-hpkp-support-fr...

For example, some kinds of HSM bugs might conceivably lead to issuing a new intermediate after an HSM software update (like if an HSM vendor said that it had concluded that its CSPRNG was seeded inadequately with fewer effective bits of entropy than the specifications required, or something).

In support of being cautious about predicting what intermediate will be used for issuance at a given time, there was also once a Let's Encrypt Authority X2 (also browser-trusted by virtue of being signed by IdenTrust's root), but issuance skipped directly from the X1 to the X3 intermediate in March 2016.

https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.p...

https://crt.sh/?Identity=%25&iCAID=7395

https://crt.sh/?Identity=%25&iCAID=16418

Barclays pinned to an intermediate. Here's what happened: https://cabforum.org/pipermail/public/2016-November/008989.h...

It worked out OK for Barclays in the end, but only because Symantec was willing to violate the Baseline Requirements to help them out. (I wonder how much that cost Barclays.)

Why did Symantec change the private key used for their intermediate certificate? It sounds like they switched from an older system to a newer one for issuing certificates, but that doesn't explain why they couldn't preserve the key.

Speculation: Possibly just because they didn't have to preserve it. Possibly because it was stored in a hardware module and could not be extracted.

Speculation: Symantec was not satisfied with the containment of the key. They might have preferred to rotate it out even though there is no evidence of key leakage if they knew there was a gap in their key access policy or audit processes. That gap might have been filled, so now they'd prefer to move on to a new key living under the new process.

Or you get N certificates from different sources, pin them all, use 1, stick the rest in (a) safe vault(s). Even if something really bad happens, you can use one of the other ones until you cycle. Cost of N certificates will be << money you'd lose otherwise, and likely a rounding error in any company's monthly spending. (if it's already live / trading)

HPKP is based on the public key, so you don't necessarily need to obtain signed certificates in advance - generating a key pair and keeping the private key safe would suffice.

There is some value in ensuring that a CA is willing to sign a certificate using those keys in case something went wrong during the key generation (i.e. a key size or curve that's not supported by the Web PKI), so it might be considered a best practice to do that regardless.

It's possible. But if you're in a disaster recovery situation, do you want to add the step of granting the certificate as well? Do people on call have access to the company credit card to get one?

It's easier to just get a full cert ahead of time.

The only safe way to try and do that would be to make sure that the max-age of your policy was never more than the remaining validity of your longest valid certificate.

There is a debate about which public key to pin, and I'm not sure it's settled. It depends on your priorities and the relative probabilities you put on various failure modes.

If you pin your public key, it's easy to switch CAs if the one you currently use goes under. This does happen.[1] But you are in trouble if you lose your key somehow.

If you pin your CA's public key, it's easy to recover from losing your key but you can't switch CAs until your pin expires. You could use the required second HPKP pin to add a fallback CA though.

I will note that this decision is not actually the hard part of deploying HPKP.

[1] https://blog.mozilla.org/security/2016/10/24/distrusting-new...

> You could use the required second HPKP pin to add a fallback CA though.

Or pin current CA + current pubkey? That way you can either change certificate within the current CA or use the current certificate to move to any new CA.

You should add one additional (CA|end-entity) pin regardless. If your key is compromised, there's a non-zero chance that you'll realize that your CA has stopped issuing certificates under the CA key you pinned at the same time. Most CAs aren't very transparent with regards to their root/intermediate lifecycles.

Well actually HPKP will not work if there is only one pin present. The browser will reject the entire header.

I had to double-check the RFC on this. The OP suggested pinning to "current CA + current pubkey", which would technically count as two pins and satisfy a simple "you'll need at least two pins" requirement. Luckily, the RFC authors realized that someone would try this and wrote it as "The given set of Pins contains at least one Pin that does NOT refer to an SPKI in the certificate chain.", meaning this pin would get rejected.

Yes, although they cannot make people backup the inactive pinned key they at least get them to think what they are doing.

In many of my articles I discuss the various ways to deploy HPKP including leaf pins, intermediate pins and root pins, or even a combination of different types of pin. They all come with various challenges and considerations that a site needs to consider.

Pinning the intermediate or root CA is actually more risky, since you have no control over it.

Reply on news.ycombinator.com