What is HTTP Public Key Pinning [HPKP]?

What is HTTP Public Key Pinning?

HTTP Public Key Pinning (HPKP) is a security feature built to protect websites from man-in-the-middle (MITM) attacks of a mis issued certificate. HPKP enables administrators to specify which cryptographic public keys are trusted for a particular domain.

Also, HPKP prevents browsers from accepting certificates that were not issued via a trusted Certificate Authority (CA).

HPKP originated in 2015 with Google’s announcement and was introduced to improve SSL/TLS security so that websites could no longer impersonate themselves due to misissued certificates from rogue or compromised CAs.

The essence of HPKP was that web browsers would only accept pre-approved certificates with the correct public keys, thus reducing the risk that attackers would obtain fraudulent certificates and be able to intercept traffic between the website and its users.

Even though HPKP was designed to provide security, there were numerous challenges with its implementation, as well as security risks, which ultimately led to its deprecation.

What happened to HPKP?

Complicated Setup and Configuration

The largest problem with HPKP was its complicated infrastructure. For example, HPKP required that website administrators properly generate, manage, and configure public key pin sets; this was not straightforward and required pin sets to be properly coordinated with their respective SSL/TLS certificates.

Potential for Hostile Pinning Attacks

One of the serious problems with HPKP was that it was susceptible to hostile pinning attacks. If an adversary obtains a mis-issued certificate from a compromised Certificate Authority (CA) and pins their public keys to a domain, it may permanently lock the legitimate owner out of their own site.

HPKP does not supply a built-in recovery method and therefore there is no easy way to unpin a maliciously pinned key recovery, leaving domain owners in a very difficult position.

While there have been no reliable instances of hostile pinning attacks, the risk was enough for many companies to consider HPKP as unacceptably risky.

Difficulty in Key-set Lifecycle Management

HPKP introduces a challenge to effectively pin cryptographic keys, which stems from the dynamic state of the SSL/TLS landscape.

Sites often change the CA(s) that supply their certificates or update their SSL certificates more frequently creating a struggle for the domain owner to manage changes.

If a site does not properly rotate backup keys, the result is a state of permanent inaccessibility as a result of key pinning with non-current or incorrectly matched pins.

This makes HPKP a brittle security mechanism since key-pinning will simply break during expected services associated with the certificate lifecycle.

Limited Compatibility and Adoption of Browsers

From the beginning, HPKP suffered low adoption due to limited support from the browsers. Google introduced HPKP as part of its Chrome browser in 2015, but only Chrome and Opera fully supported the feature.

Mozilla’s (Firefox) not fully implementing it and Apple (Safari) and Microsoft (Edge/Internet Explorer) not even attempting to support HPKP meant it never gained significant trustworthy adoption in the industry.

As only a small percentage of sites were using it, Google ultimately determined it was no longer a worthwhile effort to continue support for HPKP especially since safer alternatives were available.

Google Deprecates HTTP Public Key Pinning (HPKP)

Google officially deprecated HPKP when they released Chrome 67 in May of 2018, down a path of absolute deprivation due to the lack of adoption, risks of misconfiguration, and better security mechanisms.

Instead, Google encouraged website owners to utilize Expect-CT, Certificate Transparency Logs, and CAA records for better security without the risk of breaking websites permanently.

How Does HTTP Public Key Pinning Work?

HTTP Public Key Pinning (HPKP) permits owners of the website to dictate which specific cryptographic public keys should be trusted by web browsers in connecting to their site.

This process presents security from certificate misissuance and man-in-the-middle (MitM) attacks by implying to web browsers which keys to use for secure connections.

Specifying and Sending the HPKP Header

HPKP works by sending a special HTTP response header (Public-Key-Pins) back from the web server to the client (e.g., browser).

This header, or field, contains a list of public keys which represent trusted Certificate Authorities (CAs) or individual SSL/TLS certificates which are allowed to make connections.

The header also presents data called max-age, which is used by browsers to determine how long the public keys are allowed to be cached in the browser cache for future connections.

Example of an HPKP header:

Public-Key-Pins: pin-sha256=”Base64EncodedPublicKey1″;  pin-sha256=”Base64EncodedPublicKey2″; 

max-age=5184000; includeSubDomains; report-uri=”https://example.com/hpkp-report”

