Re: [websec] Issue #53 - Clarify status of pin validation when used with private trust anchors

[Yoav Nir <[e-mail]>]

On Nov 22, 2012, at 2:45 AM, Ryan Sleevi <[e-mail]> wrote:

> On Wed, November 21, 2012 1:38 pm, Yoav Nir wrote:
>> Hi
>> 
>> During the meeting in Atlanta I said that saying that that pin validation
>> is disabled when the cert chains to a private trust anchor would not go
>> over well, because it's disabling a security feature in the presence of an
>> attack. I still think so, but I think we can raise less red flags if we
>> just describe what the issue is - that there is a TLS proxy.
>> 
>> I don't have suggested text, at least yet, but here's how I think the
>> issue can be addressed. Keep in mind that we're not writing a design for
>> any particular browser.
>> 
>> ===
>> On some networks, mostly corporate networks, there are TLS proxies,
>> transparent proxies that sign certificates on behalf of visited web sites
>> as described in [ref]. When a UA gets into such a network, the certificate
>> presented in the TLS handshake will not be consistent with the UA's
>> previously stored pins.
>> 
>> It is up to the UA to decide whether such a TLS proxy is acceptable or
>> not. If it is acceptable, then pinning should be disabled, and the UA
>> should not follow the mandates in section 2.4 of this document. Ideally,
>> such proxies, or their associated trust anchors would be specially marked
>> as trusted for this purpose. If the UA does not allow for such a
>> configuration, a heuristic MAY be used to determine what trust anchors are
>> used for a legitimate TLS proxy. One such heuristic, is that all trust
>> anchors that are not part of the stock trust anchor store that comes with
>> the UA or the operating system, but that are in the trust anchor store
>> (implying that they have been added by the user) are acceptable for TLS
>> proxies.
>> ===
>> 
>> I think this defuses the issue. What do others think?
> 
> The wording suggests that it's primarily a network layer 'attacker', which
> somehow raises the spectre of RFC 1984 (unfairly, I think), but we also
> see TLS proxies that are entirely local to clients' machines - for
> example, Antivirus Software that installs a Winsock LSP.

OK, but clients that share a machine with software like that can never ever verify pins. I don't think we really need to talk about them.

> I'm still working with Chris Palmer to find suitable language to propose
> on this, but we've been looking at ways to define this processing in terms
> of "client policy" that may supercede or disregard the the Pinning
> Metadata for a Known Pinned Host, to be incorporated into Section 2.4.
> (Validating Pinned Connections)

Looking forward to seeing this.


>> One other suggestion that was brought up in Atlanta, was to have the
>> server specify a policy about private trust anchors in the Public-Key-Pins
>> header, something like:
>> 
>>    Public-Key-Pins: max-age=500; policy=strict;
>>        pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
>>        pin-sha1="IvGeLsbqzPxdI0b0wuj2xVTdXgc="
>> 
>>    Public-Key-Pins: max-age=31536000; policy=accept_private;
>>        pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
>>        pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="
>> 
>> 
>> In case of policy=strict, the UA will not accept any handshake that
>> disagrees with stored pins. This might be preferred by some servers, that
>> are willing to accept not being accessible from all networks for the
>> benefit of preventing MitM attacks. What do others think about this idea?
> 
> Given HPKP's shared history with HSTS, and as discussed during Atlanta,
> one of the things we were looking at was ensuring the ABNF grammar was
> consistent with the grammar that was decided for HSTS. In particular, the
> ABNF grammar should NOT specify all of individual tokens, but instead
> define the set of directives, to allow new directives to be added.
> 
> This ABNF looks as such:
> 
> Public-Key-Pins  = "Public-Key-Pins" ":" [ directive ] *( ";" [ directive ] )
> 
> directive        = simple-directive
>                   / pin-directive
> 
> simple-directive = directive-name [ "=" directive-value ]
> directive-name   = token
> directive-value  = token | quoted-string
> 
> pin-directive    = "pin-" token "=" quoted-string
> 
> 
> With the above grammar, and given that HPKP's threat model is primarily
> motivated by allowing site operators to defend against certificate
> misissuance from CAs trusted by the client, we're proposing that 'strict'
> be added (as a simple-directive). The absence of 'strict' implies that the
> UA is permitted to allow client local policy to override the directive,
> while the presence of 'strict' implies that the header should be
> interpreted exactly as it is supplied.
> 
> The reasoning to making the default open, rather than closed, is that we
> anticipate that 'strict' is not the primary or default mode that sites
> intend to operate in (since client policy is a known-unknown from the
> perspective of site operators), so this is primarily an ease-of-use
> feature.
> 
> I think your proposal to use a policy directive with a set of known value
> strings may also work, but my fear is that it would just end up with most
> servers sending "policy=accept_private" to be safe, which seems like both
> a sharp edge to find and perhaps more bytes than needed.

Got me convinced. And I agree that there will be very few sites that actually use "strict", unless some auditor or PCI decide that this is a good idea. And even if they did, they'd get a lot of pushback, because this actually makes the website works in fewer places. This is not the same as mandating RC4 for fear of the BEAST.

Yoav