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

[Peter Bowen <[e-mail]>]

On Tue, Nov 24, 2015 at 10:04 AM, Jeffrey Walton <[e-mail]> wrote:
>> No, the least disruptive option is to leverage existing standards without modification to implement both the signal and the verification.  Frex., adding a DANE record check to TLS server authN verification.
>>
>
> OK, thanks Tim.
>
> So let me wrap this up... What is the IETF and/or PKIX going to
> provide us with to discern between authentic servers and
> proxied/intercepted connections now that Public Key Pinning with
> Overrides is here?
>
> What do I tell my developers?

I'm a little lost.  What are you trying to achieve?  Assuming your
developers are writing a client app, I see several scenarios:

1) You have a client application relying on a shared trust store.  The
proxy is configured to issue certificates signed by something in the
trust store.  In this case validation works as normal.

2) Validation passes, but there are additional post-validation
constraints validation info (e.g PKP).  The constraints fail. In this
case, you check the trust store to see if the CA signing the cert is a
"system" CA or a "user" CA.  If user, ignore PKP.

3) You have a client app that has its own trust store.  The proxy's
certificate is not signed by a CA in your list.  Validation fails.

4) The proxy is signing with an unknown certificate.  Validation fails.

In none of the scenarios does it help to have a flag for 'this is a
proxy'.   The only place it would help is if you wanted to only allow
overrides where the User CA explicitly indicated it was trying to
override.  However I can't imagine when the CA would not set this.

Thanks,
Peter