• pin-sha256: Specifies the SHA-256 hash of a trusted public key.
• max-age: Defines how long (in seconds) the browser should enforce key pinning (e.g., 60 days).
• includeSubDomains: Extends the pinning policy to all subdomains.
• report-uri: Sends violation reports to a specified endpoint when an invalid key is detected.

Storing the Pinned Public Keys in the Browser

When the user requests to visit a website with HPKP, the browser caches the pinned public keys for the specified max-age. Only the referenced pinned public keys and certificates can be used to connect to the site in the future.

If the site requests the browser to connect using a public key and no pinned public key is found, the browser will block the connection from proceeding.

Pinning Enforcement for Future Connections

The browser verifies whether the SSL certificate served by the server matches any of the pinned keys when a user revisits a website. If it does not match any pinned keys, the connection is blocked, prompting the browser to show the user a security warning.

This stops attackers from impersonating a website by using misissued or fraudulently obtained certificates.

Restorative Mechanism Using Back-up Pins

A pinned key may block access to a website permanently. Best practices therefore recommend including backup pins in the HPKP header. Backup pins indicate a second option when the original pin is not a valid option.

If a website fails to include a valid backup pin, the website may be completely locked out if the certificate is unexpectedly invalidated.

How Does HPKP Stop Impersonation Attacks?

Stopping Certificate Misissuance

HPKP played a critical role for the protection of websites in stopping impersonation attacks because it stopped certificate misissuance.

Certificate Authorities (CAs) were at times mistaken or even maliciously issued SSL/TLS certificates to unauthorized persons, enabling them to impersonate legitimate websites.

HPKP pinned a public key, which made it impossible to accept fraudulent certificates issued by CAs, in effect defining the public interface with degree of reliability.

Preventing Man-in-the-Middle (MITM) Attacks

A significant risk to online security is related to the concept of a man-in-the-middle (MITM). This is when an attacker interposes their device in the communications between a user and the site.

As originally conceived, HPKP provided a mechanism where browsers stored pinned public keys before establishing an encrypted connection and confirmed them before establishing an encrypted connection.

If an attacker attempted to inject a fake certificate into the communication process the Browser would have failed that pinning check and prevent an attacker from obtaining unauthorized access.

Without unauthorized access, the attacker cannot decrypt sensitive information and/or change sensitive information, protecting the confidentiality of that data and providing authentication for the user of the site.

Preserving Long-Term Security with max-age Directive

HPKP allowed a site owner to define a max-age directive that instructed a browser how long it must enforce key pinning.

After a browser received a key pinning header, the browser could remember the pinned keys and reject any certificate that did not match, regardless of whether it was relied on later.

This ensures, long-term, protection from impersonation attacks, as an attacker can not trick the user into accepting a fake certificate after the original certificate for the site has expired or been changed.

Protecting Against Rogue Sub-Certificate Authorities (sub-CAs) and Intermediates

Many Certificate Authorities (CAs) delegate the issuance of certificates to sub-CAs or intermediates that present a risk for mis- issuance of an unauthorized certificate.

HPKP mitigated this type of threat because it allowed a website owner to pin keys only from trusted keys, preventing an unauthorized or misconfigured sub-CA from issuing its own certificates that a web browser would accept.

Even if a sub-CA misissued a fraudulent certificate, it would not align with the pinned public keys stored in the user’s browser, which ensured that only permitted certificates could build a secure connection.

The Risks and Challenges of HPKP

Despite the strong security benefits, HPKP came with significant risks, which led to the revocation of this specification. One of the biggest issues with HPKP was ratifying a misconfiguration, which could permanently lock a website out of its domain.

A website owner could pin the wrong keys or simply lose access to the correct keys, preventing access to its own domain.

Additionally, hostile pinning via an unauthorized misissued certificate could suppress updates of legitimate key pinning as the attacker pinned his or her own key to a certificate.

These serious pitfalls permitted Expect-CT headers in combination with Certificate Transparency Logs to become preferred solutions to guard against impersonating attacks.

What are the Possible Dangers of HTTP Public Key Pinning?

Risk of Locking Out Users

One significant danger of HPKP was that, due to a misconfiguration, the existence of HPKP might lock users out of a website.

If a website pinned a public key improperly, or if the aligning private key was lost, browsers would reject future connections, even if the website subsequently acquired a valid cert.

