HPKP: What is HTTP Public Key Pinning?

HTTP Public Key Pinning

HTTP Public Key Pinning (HPKP) protect websites from man-in-the-middle (MITM) attacks of a misissued certificate, while HPKP enables administrators to specify which cryptographic public keys are trusted for a particular domain.

HPKP also 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.

Problems with HPKP

Difficulty in Maintenance

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.

Technical Complications

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.

Compatibility Issues

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.

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 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.

Google Support

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 HTTP Public Key Pinning Works?

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 that 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.

Read the complete article -https://certera.com/blog/what-is-http-public-key-pinning-hpkp