9 ms·

> Imagine the impact on an HPKP site. I don't see why the impact on a site using HPKP would be different than for any other site. In both cases the site would

> Imagine the impact on an HPKP site. I don't see why the impact on a site using HPKP would be different than for any other site. In both cases the site would have to install a new cert. The only difference with the HPKP site is that they'd need to make sure their new cert uses the same key as the old one. (Or they could use a backup key/cert, which I'd expect them to have anyway if they're using HPKP.)

watbe 9y ago
Doesn't the max-age parameter[1] restrict a browser from accepting only those previously specified keys for a certain time frame? Therefor newly issued certificates should throw a warning. Otherwise it would be trivial for a MitM'ed sever to deliver their own key hash via a HPKP header. Or am I incorrectly understanding the value of the pinned hash? 1: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...
- Ajedi32 9y ago
  You're correct about the header. The part you're missing is that it's entirely possible for the site operator to get a new, unrevoked certificate that uses the same underlying private key issued to themselves by a different (or even the same) CA. Such a certificate would be accepted just fine by browsers which have that key pinned. HPKP pins public keys, not individual certificates.
  - watbe 9y ago
    Gotcha, I appreciate the explanation.
richardwhiuk 9y ago
Fairly sure that they'd be blocked from issuing a new cert with the same key?
- Ajedi32 9y ago
  You'd think so given that Symantec believes the key is compromised, but that's actually not the case. I actually saw a fairly interesting discussion about this over on the mozilla.dev.security.policy mailing list just the other day: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/71AXGTgcX9c https://groups.google.com/forum/#!topic/mozilla.dev.security...
  - hannob 9y ago
    However in that case it was Comodo that didn't block the compromised private key.
    - Ajedi32 9y ago
      Right. If you read the rest of the thread though you'll see that that's because they're not actually required to check. (Or at least, it's certainly arguable that they're not.) Any other CA could have done the same thing and that would be considered perfectly acceptable behavior per the Baseline Requirements.
      - hannob 9y ago
        I started the thread, I have read it :-)
- deleted 9y ago
  [deleted]

watbe 9y ago

Doesn't the max-age parameter[1] restrict a browser from accepting only those previously specified keys for a certain time frame? Therefor newly issued certificates should throw a warning. Otherwise it would be trivial for a MitM'ed sever to deliver their own key hash via a HPKP header. Or am I incorrectly understanding the value of the pinned hash? 1: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...

Ajedi32 9y ago
You're correct about the header. The part you're missing is that it's entirely possible for the site operator to get a new, unrevoked certificate that uses the same underlying private key issued to themselves by a different (or even the same) CA. Such a certificate would be accepted just fine by browsers which have that key pinned. HPKP pins public keys, not individual certificates.
- watbe 9y ago
  Gotcha, I appreciate the explanation.

richardwhiuk 9y ago

Fairly sure that they'd be blocked from issuing a new cert with the same key?

Ajedi32 9y ago
You'd think so given that Symantec believes the key is compromised, but that's actually not the case. I actually saw a fairly interesting discussion about this over on the mozilla.dev.security.policy mailing list just the other day: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/71AXGTgcX9c https://groups.google.com/forum/#!topic/mozilla.dev.security...
- hannob 9y ago
  However in that case it was Comodo that didn't block the compromised private key.
  - Ajedi32 9y ago
    Right. If you read the rest of the thread though you'll see that that's because they're not actually required to check. (Or at least, it's certainly arguable that they're not.) Any other CA could have done the same thing and that would be considered perfectly acceptable behavior per the Baseline Requirements.
    - hannob 9y ago
      I started the thread, I have read it :-)
deleted 9y ago
[deleted]