SecurityEngineering/Public Key Pinning: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
== 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/).  
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.
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.


Currently feature is expected to be done on three phases:
== Implementation status ==
Firefox 32 and later has the ability to enforce built-in pinsets, or mappings of public key information to domains ({{bug|704204}}).


# Built-in Pins
We will:
# Pinning service for addons (including non-volatile storage)
# Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.
# Allowing sites to set up their own pins.
# 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)


There will be three levels of pinning enforcement in the code (integer preference security.cert_pinning.enforcement_level)
=== New sites pinned in Firefox 32 ===
* 0. Pinning disabled
* Twitter: twitter.com, api.twitter.com, business.twitter.com, dev.twitter.com, mobile.twitter.com, oauth.twitter.com, platform.twitter.com, twimg.com, www.twitter.com
* 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, this is Chrome's default)
* AMO: *.addons.mozilla.org, *.addons.mozilla.net
* 2. Strict. Pinning is always enforced.
* Mozilla CDN: *.cdn.mozilla.{org,net}, *.media.mozilla.com
* 3. Enforce test mode. Enforce pinning violations, even if the pin is in test mode.


== Built-in Pins ==
=== New sites pinned in Firefox 33 ===
* Twitter: *.twitter.com (expanded coverage from 32)
* 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)


This is the first stage that and has landed in central {{bug|704204}}.
== New sites pinned in Firefox 34 ===
 
* Firefox accounts: *.accounts.firefox.com
We are attempting to:
* TOR
# Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.
# 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}}
Tracking bug for pinning all the things: {{bug|1004350}}


== More information ==
[[SecurityEngineering/Public_Key_Pinning/SiteOperators]]
[[SecurityEngineering/Public_Key_Pinning/SiteOperators]]
[[SecurityEngineering/Public_Key_Pinning/ReleaseEngineering]]
[[SecurityEngineering/Public_Key_Pinning/ReleaseEngineering]]
Pinning dashboard: http://people.mozilla.org/~mchew/pinning_dashboard
Pinning dashboard: http://people.mozilla.org/~mchew/pinning_dashboard
== Pinning Service ==
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.
(mmc: really? this is news to me :) )


== Public Key Pinning Extension for HTTP ==
== Public Key Pinning Extension for HTTP ==


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


Tracking bug: {{bug|787133}}
Tracking bug: {{bug|787133}}

Revision as of 16:02, 23 July 2014

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 and later has the ability to enforce built-in pinsets, or mappings of public key information to domains (bug 704204).

We will:

  1. Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.
  2. 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
  3. Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)

New sites pinned in Firefox 32

  • Twitter: twitter.com, api.twitter.com, business.twitter.com, dev.twitter.com, mobile.twitter.com, oauth.twitter.com, platform.twitter.com, twimg.com, www.twitter.com
  • AMO: *.addons.mozilla.org, *.addons.mozilla.net
  • Mozilla CDN: *.cdn.mozilla.{org,net}, *.media.mozilla.com

New sites pinned in Firefox 33

New sites pinned in Firefox 34 =

  • Firefox accounts: *.accounts.firefox.com
  • TOR

Tracking bug for pinning all the things: bug 1004350

More information

SecurityEngineering/Public_Key_Pinning/SiteOperators SecurityEngineering/Public_Key_Pinning/ReleaseEngineering Pinning dashboard: http://people.mozilla.org/~mchew/pinning_dashboard

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=999617"