HTTP Public Key Pinning

HTTP Public Key Pinning (HPKP),^[1] sometimes incorrectly known as certificate pinning, is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates.

For example, attackers might compromise a certificate authority, and then mis-issue certificates for a web origin. To combat this risk, the HTTPS web server serves a list of “pinned” public key hashes; on subsequent connections clients expect that server to use one or more of those public keys in its certificate chain.

How It Works

The server communicates the HPKP policy to the user agent via an HTTP response header field named Public-Key-Pins (or Public-Key-Pins-Report-Only for reporting-only purposes).

The HPKP policy specifies hashes of the subject public key info of one of the certificates in the website's authentic X.509 public key certificate chain (and at least one backup key) in pin-sha256 directives, and a period of time during which the user agent shall enforce public key pinning in max-age directive, optional includeSubDomains directive to include all subdomains (of the domain that sent the header) in pinning policy and optional report-uri directive with URL where to send pinning violation reports. At least one of the public keys of the certificates in the certificate chain needs to match a pinned public key in order for the chain to be considered valid by the user agent.

At the time of publishing, RFC 7469 only allowed the SHA-256 hash algorithm. Hashes for HPKP policy can be generated by shell commands mentioned in Appendix A. of RFC 7469 or third-party tools.

A website operator can choose to either pin the root certificate public key of a particular root certificate authority, allowing only that certificate authority (and all intermediate authorities signed by its key) to issue valid certificates for the website's domain, and/or to pin the key(s) of one or more intermediate issuing certificates, or to pin the end-entity public key.

At least one backup key must be pinned, in case the current pinned key needs to be replaced. The HPKP is not valid without this backup key (a backup key is defined as a public key not present in the current certificate chain).^[2]

HPKP is standardized in RFC 7469.^[1] It expands on static certificate pinning, which hardcodes public key hashes of well-known websites or services within web browsers and applications.^[3]

The Chromium browser disables pinning for certificate chains with private root certificates to enable various corporate content inspection scanners^[4] and web debugging tools (such as mitmproxy or Fiddler). The RFC 7469 standard also recommends disabling pinning violation reports for such certificate chains.^[5]

Reporting

If the user agent performs pin validation and fails to find a valid SPKI fingerprint in the served certificate chain, it will POST a JSON formatted violation report to the host specified in the report-uri directive containing details of the violation. The user agent cannot send HPKP violation reports to the same domain, as the report was triggered because the connection failed, so hosts must use an alternative domain or use a reporting service.^[6]

Browser support

HPKP is supported in Firefox and Chrome,^[7] but not in Internet Explorer/Edge.^[8]

See also

• HTTP Strict Transport Security

References

External links

• Online browser HSTS and Public Key Pinning test
• JavaScript Public-Key-Pins (HPKP) calculator
• Article about the very beginning of HPKP
• Public Key Pinning Extension for HTTP (HPKP) article on Mozilla Developer Network
• HPKP Violation Reporting
• HPKP Policy Analyser
• HPKP Hash Generator (URL)
• HPKP Hash Generator (PEM)