Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

Hi Yngve,

On Jul 26, 2011, at 8:23 AM, Yngve N. Pettersen wrote:

> Hi,
>
> I just skimmed the start of the document
>
> I assume, from context, that your use case is for proxies that  
> perform an authorized MITM "attack" on the TLS connection by issuing  
> specific "fake" certificates for the site you are connecting to,  
> decrypting/re-encrypting the encrypted data, and not a proxy that  
> uses the normal HTTP CONNECT request and just passes packets back  
> and forth and the TLS connection is end-to-end. Right?
>

right.


> If so, that should perhaps be made clearer in the introduction and  
> abstract, possibly by using a different term for the proxy? My  
> association with "proxy" is generally the ordinary CONNECT packet  
> forwarding proxy, not the MITM proxy.

Yes, I think so.

>
> IMO, when you authorize a proxy to MITM your connections, you also  
> implicitly accept the security policies of the proxy, and whatever  
> encryption and certificate it trusts.
>

Right, this is what happens at present.

> As an alternative way forward, might it not be an equally good way  
> forward to require the proxy to either negotiate the same encryption  
> methods with the client as it negotiated with the server, or  
> alternatively, only offer the mutually acceptable set of cipher  
> suites for the client and proxy (perhaps with an addition for better  
> suites, allowing an encryption upgrade)?

Agreed that it is a good idea for the proxy to offer a subset of the  
ciphersuites offered by the client.  But this only covers the crypto  
policy - it doesn't address the problem of how the client can decide  
whether or not it trusts the server on the other side of the proxy,  
for the particular application in use.  Section 2 of the draft  
outlines this in some more detail.

As a side note, I think that for almost all purposes, the ciphersuites  
offered by the proxy should be a subset of those offered by the  
client.  The one scenario where we might decide that it is a good idea  
to allow the proxy to offer other ciphersuites is the case in which  
the client and server do not have a mutually acceptable ciphersuite;  
in this case the proxy is acting like a translator.   I am not  
thrilled about this scenario, because it implies that there is lack of  
interoperability which I think should be avoided if/when possible, but  
I do not think that it would make sense to exclude the scenario.

thanks,

David

>
>
> On Tue, 26 Jul 2011 17:01:31 +0200, David McGrew <[e-mail]>  
> wrote:
>
>> Hi,
>>
>> I would like to request feedback on a new draft that Philip  
>> Gladstone and I put together, which aims to solve some of the  
>> security problems that happen when there is a (HTTP) proxy present  
>> and TLS is in use.   The approach is to require the proxy to  
>> provide the client with additional information that the client can  
>> use to make a well-informed decision about the security of the  
>> session.  This draft was put together too late to request a slot at  
>> the WG meeting this week, but if you have thoughts on either the  
>> goals or the mechanism, we can discuss either in person or on the  
>> list.
>>
>> David
>>
>> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> -- 
> Sincerely,
> Yngve N. Pettersen
>
> ********************************************************************
> Senior Developer                     Email: [e-mail]
> Opera Software ASA                   http://www.opera.com/
> Phone:  [phone]              Fax:    [phone]
> ********************************************************************