Confirmed users
238
edits
SecurityEngineering/Public Key Pinning: Difference between revisions
SecurityEngineering/Public Key Pinning (view source)
Revision as of 22:21, 22 May 2014
, 22 May 2014no edit summary
No edit summary |
|||
| 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. | 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, | 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: | Currently feature is expected to be done on three phases: | ||
| Line 13: | Line 13: | ||
* 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, this is Chrome's default) | * 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, this is Chrome's default) | ||
* 2. Strict. Pinning is always enforced. | * 2. Strict. Pinning is always enforced. | ||
* 3. Enforce test mode. Enforce pinning violations, even if the pin is in test mode. | |||
== Built in Pins == | == Built-in Pins == | ||
This is the first stage that and has landed in central {{bug|704204}}. | This is the first stage that and has landed in central {{bug|704204}}. | ||
| Line 25: | Line 26: | ||
Tracking bug: {{bug|1004350}} | Tracking bug: {{bug|1004350}} | ||
==Pinning Service == | == 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. | 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 == | ||
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}} | |||