Re: [TLS] TLS Proxy Server Extension

[Yoav Nir <[e-mail]>]

On Jul 29, 2011, at 11:22 AM, Marsh Ray wrote:

> On 07/26/2011 10:01 AM, David McGrew wrote:
>> 
>> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00
> 
>> The ProxyInfo extension only provides information about proxies to
>> the client; it does not provide any information to the server about
>> either the client or other proxies on the path.  This is acceptable
>> when there are no client certificates in use, which is (regrettably)
>> common in practice.  It would be possible to generalize the ideas in
>> this note to also provide information to the server about the client
>> and other proxies on the path.  Nonetheless, that goal is out of
>> scope for this note.
> 
> It's good that the draft is explicit about what is not being provided to
> to the server.
> 
> But, please, won't somebody think of the poor servers?
> 
> As someone who works on the security of an authentication service
> delivered through TLS, I feel the need to oppose the standardization of
> functionality with the potential to undermine the security of our service.

This draft does not invent TLS proxies or even standardize them. It invents a way for the client to recover some of the information that is lost because of the existing use of TLS proxies.

> It was once said that the driving purpose of the design of SSL was to
> make users *feel* secure enough to be comfortable entering their credit
> card number on the web and I've seen little or no evidence to refute
> that claim. In this model, all the paranoia is expected to reside with
> the user.
> 
> One of the unfortunate artifacts of the resulting design is that the
> server has no way to prove the nonexistence of a MitM, he can only hope
> that the client will do a good job of this. We all know how well this
> works when put to the test by an active attacker. Client certificates
> are currently the only tool available for server admins to participate
> in preventing this important class of attacks. The authors of this draft
> seem to feel the relative infrequency of client certificate usage is
> "regrettable", yet they propose standardizing a scheme which will break
> them entirely!

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", so we probably don't want that at all.
But client certificates are already broken now behind a TLS proxy. This draft does not make this worse. It does mean that other things that got broken, like HSTS and EV can be unbroken.

> Consider, for example, the scenario which was described to me by someone
> in the retail sector. She was responsible for auditing security policies
> for a retail credit card website. They interpreted the relevant laws and
> industry regulations to mean that they were obligated to intercept
> employee web browser usage to monitor for and block various forms of
> undesired content. However, employees may also have personal credit
> cards with the same issuer, the statements of which they might sometimes
> access from their desk at work. But the organization considered itself
> forbidden from snooping on that traffic.
> 
> I don't know if or how they got it sorted out, my point being only that
> there are several parties involved here and it's not clear at all the
> circumstances under which one party may have an absolute right to
> impersonate, decrypt, or MitM the traffic even between its own clients
> and servers.

Operating a MitM requires issuing fake certificates from a CA that is not trusted by any browser out of the box. 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. I agree that there is an ethical issue with having the CA certificate pre-installed on the "company laptop" without telling the user.

> 
> If you operate a financial or government site, you may be under various
> legal obligations to ensure that certain information is transmitted only
> to the intended recipient. Today this is commonly done (weakly) with
> non-client certificate HTTPS websites. If or when MitM interception
> becomes standardized and widespread it will obligate the use of client
> certificates to satisfy this requirement while at the same time breaking
> their functionality entirely.

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

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.

> Any standardization of MitM or interception functionality must take into
> account the requirements of the server operators as an equal party and
> stakeholder in the security of the connection.

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.

Yoav