HTTP Public Key Pinning (HPKP) is a standard that allows a HTTPS website to specify which certificates it trusts, and instruct the browser not to allow any connection to that site that's secured by any other certificate.

Can this be used to facilitate a persistent denial-of-service attack on a website? Suppose an attacker compromises a website like cnn.com (say). It seems like the adversary could configure the webserver to enable HSTS and HPKP, with a pinning policy that specifies a certificate controlled by the attacker. The attack might be discovered and the legitimate administrators regain control, but everyone who visits cnn.com in the meantime will receive a HSTS and HPKP policy and their browser will cache it. As a result, their browser won't allow any HTTP connection to cnn.com (due to the HSTS policy) and will only allow HTTPS connections if the server uses the pinned certificate and public key. But since the attacker specified the pinned cert, it might be using a private key controlled by the attacker and not known to cnn.com. Consequently, after the attacker is kicked off, cnn.com has no way to terminate a SSL session using that attacker-chosen private key. So, all future connections from those browsers to cnn.com will fail.

The HPKP standard does suggest that browsers should set a maximum age for these policies, but it also suggests setting the maximum age to 60 days. So, if I'm understanding this correctly, it means that if an attacker temporarily compromises a website, then the attacker can ensure that the website will be absolutely unreachable for the next 60 days for all users who visit the website during the brief time when the website is compromised. Basically, any user who visits the website at a time when it is controlled by the attacker is "poisoned" for the next 60 days, and the website appears simply unreachable.

As website breaches are not unheard-of, this seems like it would be a rather severe outcome. This is a rather unusual sort of denial-of-service attack: it allows for irreversible vandalism of a site that there's nothing the website admins can do anything about, except to wait. the It also looks like this attack could be exploited against any website, even one that's not currently using HPKP, HSTS, or even HTTPS.

Have I understood this correctly? Are there any mitigations that a website can take to prevent itself from being DoS'ed in this way? Is there an argument that HPKP doesn't introduce any new DoS risk that's any more severe than what already existed before HPKP? Has this kind of persistent DoS attack ever been observed in the wild?

I've read RFC 7469, the standard that describes HPKP, and it doesn't seem to have any mitigation. It appears the attack I described would qualify as an instance of 'hostile pinning', but the standard doesn't seem to mention any useful mitigation for hostile pinning (apart from the max-age).

  • s/The HKPK standard does specify [...], but/The HKPK standard does not specify [...], but/ ? Commented Jul 6, 2015 at 6:15
  • I think this difficulty is a fundamental difference between HPKP and TACK. TACK uses "PIN Activation" to counter this. And one of TACK's authors (Trevor Perrin) thinks that this would be hard to add for HPKP. This was from 2013. I don't know if the technical details have changed. Perrin's mail to IETF:WEBSEC is here. Commented Jul 6, 2015 at 9:22
  • This threat is discussed in greater detail here: blog.qualys.com/ssllabs/2016/09/06/…
    – D.W.
    Commented Sep 12, 2016 at 2:57

1 Answer 1


Reading through this memo, a link is given to the un-pin draft of Perrin here. I see two countermeasures against the scenario which you describe in this draft:

Let's start with the first one, which can be interpreted in different ways:

Whenever a client performing "pin activation" sees a hostname and TSK combination not represented in the "pin activation" pin store, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days.

In my interpretation, the implementation of the above paragraph would mean that an attacker can only activate new pins for a very limited timespan. However, the attacker could still revoke older pins, it seems. Therefore, we move on to the second countermeasure described:

Nonrevokable tacks: A tack with generation 255 cannot be revoked. Such tacks MAY be used to minimize the risk that a compromised TSK private key could be used to affect site availability.

Thus, a server that has issued a non-revokable tack, could in fact keep using this tack forever. How I read that is that a server could create a key pair which is does NOT use, but for which it creates a non-revokable tack. (In Perrin's implementation, this would become one of the maximum of two PINs which cannot be deleted). In case the server is compromised, this key can be retrieved and used to undo the attacker's changes.

Whether or not this is implemented in current browsers, I don't know.

Edit: As @StackzOfZtuff pointed out in one of the comments, there is actually a transcript of an email conversation between IETF:WEBSEC and Perrin, pointing out to implement a TACK-like mechanism for HSTS.

  • I think you're talking about TACK, which AFAIK is a mechanism that directly competes with HPKP. Commented Jul 6, 2015 at 9:18
  • Possibly, but the idea could easily be reused for HPKP, and thus is a mitigation (if implemented of course).
    – Michael
    Commented Jul 6, 2015 at 9:20
  • Perrin said "No" in 2013 (see my comment to question). Commented Jul 6, 2015 at 9:28
  • @StackzOfZtuff Very interesting link, thanks. But where does he say no? I feel he says the contrary: it is possible, but requires some implementation.
    – Michael
    Commented Jul 6, 2015 at 11:40
  • My bad. You're right. Commented Jul 6, 2015 at 11:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .