3 ms·

So, curious, what happens in the case that my private key is compromised? An attacker can then change my key pinning and prevent users from accessing my website

So, curious, what happens in the case that my private key is compromised? An attacker can then change my key pinning and prevent users from accessing my website? Heck, can an attacker already do this to many users simply by adding some headers and using their own SSL key? Seems a scary proposition, someone could effectively kidnap control of your domain and you'd have no way to get it back. Especially given the opposition to OCSP by certain parties and the fact that smaller sites have problems even getting on their alternative lists, it could be part of impossible to get your attacker's certificate removed from many of your users browsers.

pfg 11y ago
That's an interesting and scary attack I hadn't thought about before. HPKP headers should become part of security monitoring strategies to reduce the impact of such an attack, independent of whether a site actually uses HPKP or not.
mwpmaybe 11y ago
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]
nly 11y ago
I'm not sure if it is so, but I would hope browsers attach an expiry date to each hash, not each hash set, and that hashes can't be revoked simply by later omission. i.e. if you have keys A and B, and an attacker takes your domain and sets a header solely for the hashes of keys B and C, I would hope that you can still use a cert built using key A until the expiry.

pfg 11y ago

That's an interesting and scary attack I hadn't thought about before. HPKP headers should become part of security monitoring strategies to reduce the impact of such an attack, independent of whether a site actually uses HPKP or not.

mwpmaybe 11y ago

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]

nly 11y ago

I'm not sure if it is so, but I would hope browsers attach an expiry date to each hash, not each hash set, and that hashes can't be revoked simply by later omission. i.e. if you have keys A and B, and an attacker takes your domain and sets a header solely for the hashes of keys B and C, I would hope that you can still use a cert built using key A until the expiry.