4 ms·
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
by 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]