SecurityEngineering/Public Key Pinning: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎Implementation status: remove no-longer-pinned sites)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. The benefit of certificate pinning is that users cannot be mitm'ed because of a rogue CA not on the site's list (see the Diginotar attack which Chrome detected and we did not: https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/).
== Background ==


The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser. In particular we are pinning the sha256 digest of the der encoded subject public key info. In order to reduce rejections, firefox will compute all potential trust chains before deciding that are no valid pins.
Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. Public key pinning prevents man-in-the-middle attacks due to rogue CAs not on the site's list (see the Diginotar attack which Chrome detected and we did not: https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/).  


Currently feature is expected to be done on three phases:
The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser. In particular we are pinning the sha256 digest of the der encoded subject public key info. In order to reduce rejections, Firefox computes all potential trust chains before deciding that are no valid pins.


# Built-in Pins
== Implementation status ==
# Pinning service for addons (including non-volatile storage)
Firefox 32 on desktop and later has the ability to enforce built-in pinsets, or mappings of public key information to domains ({{bug|744204}}).
# Allowing sites to set up their own pins.


There will be three levels of pinning enforcement in the code (integer preference security.cert_pinning.enforcement_level)
Pinning is supported in Firefox 34 and later on Android.
* 0. Pinning disabled
 
* 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, this is Chrome's default)
We currently:
* 2. Strict. Pinning is always enforced.
# Pin all of the sites that Chrome already does (mainly Google sites) by importing chromium's pinset.
# Pin our own sites after auditing them and cleaning them up.
# Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)


== Built in Pins ==
=== Currently-pinned Sites ===
* AMO: *.addons.mozilla.org, *.addons.mozilla.net
* Firefox accounts: *.accounts.firefox.com
* Mozilla CDN: *.cdn.mozilla.{org,net}, *.media.mozilla.com
* Google: too many to list (see everything from https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json with the "google" pinset)
* TOR


This is the first stage that and has landed in central {{bug|704204}}.
Tracking bug for pinning all the things: {{bug|1004350}}


We are attempting to:
== How to use pinning ==
# Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.
Starting with FF 32, it's on by default, so you don't have to do anything. The pinning level is enforced by a pref, security.cert_pinning.enforcement_level
# Pin our own sites after auditing them and cleaning them up, so that our users know that the updates we serve actually come from us. The list of initial mozilla sites that are pinned is being tracked at: https://mana.mozilla.org/wiki/display/services/Mozilla+sites+SSL+Certificate+Authority+roots+sync+with+Gecko+Built-In+Pins
# Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)


Tracking bug: {{bug|1004350}}
* 0. Pinning disabled
* 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)
* 2. Strict. Pinning is always enforced.
* 3. Enforce test mode.


==Pinning Service ==
== More information ==
* [[SecurityEngineering/Public_Key_Pinning/SiteOperators]]
* [[SecurityEngineering/Public_Key_Pinning/ReleaseEngineering]]
* [[SecurityEngineering/Public_Key_Pinning/Implementation_Details]]


This will allow addons to start pinning sites for which there is no built-in list and will allow us to have a cleaner mechanism to test new entries to the pinning list.
== Public Key Pinning Extension for HTTP ==


== HPKP Header ==
In the future, we would like to support dynamic pinsets rather than relying on built-in ones. HTTP Public Key Pinning (HPKP) [http://tools.ietf.org/html/draft-ietf-websec-key-pinning-12] is an HTTP header that allows sites to announce their pinset. It relies on "clean load" in order to provide a similar level of assurance as built-in pins.


The final state where we parse headers sent by sites to populate the pinning service.
Tracking bug: {{bug|787133}}

Latest revision as of 20:11, 23 May 2024

Background

Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. Public key pinning prevents man-in-the-middle attacks due to rogue CAs not on the site's list (see the Diginotar attack which Chrome detected and we did not: https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/).

The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser. In particular we are pinning the sha256 digest of the der encoded subject public key info. In order to reduce rejections, Firefox computes all potential trust chains before deciding that are no valid pins.

Implementation status

Firefox 32 on desktop and later has the ability to enforce built-in pinsets, or mappings of public key information to domains (bug 744204).

Pinning is supported in Firefox 34 and later on Android.

We currently:

  1. Pin all of the sites that Chrome already does (mainly Google sites) by importing chromium's pinset.
  2. Pin our own sites after auditing them and cleaning them up.
  3. Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)

Currently-pinned Sites

Tracking bug for pinning all the things: bug 1004350

How to use pinning

Starting with FF 32, it's on by default, so you don't have to do anything. The pinning level is enforced by a pref, security.cert_pinning.enforcement_level

  • 0. Pinning disabled
  • 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)
  • 2. Strict. Pinning is always enforced.
  • 3. Enforce test mode.

More information

Public Key Pinning Extension for HTTP

In the future, we would like to support dynamic pinsets rather than relying on built-in ones. HTTP Public Key Pinning (HPKP) [1] is an HTTP header that allows sites to announce their pinset. It relies on "clean load" in order to provide a similar level of assurance as built-in pins.

Tracking bug: bug 787133

Retrieved from "https://wiki.allizom.org/index.php?title=SecurityEngineering/Public_Key_Pinning&oldid=1250874"