Open Bug 1168603 Opened 5 years ago Updated 3 years ago
hpkp implementation conflates user-installed CAs with pinning override
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: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning 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. https://tools.ietf.org/html/rfc7469#section-2.6 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 platform). 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=438825] or privacy-sensitive activists using Autistici mail and blogs [http://www.autistici.org/en/ca/index.html]) 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  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.
Status: UNCONFIRMED → NEW
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.