Re: [TLS] TLS Proxy Server Extension

[Marsh Ray <[e-mail]>]

On 07/29/2011 11:52 AM, Yoav Nir wrote:
>
> This draft does not invent TLS proxies or even standardize them.

The IETF defines no such thing as a "TLS proxy". I don't even see how 
such a thing can be defined without violating some basic guarantees of 
the protocol, but I'm open to being educated on that.

> It invents a way for the client to recover some of the information that
> is lost because of the existing use of TLS proxies.

I'm really sympathetic to the necessity of the lesser evil in practice.

But "TLS proxies" currently work poorly today because they are 
underspecified and they violate certain protocol assumptions. Sometimes 
they end up weakening security and breaking higher-layer stuff.

> I can see how this draft could be extended to support client
> certificates, but that would require changes to the server as well,
> and a change to the state machine that elevates this draft in the new
> taxonomy from "trivial" to "significant",

That would be a good thing in my view because the underlying changes 
actually are significant.

> so we probably don't want
> that at all. But client certificates are already broken now behind a
> TLS proxy.

What is this "TLS proxy" of which you speak? I see no SHOULDs or MUSTs 
or which apply to it, much less any cryptographic guarantees about it.

More importantly, what is its security model?

All I see usually amounts to "convince the client to install our trusted 
root and then the MitM can get away with almost anything". Perhaps this 
draft is admirable in that it defines a mechanism with which the MitM 
MAY choose to communicate certain info to the client, but I feel it is 
handwaving over the deeper questions and tacking features on top of an 
architecture which isn't really defined at all.

> This draft does not make this worse.

But it does, it endorses the brokenness as a protocol standard.

> It does mean that
> other things that got broken, like HSTS and EV can be unbroken.

TLS is being changed at a fundamental level, it's not a little tweak 
that just needs a little tweak to change it.

> Operating a MitM requires issuing fake certificates from a CA that is
> not trusted by any browser out of the box.

Has anyone ever asked the rightful domain holders how they might feel 
about someone minting certificates with their name on them?

> The user will get the
> warning messages from the browser unless they choose to trust this
> CA, or are required to do so by company policy. In both cases the
> existence of the MitM is known to the user.

Right, it's TLS operating properly as designed to prevent MitM attacks. 
If only TLS had been designed such that the server could resist them as 
well!

> I agree that there is an
> ethical issue with having the CA certificate pre-installed on the
> "company laptop" without telling the user.

Honestly, I don't see that as the big issue in general. Such laptops 
commonly have a wide variety of spyware installed already and employees 
should have no expectation of privacy on it, IMHO.

But note that the web site being accessed is not a party to that 
employment contract!  Lying to the web browser about the authenticity of 
the server's identity could be viewed as lying to the server about the 
absence of a MitM. Oh what a tangled web we weave!

> That's the beauty of this draft. If MitM boxes support it, it will
> expose (to the browser) the existence of a MitM even without user
> certificates.

Couldn't that be done today without a protocol change by looking at the 
issuer?

> Maybe WebSec should standardize a header that says
> "no-tls-proxies". A client that detects a proxy and receives this
> header breaks the connection and shows a red warning screen.

Why wouldn't the MitM simply strip the header while he was at it?

> Fortunately today many people have an alternative to "company
> network". If the company network has a MitM and you don't want it to
> see your credit card number or scan the attachments you get to your
> gmail account, just surf from your phone. Just as you would call from
> your phone if the company may listen in on phone conversations.

I agree that the best course of action for the user is to use a network 
which does not have a MitM policy (or possibly establish a secure tunnel 
to one).

> Stealthy MitM are possible today with company computers without any
> standardization effort by the IETF. We can make it possible for
> clients and MitM to play nice - inform the browser, etc.

I don't want them to play nice. They're broken now because they violate 
a fundamental principle of the security model: clients trust CAs to 
accurately represent the identity of the target domain (don't laugh :-).

Making them 'play nice' appears to reduce my effective security as a 
server operator.

- Marsh