In such scenarios, returning to a position of being able to access the website would virtually be impossible, and users would sometimes have to clear their browsing settings themselves just to remove the HPKP pin.

Due to this, many organizations have opted not to implement HPKP into their policies because it does not provide any way to recover from mistakes.

Hostile Pinning Attacks

With HPKP, there is also the danger of a possible attack (though it’s not obvious) called hostile pinning. In this attack, an attacker that had gained unauthorized access to a website could pin their own public key to it.

If the attacker, for instance, pinned their key using a mis-issued certificate, a legitimate owner would be locked out of the website and would be unable to issue a new valid certificate.

In this case, the website would not be functional (and the HPKP pin could make it unusable for a long time), which could be disastrous for a business or organization.

Since HPKP does not provide any means for recovery, such an event could cause delayed and definite consequences to a business as it would put a stop to connecting in a usable way the reputation companies have built through a crafty and automatic attack.

Difficulty and Risk of Misconfiguration

HPKP was hard to get correct because site operators had to choose reputable backup keys and manage this over a long period.

Many developers did not have experience in either key management or pin-set selection, which would only increase the chance of an accidental misconfiguration.

For example, if a pinned key expired or was replaced without updating the pin-set, the user was locked out of the site. The technical expertise and the chance for human error dissuaded many organizations from adopting HPKP across various industries.

Lack of Recovery Option

In contrast to modern mechanisms such as Expect-CT, the prior key pinning mechanism did not provide a built-in recovery option for incorrect pinning configurations.

If a website pinned the wrong key, or lost access to the private key, there was no reasonable process to revoke or sidestep the error.

That is to say, they had to be exceptionally careful with key management, or else the one mistake could result in UTD indefinitely until the max-age quota expired.

Issues of Compatibility with Certain Browsers and Clients

Not every web browser provides complete support for HPKP, meaning that while both Google Chrome and Opera implemented HPKP, Mozilla Firefox was never able to be fully implemented and Microsoft Edge and Apple Safari did not implement it at all.

This inconsistency in support meant that HPKP could never provide widespread capabilities for protection, making it a less than effective web security standard. It was ultimately the lack of widespread adoption that triggered its eventual deprecation.

What Are Some Alternatives to HPKP?

There are  few alternatives to HTTP Public Key Pinning (HPKP), but those alternatives provide safer and more practical security solutions.

Expect-CT not only enforces Certificate Transparency (CT) logs, but also detects misissued certificates without the threat of site lockout. Certificate Authority Authorization (CAA) allows domain owners to add specifics about which CAs can be trusted, or issue, certificates.

DNS-based Authentication of Named Entities (DANE) attaches a certificate to DNSSEC, making that trust more explicit.

Static certificate pinning is another alternative that is usually employed in mobile or desktop applications when absolutely necessary, and as a way to deter fraudulent certificates.

The alternatives provide better security and usability and renewal opportunities, explaining why HPKP is now deprecated.

Public Key Pinning vs Certificate Pinning

Feature	Public Key Pinning (HPKP)	Certificate Pinning
Definition	Enforces browsers to accept only specific public keys for a website.	Restricts applications or clients to accept only specific certificates.
Implementation	Implemented via HTTP headers in web browsers.	Hardcoded in mobile or desktop applications.
Flexibility	Less flexible; difficult to update pinned keys.	More flexible; allows updates through app updates.
Risk of Lockout	High; misconfiguration can permanently lock users out.	Lower; updates can be managed via app releases.
Security Mechanism	Protects against certificate misissuance by limiting allowed keys.	Prevents man-in-the-middle (MITM) attacks by trusting only specific certificates.
Ease of Use	Complex; requires manual key rotation and backup keys.	Easier; controlled by application developers.
Browser Support	Deprecated in Chrome, limited adoption in other browsers.	Used in apps and enterprise environments but not browsers.
Best Use Case	Previously used for website security (now replaced by Expect-CT).	Ideal for mobile apps, APIs, and enterprise software.
Recovery Mechanism	No built-in recovery; accidental misconfiguration is irreversible.	Can be updated via app updates or API changes.
Current Status	Deprecated by Google in 2018 due to security risks.	Still widely used in secure apps and closed environments.

Conclusion

Don’t put your website at risk—get Certera SSL to make it secure! Go to Certera and learn about cost-effective SSL solutions to secure your website from invaders. Take action today and secure your online future!