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

[Jeffrey Walton <[e-mail]>]

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

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)
* Its a real-life problem, and not a theoretical one. It can't be
ignored as if it does not exist.
* 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.

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

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