Which mechanism uses HTTP headers to pin a server's public key to mitigate fraudulent certificates?

Which mechanism uses HTTP headers to pin a server's public key to mitigate fraudulent certificates?

• A. Token Binding
• B. HTTP Public Key Pinning (HPKP)
• C. HSTS
• D. SSL Pinning

Answer: (B)

Pinning a server’s public keys via HTTP headers tests the ability to harden trust in TLS by constraining which keys are considered valid for a domain. This is done with a header that communicates the allowed public keys for the site’s certificates. The browser or client stores these pins (typically hashes of the server’s public key info) along with a time period to trust them. On subsequent connections, the client checks the server’s presented certificate chain against the pins; if none of the keys match, the connection is rejected. This protects against fraudulent certificates issued by compromised or malicious certificate authorities, because even if a rogue CA issues a certificate for the domain, it would have a different public key that isn’t in the pinned set. In practice, this mechanism is implemented by the HTTP header that carries the pins, along with a max-age and optional reporting. It requires careful management: if keys are rotated without updating the pins, legitimate sites can inadvertently lock out users. Also, HPKP has fallen out of favor in modern deployments due to the risk of misconfiguration, with other approaches like Certificate Transparency and related controls becoming more common, but the concept described here is pinning public keys through HTTP headers.

Pinning a server’s public keys via HTTP headers tests the ability to harden trust in TLS by constraining which keys are considered valid for a domain. This is done with a header that communicates the allowed public keys for the site’s certificates. The browser or client stores these pins (typically hashes of the server’s public key info) along with a time period to trust them. On subsequent connections, the client checks the server’s presented certificate chain against the pins; if none of the keys match, the connection is rejected. This protects against fraudulent certificates issued by compromised or malicious certificate authorities, because even if a rogue CA issues a certificate for the domain, it would have a different public key that isn’t in the pinned set.

In practice, this mechanism is implemented by the HTTP header that carries the pins, along with a max-age and optional reporting. It requires careful management: if keys are rotated without updating the pins, legitimate sites can inadvertently lock out users. Also, HPKP has fallen out of favor in modern deployments due to the risk of misconfiguration, with other approaches like Certificate Transparency and related controls becoming more common, but the concept described here is pinning public keys through HTTP headers.