What is HTTP Public Key Pinning (HPKP)?
HTTP Public Key Pinning (HPKP) is a security feature that allows HTTPS websites to resist impersonation by attackers using mis-issued or fraudulent certificates. It allows sites to specify (“pin”) which certificate authorities (CAs) are allowed to issue valid certificates for them, rather than accepting any certificate considered trustworthy by the browser settings.
Key Takeaways
- HPKP allows sites to specify which CAs can issue valid certificates for them, restricting impersonation.
- It prevents the use of mis-issued or fraudulent certificates not pinned by the site.
- HPKP pins the TLS certificate’s public key rather than the certificate itself.
- Browsers will reject connections to sites pinned by HPKP if the certificate is invalid per the pinset.
- Pins are set by the site via HTTP response headers and last for a defined period.
- HPKP can be risky if not implemented properly, as it can cause denial of service.
- HPKP has been deprecated in favor of Certificate Transparency and Expect-CT headers.
How Does HTTP Public Key Pinning Work?
With normal HTTPS connections, the browser decides whether the certificate presented by the server is valid based on the root and intermediate certificate authorities it trusts. This means that any trusted CA can issue a certificate impersonating any website if the private key for that CA is compromised.
HPKP prevents this by allowing sites to specify (“pin”) which CAs are allowed to vouch for their authenticity via public key hashes in an HTTP header. The browser will then reject any certificate for that site that does not match the pinned keys, even if it is signed by a browser-trusted CA. This restricts the CAs from issuing certs for that domain.
Specifically, the pins specify the Subject Public Key Information (SPKI) hash of the public key contained in the TLS certificate. HPKP validates the public key itself rather than the certificate.
The site specifies the pins via two HTTP response headers:
- Public-Key-Pins: Contains the pin specification
- Public-Key-Pins-Report-Only: Testing header before enforcing pins
Pin Specification
The Public-Key-Pins header specifies the pin in the form:
pin-sha256="<base64-encoded SPKI fingerprint>"; pin-sha256="<fingerprint>"; max-age=<expiration>
For example:
Public-Key-Pins:
pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=";
pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=";
max-age=5184000
This specifies two allowed SPKI pin hashes and that the pin is valid for 60 days (5184000 seconds). Multiple pins can be specified, usually for key rotation purposes.
The Report-Only header works identically, except browsers will report pin validation failures instead of rejecting connections. This allows testing before fully enforcing pins.
How Does HPKP Prevent Impersonation Attacks?
HPKP prevents impersonation by attackers who obtain fraudulent but browser-trusted certificates for a domain by restricting which keys can be used to vouch for authenticity.
For example, if an attacker gets a mis-issued certificate for “example.com” from a trusted CA:
- Without HPKP, the browser will trust this certificate due to the trusted CA signature.
- With HPKP, the browser will check that the public key in the certificate matches a pin specified by example.com. If not, the connection will be rejected.
This means only CAs possessing a private key corresponding to the public key pins can issue a certificate that will be accepted. All other CAs are prevented from impersonating the site, even if they are browser-trusted.
HPKP effectively allows sites to utilize their own PKI separated from the browser’s root programs. The pins specify the mapping between the site and authorized CA keys.
Why Pin Public Keys Instead of Certificates?
HPKP pins public key hashes rather than full certificate hashes. This is because pinning certificates would prevent sites from updating expired certificates.
By just pinning authorized public keys, sites can freely generate new certificates as long as they are signed by the private key corresponding to a pinned public key. The public key remains constant, while the wrapped certificate can change.
This allows rotation of auxiliary certificate contents like validity period while retaining the integrity of the key binding between the site and CA. The public key is the long-term indicator of an authorized certificate.
HPKP Usage Recommendations
HPKP can severely break the accessibility of sites if implemented incorrectly, so here are some usage recommendations:
- Use small max-age values like an hour when testing pins to limit damage from mistakes.
- Pin multiple keys to allow for key rotation and rollback if needed.
- Use the Report-Only header first and monitor errors before fully enforcing pins.
- Pin both your active certificate’s public key plus the public key of your offline root and intermediate CAs.
- Have mechanisms in place to deploy new pins and keys if existing ones are compromised.
- Use OCSP Must-Staple to mitigate potential issues with pinning only online CA keys.
- Consider other options like Certificate Transparency and Expect-CT as alternatives.
Proper pin hygiene is essential to avoiding availability issues. Regular monitoring and maintenance is necessary.
What Happens If an Incorrect Certificate is Used?
If a server attempts to use a certificate that does not match the pinned keys for that site, the browser will reject the connection, usually with an error like NET::ERR_CERT_INVALID.
This prevents the site from being accessed until a valid certificate is provided. Essentially, HPKP puts the site in a denied state if the pins are violated.
It is possible to specify report-only pins, where the browser will report the pin validation failure but still allow the connection. This can be used to test pins before fully enforcing them.
But generally, violating the pins will result in rejected connections until a certificate properly signed by a pinned CA key is deployed. This highlights the need for caution when implementing HPKP.
What Are Some Risks of HTTP Public Key Pinning?
Some risks and pitfalls to be aware of when using HPKP include:
- Key/Pin Errors: Pinning wrong keys, or bugs in pin deployment, can completely break access to a site.
- Inflexible Recovery: Revoking pins is difficult if you lose access to pinned keys or deploy incorrect pins.
- CA Compromise: If a pinned CA is compromised, pins may need to be updated, but this can be tricky if CA signatures are needed to deploy new pins.
- Performance Impacts: Increased handshake time due to additional pin validation.
- Interference with Traffic Interception: Causes issues with transparent middleboxes intercepting TLS.
- Server Authentication Breaks: Pins restrict CA flexibility, which can cause issues if server authentication behavior needs to change.
What Are Some Best Practices for Using HPKP?
Some best practices for using HTTP Public Key Pinning include:
- Start with short max-age values, like an hour, when testing to limit damage from mistakes.
- Use the Public-Key-Pins-Report-Only header first to monitor pin validation failures before enforcing.
- Pin your active certificate plus 2-3 spare keys to allow for rotation if needed.
- Have access to offline CA keys and tooling to issue new pins if operational keys are lost.
- Pin both leaf certificate keys and backing CA keys. Pin roots if not actively signing.
- Monitor pin reports and have automated rotation procedures.
- Evaluate risks and have contingency plans like pinset revocation schemes.
- Use OCSP Must-Staple as well to mitigate issues with CA availability.
- Consider alternatives like Certificate Transparency and Expect-CT.
What Happens When An HPKP Pin Expires?
The max-age value specified in HPKP pins defines their expiration timescale. Once pins expire, the browser will stop enforcing them and revert to normal public CA trust.
This means that after the max-age time has elapsed:
- The browser will stop checking certificates against the pinset.
- Any valid browser-trusted certificate will be accepted, not just pinned CAs.
- Attackers can potentially obtain new fraudulent certificates from trusted CAs.
To maintain protection, the site needs to deploy new pins before existing ones expire by sending fresh headers with an updated max-age.
If new pins are not deployed in time, it creates a window of opportunity for attackers between pin expiration and renewed pinning. Sites have to continually maintain pins via new deployments to avoid lapses in protection.
Some ways to help mitigate potential issues from expired pins include:
- Overlap pin lifetimes when rotating pins, so at least one remains valid.
- Monitor pin expiration dates and automate pin renewals.
- Use short max-age values of about a week during the initial deployment.
- Have mechanisms to manually upload new pins if automation fails.
- Include backup keys in pinsets to enable renewal even if some keys are lost.
What Happens If a Pinned CA’s Private Key is compromised?
If the private key corresponding to a pinned public CA key is compromised, attackers could use it to generate certificates for sites that pin that CA key. This undermines the security of HPKP.
To recover from a compromised CA, sites should:
- Revoke trust in the old pinned CA key by removing it from pinsets.
- Generate new keys and obtain a certificate from a non-compromised CA.
- Deploy new pins, including the new keys.
However, this process may be tricky if the compromised CA key is necessary to sign the HTTP headers used to convey new pinsets.
One mitigation is to include offline root or intermediate CA keys in your pins that are not used for active signing. These can still sign new pins if your online CA is compromised.
A compromised pin greatly highlights the need for agility in deploying updated pins if trust in a pinned key is lost. Having pinned backup keys and rotation procedures is critical.
How Does Certificate Transparency Compare to HPKP?
Certificate Transparency (CT) is an alternative technology that also aims to detect and prevent mistakenly issued certificates:
- Auditing: CT requires CAs to publish certificates to public logs for auditing purposes. Misissued certificates can be detected.
- Policy Enforcement: Web servers and browsers can require adherence to CT by CAs before accepting certificates.
- No Pins: CT does not use HPKP-style pinning. All browser-trusted CAs can issue certificates.
- Detect Issues: HPKP blocks while CT aims to detect. HPKP prevents specific CAs from being involved. CT allows identification after the fact.
- Deployment: CT is implemented on the CA side rather than by site operators like HPKP.
What Are the Differences Between HPKP and Expect-CT?
Expect-Certificate-Transparency (Expect-CT) is another HTTP header sites can use to enforce or audit CT participation:
- Audit Policy: Expect-CT can either audit CT compliance or enforce it like HPKP.
- No Pins: Expect CT to check the CT logs rather than pinning specific CAs.
- Broader Scope: Expect-CT applies CT policy to all certificates rather than specific domains like HPKP.
- Deployed by Site: Like HPKP, Expect-CT is implemented and managed by individual site operators.
- CA Implementation: CT itself is directly implemented by CAs, unlike Expect-CT and HPKP.
- Risk of Downtime: HPKP can risk site availability if misconfigured. Expect-CT cannot directly cause outages.
What Are Some Limitations of HPKP?
Some limitations to note regarding HTTP Public Key Pinning:
- Inflexible: It can be difficult to recover from incorrect pins or implementation mistakes.
- Manual Effort: Ongoing maintenance, like pin rotation, is required. Automation helps but is not foolproof.
- Denial of Service: HPKP can cause sites to go offline if misconfigured.
- Collateral Damage: Buggy pinsets can even take down sites that rely on the same CDN.
- Performance: Additional handshake delay for pin validation.
- Middleboxes: Can interfere with some TLS-intercepting middleboxes.
- Privacy Leaks: Pin errors can reveal user browsing behavior.
- CA Constraints: Pins constrain CA flexibility, such as cross-signing arrangements.
What Are Some Alternatives to HPKP?
Some alternative technologies and techniques to consider instead of or alongside HPKP:
- Certificate Transparency: Requires CAs to auditably log issued certificates to detect misissuance.
- Expect-CT: Allows site-specific policies to require/enforce CT compliance from CAs.
- OCSP Stapling: Requires real-time revocation checking, which helps mitigate issues if pinned CAs misbehave.
- Short-lived Certificates: Limit exposure from compromised CAs by frequently rotating certificates.
- Subresource Integrity: Prevents malicious JavaScript injection even if the site itself is compromised.
- Content Security Policy: Can restrict the origins of resources that are allowed to be restricted to prevent mixed content issues.
- CA/Browser Forum Policies: Require baseline practices like domain validation from trusted CAs.
Final Words
In summary, HTTP Public Key Pinning allows sites to restrict which certificate authorities can vouch for their authenticity by pinning authorized CA public keys. This can effectively mitigate impersonation threats from compromised CAs.
However, HPKP introduces availability risks if pins are mismanaged and require significant maintenance overhead. Safer alternative approaches like Certificate Transparency, which audibly logs all certificates, have emerged.
While HPKP can be highly effective if implemented meticulously, the risks and constraints ultimately led browser vendors to deprecate it in favor of more flexible options. Carefully layered defenses provide the best protection without the pins and pitfalls of HPKP.
Frequently Asked Questions about HTTP Public Key Pinning
What is HTTP Public Key Pinning (HPKP)?
HPKP is a security feature that allows sites to specify (“pin”) valid certificate authorities by their public key hashes. This restricts which CAs can vouch for the site’s authenticity, preventing impersonation by unauthorized certificates.
How does HPKP work?
Sites list authorized CA public key hashes in an HTTP response header. Browsers will reject certificates for that site unless signed by one of the pinned public keys. This overrides normal CA trust.
What risks does HPKP introduce?
MAIN risks are denying service if incorrect pins are set, and difficulty recovering from mistakes or compromised pinned keys. HPKP can completely break site availability if misused.
What are the best practices for using HPKP safely?
Use short expiration times, pin multiple keys, test with report-only mode, have backup pins and rotation procedures, and monitor closely. Have contingency plans to deploy new pins if old ones are lost.
What happens if a pinned key expires?
The browser will stop enforcing pin validation after the max-age time expires. This opens a window for potential impersonation until new pins are deployed. Sites must continually renew pins to maintain protection.
How does HPKP differ from Certificate Transparency?
CT requires CAs to audibly log all certificates to public logs. HPKP has sites pin specific CAs. CT detects misissuance after the fact. HPKP blocks using unauthorized CAs.
What is an alternative to HPKP?
Options like Certificate Transparency, Expect-CT, OCSP stapling, short-lived certs, CSP, SRI, and CA/Browser Forum policies can also help mitigate impersonation risks without issues of HPKP. Layered security is ideal.
Why has HPKP been deprecated?
Various challenges around inflexible recovery and high risks of denial of service led browser vendors to deprecate HPKP in favor of alternative approaches like Certificate Transparency.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
