Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

Hi Marsh,

On Jul 29, 2011, at 8: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.
>
> 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!

Important clarification: we have not proposed any standards action, we  
have requested comments on a draft.  I felt that the approach outlined  
in the draft deserved to be discussed even though it does not address  
the issue of client authentication to the server.  I would strongly  
prefer a solution that works with client certificates, if one can be  
worked out.   (I think the ideal security goal here would be something  
like three-party mutual authentication and authentication checking.   
If we are willing to be invasive to TLS, we could do something like  
that.  If C/S/P each issued nonces and signed all of the nonces, that  
would get us most of the way there.   That sounds like an interesting  
design exercise, but I am skeptical that we could get broad  
deployment.  How close we can get to that goal is something worth  
exploring.)

In the absence of a client certificate, the proxy extension does  
improve security, because it restores server authentication and  
authorization, and that operation is essential when the client is  
using password-based authentication  to the server.

David

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