4 ms·

I would be interested in hearing someone smarter and more knowledgeable address this, but I will say that the public keys are sticky ("pinned"), so if an attack

I would be interested in hearing someone smarter and more knowledgeable address this, but I will say that the public keys are sticky ("pinned"), so if an attacker was able to change it, it would only affect virgin clients during the time the false header was present. Returning visitors would (presumably) not be able to load the site because the public keys they have cached for your site wouldn't match the false SSL certificate. Unless the attacker was playing a sneaky long game and only changed the backup public keys...

pfg 11y ago
If the private key is compromised or the HPKP header is changed through some other vulnerability in your site, the attacker could still satisfy the existing pin header. The attack for clients with cached pins would be a bit more involved and would have to be done in two steps¹: First visit: Add a new backup hash for a certificate that the attacker controls. Second visit: Use the new backup certificate for the TLS session and set a new HPKP header that excludes the keys the site owner actually uses. ¹ This is assuming browsers won't accept HPKP headers that don't pass for the current connection. I haven't actually checked this.
- TimWolla 11y ago
  > ¹ This is assuming browsers won't accept HPKP headers that don't pass for the current connection. I haven't actually checked this. RFC 7469 requires this (https://tools.ietf.org/html/rfc7469#section-2.5 https://tools.ietf.org/html/rfc7469#section-2.5): o The TLS connection was authenticated with a certificate chain containing at least one of the SPKI structures indicated by at least one of the given SPKI Fingerprints (see Section 2.6).
  - deleted 11y ago
    [deleted]