3 ms·

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 i

by buu700 9y ago

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.

Ajedi32 9y ago
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.)
- buu700 9y ago
  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.

by buu700 9y ago

Ajedi32 9y ago

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.)

buu700 9y ago
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.