1302640 - security.cert_pinning.enforcement_level ignored for built-in pinsets

Status: RESOLVED DUPLICATE of bug 1303127

(Core :: Security: PSM, defect)

Description

[Nik Unger]

As described at
https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning, Firefox
includes built-in public key pins for several important domains (e.g.,
addons.mozilla.org). The article describes a pref,
security.cert_pinning.enforcement_level, that should control the
strictness of the enforcement. A value of "1" (the default) ignores
pinning when the user has installed their own CA, while a value of "2"
means "pinning is always enforced".

Setting security.cert_pinning.enforcement_level to 2 does not affect the
built-in pinsets (i.e., user-inserted CAs continue to override pinning
for these domains). In contrast, setting
security.cert_pinning.enforcement_level to 2 works as expected for
domains protected using HPKP.

Test environment:
- Freshly installed Debian Jessie VM:
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03)
x86_64 GNU/Linux
- Firefox 50.0a2 (2016-08-11) build ID 20160811004013, also tested with
Firefox 45.3.0 ESR
- New Firefox profile with default settings
- mitmproxy configured in transparent mode (acting as default gateway)

Steps to reproduce:
- Arrange for TLS interception (e.g., using mitmproxy from
https://mitmproxy.org/)
- Launch new Firefox profile
- Visit https://addons.mozilla.org/ (or any other domain from the
built-in pinset). Note the certificate error.
- Install root CA from the interception proxy (for mitmproxy, visit
http://mitm.it/)
- Visit the pinned site again. Note that interception occurs.
- In about:config, set security.cert_pinning.enforcement_level to 2
- Visit the pinned site again. Note that interception still occurs.

Expected result: a pinning error (e.g.,
MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE) should be displayed during the
final step and the TLS handshake should fail.
Actual result: pinning is not applied (tested addons.mozilla.org,
google.com, and twitter.com, all of which are claimed to be covered by
the wiki).

Note that the feature is working as expected for HPKP-enabled sites.
Steps to reproduce:
- Disable TLS interception
- Launch new Firefox profile
- Visit a HPKP protected site (e.g., https://scotthelme.co.uk/)
- Arrange for TLS interception
- Install root CA from the interception proxy
- Visit the HPKP site again. Note that interception occurs.
- Set security.cert_pinning.enforcement_level to 2
- Visit the HPKP site again.

Expected and actual result: MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE occurs.

These results suggest that either built-in pinsets are not functioning
at all, or security.cert_pinning.enforcement_level does not apply to
them. In the latter case, this seems undesirable since enforcement level
2 suggests that the user expects to operate in an environment without
TLS MitM attacks occurring (and domains in the built-in pinsets are
presumably of top importance).

Comment 1

[Nik Unger]

Additional observation: https://pinningtest.appspot.com/ loads without complaint (tested in both 50.0a2 and 45.3.0 as in the original report), even when a MitM is present. Specifically, both the (valid) certificate signed by Google Internet Authority G2 and the certificate dynamically generated by mitmproxy are trusted, even though the fingerprint is intentionally set to a non-matching value in the built-in pins.

This suggests to me that the built-in pins may be completely non-functional in these releases, rather than simply failing to respond to security.cert_pinning.enforcement_level.

Related:
https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning/Implementation_Details
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h
Bug 1004350

Comment 2

[Nik Unger]

This issue was indeed caused by non-functional static pinning, as was later reported and resolved publicly in Bug 1303127. Marking this as "RESOLVED".