Skip to content

Remove HPKP, given Chrome's deprecation of it #239

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
konklone merged 1 commit into from
Nov 20, 2017
Merged

Remove HPKP, given Chrome's deprecation of it #239

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 1 addition & 32 deletions pages/certificates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,9 +15,6 @@ Frequently asked questions and answers about HTTPS certificates and certificate
* [Are there federal restrictions on acceptable certificate authorities to use?](#are-there-federal-restrictions-on-acceptable-certificate-authorities-to-use%3f)
* [Then how can I limit which CAs can issue certificates for a domain?](#then-how-can-i-limit-which-cas-can-issue-certificates-for-a-domain%3f)

* [Certificate Transparency](#certificate-transparency)
* [HTTP Public Key Pinning](#http-public-key-pinning)

## What are certificates and certificate authorities?

Websites use **certificates** to create an HTTPS connection. When signed by a trusted **certificate authority** (CA), certificates give confidence to browsers that they are visiting the "real" website.
Expand Down Expand Up @@ -87,9 +84,7 @@ In practice, federal agencies use a wide variety of publicly trusted commercial

There is no simple and 100% effective way to force all browsers to only trust certificates for your domain that have been issued from a certain CA. In general, the strength of HTTPS on today's internet depends on the overall standards, competence, and accountability of the entire CA system.

However, domain owners have some options to reduce the risk or impact of misissued or fraudulent certificates:

### Certificate Transparency
However, domain owners can use **Certificate Transparency** to reduce the risk or impact of misissued or fraudulent certificates.

**[Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency)** (CT) allows domain owners to **detect missuance of certificates after the fact**.

Expand All @@ -105,29 +100,3 @@ The strength of Certificate Transparency increases as more CAs publish more cert
* [RFC 6962](https://tools.ietf.org/html/rfc6962), the experimental standard for CT
* [Wikipedia entry](https://en.wikipedia.org/wiki/Certificate_Transparency) for CT

### HTTP Public Key Pinning

**[HTTP Public Key Pinning](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)** (HPKP) allows domain owners to **tell browsers which certain keys, certs or CAs are trusted for their domain**.

Domain owners can use HPKP in one of two ways:

* The `Public-Key-Pins` header contains a list of SHA-256 hashes of public key information corresponding to client, intermediate, or root certificates. [Supporting browsers](http://caniuse.com/#search=hpkp) **will hard-fail** on certificates whose validated chain does not contain at least one of the listed keys. The domain owner can list a URI that browsers can POST to with error information when a hard-fail occurs.

* The `Public-Key-Pins-Report-Only` HTTP header contains the same information, but **will not fail or show users an error** if a pinning violation is detected. Browsers will report detected violations to a given URI.

Using `Public-Key-Pins` is **powerful but potentially dangerous**, as mistakes can lead to a site being rendered entirely inaccessible for weeks or months.

Using `Public-Key-Pins-Report-Only` is very safe, and can provide useful information to detect potential certificate misissuance or attacks on users.

Like [HSTS](/hsts/), HPKP only takes effect once the browser has visited the site once and received the HPKP header over a secure connection. HPKP preloading is possible, but as of 2016 this requires special manual coordination with browsers to do.

**Note:** As currently implemented in [Chrome](https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-) and [Firefox](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#How_to_use_pinning), pinning rules can be overridden by locally installed root certificates. This allows device owners -- and attackers who are able to install a local root -- to intercept or modify traffic even when a web service uses HPKP.

#### HPKP Resources

* [Guide to rolling out HPKP reporting](https://developers.google.com/web/updates/2015/09/HPKP-reporting-with-chrome-46?hl=en) by the Chrome team
* [RFC 7469](https://tools.ietf.org/html/rfc7469), the official standard
* [Discussion on GitHub](https://github.com/SSLMate/sslmate/issues/10) about HPKP strategy
* [Wikipedia entry](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) for HPKP
* [Browser support](http://caniuse.com/#search=hpkp) for HPKP
* [Mozilla documentation](https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning) for HPKP