Hacker News Reader

Comment by mwpmaybe | Hacker News Reader

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

View on HN

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.

> ¹ 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):

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

Reply on news.ycombinator.com