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

[Yoav Nir <[e-mail]>]

> On 12 Nov 2015, at 12:47 PM, Jeffrey Walton <[e-mail]> wrote:
> 
>>> I've been through RFC 5280 and 6125 looking for a treatment of the
>>> subject matter, but I could not find it. I would expect it to show up
>>> somewhere, like KU or EKU, but the bits appear to be missing.
>>> 
>>> How do we differentiate authentic servers from proxies performing TLS
>>> interception?
>> 
>> There is no way to mark a certificate as an “interception" (or “proxy” or “fake”) certificate. Attempts to mark either the certificate or the TLS handshake were not successful in the IETF, because we do not facilitate interception in protocols, lawful or otherwise.
> 
> Thanks Yoav, that's interesting. I thought that too until RFC 7469
> came along and got approved with the overrides.

But as you note, the overrides are obscured.

> Now that the IETF has provided a standard with the overrides, maybe
> its time to revisit the previous decision. There are a few reasons:
> 
> * The dominate RFC 7469 players claim "interception is a valid use
> case" (citing the W3C's Priority of Constituencies)

“consider users over authors over implementors over specifiers over theoretical purity.”
But what are the interests of the users? Many would claim that not having their traffic intercepted is a higher priority. Unfortunately the users don’t participate in either W3C or IETF, so we have others make claims on their behalf.

> * Its a real-life problem, and not a theoretical one. It can't be
> ignored as if it does not exist.

But what is the problem? That proxying is possible? That proxying is not visible to the user? That proxying is not visible to the server?  Modifying the certificate does not solve that last one anyway.

> * Reusing key bits for both server authentication and
> proxying/interception violates secure design and architecture. Its a
> deep, fundamental flaw.
> 
> I'm particular bothered by the third item. Reusing the KU/EKU bits
> violates at least three of the secure design principals outlined by
> Saltzer and Schroeder's "The Protection of Information in Computer
> Systems". More informed readers (like you, DKG, Guttman, etc), can
> probably find more violations.

Perhaps, but they all boil down to your subject line, that the browser/client cannot tell that the proxy is there without heuristics.

>> The heuristic employed by some browsers and alluded to in section 2.6 of RFC 7469 is to treat certificates that chain to a trust anchor that did not come pre-installed with the operating system or browser as interception certificates, but this heuristic is only valid in the context of key pinning - it would generate too many false positives in general use.
> 
> It almost sounds like they are trying to get half pregnant...
> 
> Regarding false positives, I've found the opposite. We have
> implemented Guttman's security diversification techniques in a few
> libraries and products, and they are almost always spot-on. The trick
> is we need a secure distribution channel to keep a handful of security
> parameters up-to-date. All the App stores claim to have one, so we are
> in a good position (and side-loading is trivially secure because it
> provides a location limited channel).

What I meant by false positives is that some organizations (corporate, educational or government networks as well as others) deploy their own CA, add this CA to the trust anchor store of devices, and use certificates from this CA for internal servers. A heuristic that marks all certificates not from the public web PKI as “proxied” will inevitably misidentify such internal servers as proxied. 

> Why was the word "override" removed from RFC's 7469 Draft 21? It
> appears the effect was to make the interception more obscure. I would
> have expected it to go the other way - make it more pronounced to
> ensure the risk is noted by architects evaluating the standard.
> Putting the word "override" in the title seemed like a more
> appropriate action because it has such a negative effect on the
> security of the system.
> 
> Jeff