HTTP Public Key Pinning

Last updated

HTTP Public Key Pinning (HPKP) is an obsolete Internet security mechanism delivered via an HTTP header which allows HTTPS websites to resist impersonation by attackers using misissued or otherwise fraudulent digital certificates. [1] A server uses it to deliver to the client (e.g. web browser) a set of hashes of public keys that must appear in the certificate chain of future connections to the same domain name.

Contents

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 valid for a given time; on subsequent connections, during that validity time, clients expect the server to use one or more of those public keys in its certificate chain. If it does not, an error message is shown, which cannot be (easily) bypassed by the user.

The technique does not pin certificates, but public key hashes. This means that one can use the key pair to get a certificate from any certificate authority, when one has access to the private key. Also the user can pin public keys of root or intermediate certificates (created by certificate authorities), restricting site to certificates issued by the said certificate authority.

Due to HPKP mechanism complexity and possibility of accidental misuse (potentially causing a lockout condition by system administrators), in 2017 browsers deprecated HPKP and in 2018 removed its support in favor of Certificate Transparency. [2] [3]

Mechanism

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. (Appendix A. of RFC 7469 mentions some tools and required arguments that can be used to produce hashes for HPKP policies.)

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). [4]

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. [5]

Most browsers disable pinning for certificate chains with private root certificates to enable various corporate content inspection scanners [6] and web debugging tools (such as mitmproxy or Fiddler). The RFC 7469 standard recommends disabling pinning violation reports for "user-defined" root certificates, where it is "acceptable" for the browser to disable pin validation. [7]

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. This URI may be served via HTTP or HTTPS; however, the user agent cannot send HPKP violation reports to an HTTPS URI in the same domain as the domain for which it is reporting the violation. Hosts may either use HTTP for the report-uri, use an alternative domain, or use a reporting service. [8]

Some browsers also support the Public-Key-Pins-Report-Only, which only triggers this reporting while not showing an error to the user.

Criticism and decline

During its peak adaptation, HPKP was reported to be used by 3,500 of top 1 million internet sites, a figure that declined to 650 around the end of 2019. [9]

Criticism and concern revolved around malicious or human error scenarios known as HPKP Suicide and RansomPKP. [10] In such scenarios, a website owner would have their ability to publish new contents to their domain severely hampered by either losing access to their own keys or having new keys announced by a malicious attacker.

Browser support and deprecation

Browser support for HTTP Public Key Pinning
BrowserVersion addedVersion deprecatedVersion removedNotes
Google Chrome46 [11] 67 [12] 72 [13] [14]
Opera33 [15] 54 [16] 60
Firefox3572 [17] [18] —Can be enabled by setting flag security.cert_pinning.hpkp.enabled to true. [19]
Internet Explorer — [20] ——
Microsoft Edge — [20] ——
Safari———

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes information about the key, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Root certificate</span> Certificate identifying a root authority

In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string. For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

<span class="mw-page-title-main">Digest access authentication</span> Method of negotiating credentials between web server and browser

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.

In computer hypertext, a URI fragment is a string of characters that refers to a resource that is subordinate to another, primary resource. The primary resource is identified by a Uniform Resource Identifier (URI), and the fragment identifier points to the subordinate resource.

<span class="mw-page-title-main">.onion</span> Pseudo–top-level internet domain

.onion is a special-use top level domain name designating an anonymous onion service, which was formerly known as a "hidden service", reachable via the Tor network. Such addresses are not actual DNS names, and the .onion TLD is not in the Internet DNS root, but with the appropriate proxy software installed, Internet programs such as web browsers can access sites with .onion addresses by sending the request through the Tor network.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page, from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

<span class="mw-page-title-main">DigiCert</span> Internet security company

DigiCert, Inc. is a digital security company headquartered in Lehi, Utah. As a certificate authority (CA) and trusted third party, DigiCert provides public key infrastructure (PKI) and validation required for issuing digital certificates or TLS/SSL certificates.

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. It is a Candidate Recommendation of the W3C working group on Web Application Security, widely supported by modern web browsers. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

References

  1. 1 2 Evans, Chris; Palmer, Chris; Sleevi, Ryan (April 2015). Public Key Pinning Extension for HTTP. IETF. doi: 10.17487/RFC7469 . ISSN   2070-1721. RFC 7469.
  2. ↑ Leyden, John (2017-10-30). "RIP HPKP: Google abandons public key pinning". The Register . Retrieved 2018-12-18.
  3. ↑ Tung, Liam (2017-10-30). "Google: Chrome is backing away from public key pinning, and here's why". ZDNet . Retrieved 2018-12-18.
  4. ↑ "About Public Key Pinning". noncombatant.org. Retrieved 2015-05-07.
  5. ↑ "Certificate and Public Key Pinning - OWASP". www.owasp.org. Retrieved 2015-05-07.
  6. ↑ "Security FAQ - The Chromium Projects". www.chromium.org. Retrieved 2015-07-07.
  7. ↑ Evans, C.; Palmer, C.; Sleevi, R. (2015). "RFC 7469 - Public Key Pinning Extension for HTTP". tools.ietf.org. doi:10.17487/RFC7469 . Retrieved 2015-07-07.
  8. ↑ "HPKP Violation Reporting". Scott Helme.
  9. ↑ "HPKP is no more". Scott Helme. 2020-01-20. Retrieved 2020-01-30.
  10. ↑ "Using security features to do bad things". Scott Helme. 2016-08-15. Retrieved 2020-01-30.
  11. ↑ Stark, Emily (2015-08-31). "Rolling out public key pinning with HPKP reporting". Chrome Developers. Archived from the original on 2023-01-16. Retrieved 2023-03-10.
  12. ↑ Medley, Joe (2018-06-07). "Deprecations and removals in Chrome 67". Google Developers. Archived from the original on 2023-03-10. Retrieved 2023-03-10.
  13. ↑ Palmer; Estark; Rsleevi (2022-09-13). "Remove HTTP-Based Public Key Pinning - Chrome Platform Status". www.chromestatus.com. Archived from the original on 2022-05-25. Retrieved 2019-11-18.
  14. ↑ Medley, Joe (2020-06-27). "Deprecations and removals in Chrome 72 - Chrome Developers". Chrome Developers. Archived from the original on 2022-11-18. Retrieved 2023-03-10.
  15. ↑ Bynens, Mathias (2015-10-27). "Opera 33 released". GitHub. Opera. Archived from the original on 2023-03-10. Retrieved 2023-03-10.
  16. ↑ "What's new in Chromium 67 and Opera 54". GitHub. Opera. 2018-06-28. Archived from the original on 2023-03-10. Retrieved 2023-03-10.
  17. ↑ "HTTP Public Key Pinning is no longer supported". Firefox Site Compatibility. November 14, 2019. Archived from the original on 2020-05-29. Retrieved 2020-02-19.
  18. ↑ Keeler, Dana (2019-11-13). "Mozilla source code change that removed HPKP including discussion and reasons for this change (bug 1412438)". Mozilla Firefox Version Control. Archived from the original on 2023-03-10. Retrieved 2023-03-10.
  19. ↑ "mozilla-central: changeset 501812:d791bfa31f08ec478b2ef6ca4f89b3a8849d723b". hg.mozilla.org. Retrieved 2019-11-18.
  20. 1 2 "The status of Public Key Pinning Extension for HTTP in Microsoft Edge is Under Consideration". Microsoft Edge Development. Archived from the original on 2016-12-20. Retrieved 2018-09-21.


This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.