HTTP Public Key Pinning

HTTP Public Key Pinning
Name	HTTP Public Key Pinning
Introduced	2012
Deprecated	2018
Status	Deprecated
Type	Security header
Related	Transport Layer Security

HTTP Public Key Pinning HTTP Public Key Pinning was a web security mechanism introduced to allow website operators to reduce trust in Certificate Authorities by declaring which cryptographic public keys browsers should accept for a host. It created a policy communicated via an HTTP header that told user agents to remember one or more cryptographic public key hashes for a period of time, with the intent of preventing fraudulent certificates issued by compromised or misbehaving Comodo-type Certificate Authority incidents and similar attacks. The mechanism was standardized and implemented by several vendors before being deprecated due to operational risks and adoption challenges involving major actors such as Google and Mozilla.

Overview

HPKP was defined to bind a host to a set of cryptographic keys so that later TLS connections could be validated against those keys rather than solely against the Certificate Authority system overseen by entities like Symantec and DigiCert. The mechanism relied on an HTTP response header that included base64-encoded hashes of Subject Public Key Info, an expiration directive, and optional backup pins to be used during key rotation scenarios involving organizations such as Facebook and Twitter. Browsers like Chrome and Firefox implemented enforcement behavior influenced by ecosystem incidents involving Comodo and DigiNotar that underscored risks to the HTTPS trust model.

Technical Specification

The specification required inclusion of a header containing directives: one or more "pin-sha256" values representing hashed public key data, "max-age" for the pin lifetime, and optional "report-to" or "report-uri" directives for incident reporting. Pins targeted a public key as encoded in X.509 certificates used in TLS handshakes, which are published by Certification Authorities like Entrust or Let's Encrypt. The algorithm relied on SHA-256; implementations processed the header on successful TLS connections and stored pinsets keyed by origin. The spec permitted a "backup" pin to be held offline by administrators or organizations such as Microsoft or Amazon to enable recovery from key loss. Failure to present a certificate chain containing any pinned public key triggered a hard-fail for the origin, similar to behaviors deployed by Apple and other browser vendors during pin validation.

Deployment and Configuration

Operators configured HPKP by adding header directives in web servers such as Apache HTTP Server, Nginx, or platform services like Cloudflare and Akamai. Best practice advised pinning at the organizational level, rotating keys periodically, and maintaining offline backups for recovery to mitigate mistakes that affected entities like GitHub and HackerOne in hypothetical misconfigurations. Deployment also involved coordinating with Certificate Authorities such as GlobalSign and GoDaddy to ensure chained certificates would include the pinned public keys across issuance and renewal. Because the mechanism could render an origin inaccessible if misconfigured, many enterprises used staging environments and change-control processes similar to those practiced at PayPal and Bank of America.

Security Benefits and Risks

HPKP offered strong mitigation against CA compromise scenarios like those involving DigiNotar by ensuring that only known public keys could be used for an origin, thereby constraining fraudulent issuance by rogue CAs. It raised the barrier for nation-state actors seen in cases involving NSA-style interception to perform Man-in-the-Middle attacks without possessing the pinned keys. However, risks were substantial: accidental pinning of a transient key, loss of backup keys, or malice (a "pinning ransom") could permanently lock out legitimate site operators, echoing governance failures observed in large-scale outages at organizations such as Equifax. The hard-fail nature of enforcement created high operational cost and liability concerns for firms including Cisco and Oracle.

Incidents and Criticisms

Several high-profile debates involved browser vendors and platform operators about HPKP's safety; after incidents and community feedback, companies like Google opted to deprecate or limit the feature due to observed misconfiguration problems and potential for misuse against targets such as Wikipedia or Mozilla services. Security researchers from institutions including ENISA and universities published analyses showing that the combination of low adoption, high risk of unintentional lockout, and the possibility of attacker-induced "ransom" scenarios made the mechanism unfit for wide deployment. Critics compared HPKP's risks with the benefits achieved by Certificate Transparency logs promoted by Google and monitoring by organizations like CERT Coordination Center.

Alternatives and Successors

Following deprecation, the ecosystem converged on lower-risk options: Certificate Transparency, Expect-CT headers, and automated issuance via Let's Encrypt's ACME protocol combined with managed revocation and auditing by entities such as Google's Chrome team and Mozilla's CA program. Public Key Pinning in the form of static trust lists persisted in platform-level mechanisms like Android's Network Security Configuration and enterprise-managed Windows root stores, while runtime pin validation moved toward pin-like approaches implemented by content delivery providers such as Fastly and observability platforms at Datadog. These successors emphasize transparency, monitoring, and recovery pathways practiced by major vendors including IBM and Verizon.

Category:Computer security protocols