Re: [websec] Question on Pinning Overrides

[Chris Palmer <[e-mail]>]

On Tue, Oct 14, 2014 at 9:33 AM, Jeffrey Walton <[e-mail]> wrote:

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

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

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

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.