Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?

[Yoav Nir <[e-mail]>]

> On 16 Nov 2015, at 5:54 AM, Jeffrey Walton <[e-mail]> wrote:
> 
>> No certificate marking is needed, though.  Clients could invoke alternative certificate processing when a certificate name match fails but the certificate chains to a trust anchor marked as "trusted for proxy."
>> 
> You will have to forgive my ignorance... For user agents and other
> software that conforms to RFC 7469 and provides the overrides, how are
> they supposed to know when to break a known good pinset if its not
> signaled? That is, how do they differentiate between the "good" bad
> guys and the "bad" bad guys.
> 
> Examples:
> 
>  Corporate DLP - ACME, LLC sets Proxy key usage for subordinate
>      and server certificate. User agent allows an override to the Pinset
>      in accordance with RFC 7469 because they declared the intent and
>      confirmed with the user.
> 
>  Diginotar - Bad guy starts minting server certificates. Proxy is
>      not set in subordinate CA or server certificate. The user agent
>      refuses to break the known good pinset according to RFC 7469.
> 
> And RFC's 7469 {SHOULD NOT|MUST NOT} logging requirement can be lifted
> or refined so the failures can be reported instead of making user
> agents complicit in the cover-up.
> 
> RFC 7469's overrides opened a can of worms, but its probably best in
> the big picture. This stuff has always been going on and allowed to
> fester behind the scenes in a "don't ask don't tell" fashion. Now that
> its been brought to the fore-front, it can be dealt with accordingly.
> 

Before RFC 7469 (pins in HTTP) there were pre-loaded pins for a select group of servers. The policy of Chrome at the time was to allow “wrong” keys whenever the root of trust was not part of the default set that comes with the operating system. This allowed for trust anchors installed specifically for proxy to sign certificates for mail.google.com. The unfortunate side-effect was that it allowed any corporate CA to also sign such certificates, which it shouldn’t. 

It would be nice if a trust anchor could be marked as “for proxy” vs “just another CA”, but no OS or browser provides that distinction.

Yoav