Hacker News Reader

Comment by kardos | Hacker News Reader

Re: HPKP suicide, why not pin a handful of 'recovery' keys that you can use when things go sour? Stored off-server or offline so in the hack scenario you don't lose them.

View on HN

Having multiple backup keys doesn't really provide much benefit beyond having 2 well protected backups. Most of the same risks still exist like the minimum key size changing.

In a "hack scenario" theoretically everything can be compromised.

Sure, in theory. Realistically though, I think any scenario that involves compromising both the production server _and_ a USB drive locked in a safe is pretty unlikely.

The interesting bit about RansomPKP is that it works independent of whether your HPKP pinning strategy is sound. In fact, it works even if you don't use HPKP at all. All the attacker needs is the ability to modify your HTTP headers and to either have access to your existing private key, or the ability to change the private key to one under their control. From that point on, it's all about how long it'll take you to notice the modified header. If it's live long enough for a sufficiently large percentage of your visitors to hit the site, the damage is done.

One thing to take away from this is that RansomPKP is not so much an argument you can use when deciding whether you should deploy HPKP for a particular site, but rather something that's relevant for deciding whether browsers should continue to support HPKP in its current form at all. I could see how a couple of large RansomPKP cases could very well cause a change on that front.

Actually, more than just being independent of your pinning strategy, one of the partial mitigations that Bryant (@eganist) and I recommended when introducing RansomPKP was to enable HPKP, since it would both block existing users of the target site from pinning the new malicious headers and cause alarm bells to be set off early.

Like you said, RansomPKP is more impactful to the ecosystem-wide decision of whether HPKP should exist than to whether an individual should use it (given the precondition that it exists). That said, malicious pinning was explicitly discussed and noted as a concern during the standardization process, so RansomPKP doesn't add much to that ecosystem-wide decision; it's just a fun application of HPKP Suicide that takes the core malicious pinning idea to a logical conclusion, and isn't even necessarily the worst way to abuse a compromised web server. There are also much more positive applications of HPKP Suicide, e.g. my startup Cyph's in-browser code signing layer.

Anyway, I wouldn't use any of this to argue against the very existence of HPKP, but I agree with Scott removing it from a tool that at least partially targets non-experts.

> one of the partial mitigations that Bryant (@eganist) and I recommended when introducing RansomPKP was to enable HPKP, since it would both block existing users of the target site from pinning the new malicious headers[...]

Huh? How? If the header changes, don't browsers automatically update their pins next time the user visits that page?

> [...]and cause alarm bells to be set off early

I don't get this either. If an attacker enabling HPKP wouldn't set off any alarm bells, why would changing an existing HPKP header do that?

At the time, if I recall correctly, we'd tested both Chrome and Firefox and confirmed that any HPKP header that didn't match the key currently in use would be ignored. Because of this, the only way we could see to replace an existing pinned key would have been to remove or replace the existing header and keep that change intact for the duration of the header's max age while remaining undetected the whole time (which would be unlikely when faced with a competent InfoSec team, as you implied).

As far as early alarm bells, sorry, that was a bit vague. I was referring to not just ambiguous warning signs that would be caught by careful monitoring, but the inevitable stream of reports from end users about the big scary TLS pinning error screen in the browser, should the attacker decide to immediately push out the malicious keys/headers without waiting out the old ones' expiry.

Ah okay, I see what you're saying. If the HPKP header is set, the attacker can't transition the server over to using a new key the attacker controls until _after_ the max-age expires, otherwise they'd risk tipping their hand when users who still have the old set of keys pinned start getting key pinning errors and complaining to the site owner. (And they can't remove the original key from the set of pinned keys until after they make that transition, since key pinning headers that don't include the key you're currently using are ignored.)

Yep, that's exactly it. There are a bunch of possible permutations/optimizations, like initially keeping the original header with the max age changed to 1 for a shorter period of time (until you're confident that the number of user reports will be small enough not to get on anyone important's radar before it's too late, and/or maybe you have some more complicated logic to track which clients do and don't have the altered header); but in any case the general point we made in the talk was just that enabling HPKP (among a few other things) was a net positive if you were worried about getting hit by RansomPKP today, not that it would entirely prevent the attack.

If your service is down, there's nothing to hack anyways.

Reply on news.ycombinator.com