Subject: [websec] Question on Pinning Overrides

From: Jeffrey Walton <[email-masked]>
Date: Tue, 14 Oct 2014 12:33:42 -0400

Section 2.7 states:

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs should allow users to override such additional sources,
   including disabling them from consideration.

>From section 2.7, I understand a _user_ can provide an override to a
_preloaded_ pinset. But I don't see where a user is provided the
authority to override a non-preloaded pinset. And I don't see where an
external entity is provided authority to override a preloaded or
non-preloaded pinset.

Is this correct?

If correct, shouldn't the user be allowed to override both preloaded
and non-preloaded pinsets?

If correct, won't that break Chrome with respect to
http://www.imperialviolet.org/2011/05/04/pinning.html (see section
"What about MITM proxies, Fiddler etc?")?

---

From: Chris Palmer <[email-masked]>
Date: Tue, 14 Oct 2014 09:58:13 -0700

>    including disabling them from consideration.

This is so that, for example, there is at least a chance people can
recover from stale built-in pin sets. (Chrome currently handles this
by skipping Pin Validation for built-in pin sets if Chrome detects
that it was built 10 weeks or more in the past.)

> "What about MITM proxies, Fiddler etc?")?

Section 2.6:

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

So that's how you make Fiddler work, among other things.

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 19 Oct 2014 12:27:30 -0400

Hi Chris,

I've had a few days to think about this...

> So that's how you make Fiddler work, among other things.

This is where I am concerned: user-defined. I thinks its a mistake to
claim the user defined anything under most circumstances and use
cases. Its not clear to me where the user makes a well informed
decision.

The uncommon case is the pen-tester or researcher using the proxy
tools. In this use case, the user clearly made the decision, and
clearly defined the trust anchor.

I think the more common cases of "I want to use my device at work" or
"I must click through the buttons to use the wifi hotspot" is devoid
of any user understanding and decision. In this use case, the user did
not define a trust anchor. Rather, it was surreptitiously installed by
the device management software or unscrupulous service providers.

In fact, the "user's decision" was likely hidden away in a Terms of
Service when Nokia was caught performing intercept en masse [0]. In
this case, the user clearly did not define anything. Rather, the
handset manufacture made the decision for the user.

Is there anything that can be done to address the gap?

[0] http://web.archive.org/web/20140127075723/http://falkvinge.net/2013/01/11/death-twitches-nokia-caught-wiretapping-encrypted-traffic-from-its-handsets/

---

From: Chris Palmer <[email-masked]>
Date: Mon, 20 Oct 2014 11:40:14 -0700

> the device management software or unscrupulous service providers.

To install a new trust-anchor, the attacker/owner/user/device
administrator must have administrative control over the device, or
must trick the true owner into mis-using their power.

Such an attacker is, by necessity, outside the scope of the key
pinning threat model.

http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

> Service when Nokia was caught performing intercept en masse [0]. In

If the device manufacturer is also taking administrative control over
devices in the field, then market pressure (such as those articles) is
the only recourse. We can't do anything technically that would not
also break legitimate use cases.