Open Bug 1168603 Opened 5 years ago Updated 3 years ago

hpkp implementation conflates user-installed CAs with pinning override


(Core :: Security: PSM, defect, P5)





(Reporter: dkg, Unassigned)


(Whiteboard: [psm-backlog])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 Iceweasel/37.0.2
Build ID: 20150420231403

Steps to reproduce:

Installed a custom root CA needed for smoother access to web services at https//a.private-zone.example, https://b.private-zone.example, etc.

Actual results:

Lost HPKP (public key pinning) protection for the entire rest of the web.

Expected results:
describes security.cert_pinning.enforcement_level as:

    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.

The default state (1) conflates the idea that a user-added trust
anchor is welcome to override HPKP headers. explicitly allows
the current behavior, but does not mandate it:

   [...] It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying

I believe this carveout was intended to accomodate vendors of TLS MiTM
boxes that offer anti-malware and data leak prevention tools for
businesses engaged in surveillance of their employees.  It should not
introduce additional weakenesses for users not subjected to these
intrusive network monitoring devices.

Mozilla can and should do better with its local policy than this
current rough approximation, if we want to give Mozilla users the
maximal benefit of HPKP.


Many users of specific services (e.g. Brazilian citizens accessing
government web sites
[] or
privacy-sensitive activists using Autistici mail and blogs
[]) are effectively obliged
to install a root certificate in order to have smooth interaction with
these services on Firefox.

As a result, those Firefox users are now vulnerable to attacks that
HPKP would have otherwise protected them from.  This includes attacks
against services unrelated to the service for which they installed
their custom CA: the installed CA can now issue certs for any web site and can violate any HPKP pin without the user being protected.  (see also bug 953322 about name constraints for user-installed CAs)

This could be mitigated by the following approach:

 * update the certificate store to include an additional explicit
   trust bit "can override pinning" for each CA -- this bit is only
   relevant for CA certs that have the "can identify web sites" flag
   set.  This bit should be cleared for all built-in CA certs, and would
   need to be explicitly set upon importing an external CA cert.

 * change the semantics of the default security.cert_pinning.enforcement_level = 1
   to be " "pinning not enforced if the trust anchor is allowed to
   override pinning"

 * (optionally) add security.cert_pinning.enforcement_level = 4, with
   the old [1] semantics.

(alternately, add the new semantics as 4 and make 4 the default)

It's not clear to me what the best way to transition pre-existing
user-inserted CAs across such an upgrade would be.  The least
disruptive change would be for pre-existing user-inserted CAs to
automatically gain the "can override pinning" bit upon upgrade.  The
safest change would be for pre-existing user-inserted CAs to leave the
bit clear upon upgrade.
Component: Untriaged → Security: PSM
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Version: 37 Branch → Trunk
In addition to this fix, bug 1059392 would be great -- if the default is set to 2, that would be excellent.

Vendors of TLS MiTM boxes should need to configure the browser to submit to their middleboxes.  Firefox shouldn't default to making MiTM's easy.
I think this is a good idea. A similar approach might be to be able to add custom name constraints to imported roots. That way, they wouldn't be able to issue certs for other domains and thereby defeat pinning. Unfortunately, the population of people that both need to import an external root CA and understand the issues at stake is very small, so we're unlikely to devote resources to implementing this.
Whiteboard: [psm-backlog]
You need to log in before you can comment on or make changes to this bug.