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

[Jeffrey Walton <[e-mail]>]

On Thu, Nov 12, 2015 at 6:39 AM, Yoav Nir <[e-mail]> wrote:
>
>> 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.

+1. And I still can't figure out how some in the W3C think its a good
decision to throw away a specific security context, like a known good
pinset, in favor of a less specific security context, like a trust
store override. I argue they are violating the W3C's when they move
from specific to specific to general since the user wanted the more
specific security context.

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

Data has three state: data at rest, data on display, and data in
motion. Interception in general, and PKP overrides in particular,
destroys the third state of data security. The system is no longer
secure, and it likely no longer adheres to its security requirements.

The fact that the app no longer meets requirements is not always a
death knell. Its is probably OK for some applications in some
circumstances, like Gmail. Its probably also OK for financial
transactions in the US because legislation shifted risk off the
user/consumer. Financial institutions are aware of the risk and they
accept it.

But the loss of security is not acceptable in other contexts. The
other contexts include systems handling medium and high value data
(for organizations that classify their data), like executive
compensation, mergers and acquisitions, pending litigation, corporate
strategies, etc. And it is an unacceptable risk for users in countries
like Iran, where dissidents get put to death or are tortured.

The web security folks don't seem to get the last point: the risk
model changed, and the risk is not acceptable for some. One size does
not fit all. Personally, I don't know what I would do if I condoned
the web security model and someone died because of it. I probably
could not bear it - it would eat me up internally until I died.

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

Right, but that's because we don't have what we need to make the
decision. And its only going to get worse with Secure Origins. That's
where the W3C is using Authentication as Authorizations. But the
interception disgorges the assurances provided with the CA/RA vetting,
so there are no assurances that remain in practice. (I'm side stepping
the whole Authentication is not Authorization foasco. The W3C folks
seem set on traveling down the Java Applet path).

Providing addition information would make the heuristics more
accurate, and lead to a better security posture. Here are the use
cases:

   (1) NOT proxied
   (2) Proxied and advertised as proxied
   (3) Proxied and NOT advertised as proxied

(1) is what everyone hopes for.

(2) allows us to make more informed decisions, and allows us to teach
users with simple rules. (2) could become a simple platform wide
policy setting applied to all browser based applications.

If I had (2), then I could tell my mother or brother to forgo the
guest Wifi network and hop on 3G/4G. But that decision has been taken
away from us in pursuit of the "interception is a valid use case"
goal.

(3) is a red herring, and its a sure sign something is wrong, if
detected. if it goes undetected, then we are at the status quo.

The folks who seem to resist providing more information, allowing user
agents to make better decisions and allowing users to make more
informed decisions are those who are promulgating the "interception is
a valid use case" goal. The NSA, GCHQ and friends does not need to
infiltrate an organization since it has unwitting co-conspirators

Or maybe they are the same folks (they say the devil's greatest
deception was convincing folks he does not exist).

Jeff