Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote:

>
>
> On 8/1/11 9:28 AM, "Marsh Ray" <[e-mail]> wrote:
>
>>
>>> The intent of the authors is to enable TLS to be
>>> used when an proxy is present,
>>
>> But the intent of TLS is to prevent man-in-the-middle attacks,  
>> i.e., to
>> prevent you from proxying it.
>>
>> Just because you can exploit it almost reliably with a custom root  
>> CA on
>> today's clients doesn't mean that it's not deeply contrary to the
>> security architecture of TLS.
>>
>> Design a secure way for the legitimate endpoints to agree to share  
>> some
>> session key material with you in a way that doesn't impersonate  
>> anyone.
>> I might even support such an extension (but good luck convincing the
>> servers of the world).
>
> Actually, with this extension, the proxy does not need to generate a  
> "fake
> certificate". It's fine for the proxy to present a certificate for
> "CN=tlsproxy.example.com" and convey the real certificate in the
> extension. Of course, clients would have to explicitly trust the  
> proxy,
> but that can be added as part of adding support for the extension.

Agreed.  It may also be desirable to add an authorization attribute to  
the certificate to explicitly label it as a proxy certificate.

>
> As for servers, it's possible to change the tls-proxy format in
> ClientHello to have a "role" field that could be either "client" or
> "proxy". Then the servers would be able to reject connections from
> proxies. Would that make it more acceptable?

This is a good idea.  It does not provide strong authentication of who  
the proxy is, but it does inform about its presence.

David

>
>>
>>> and to make clients informed about both
>>> the proxy and the server, and to provide cryptographically strong
>>> authentication of both.
>>
>> This concept of polyamorous TLS is more radical than its proponents  
>> want
>> to accept.
>
> Practically, I don't see this happening. The IETF generally does not
> radically alter protocols to fit the needs of middleboxes, it's the
> middleboxes that have to adapt at least at first. Later we do see  
> how the
> active mode of FTP replaces the passive mode because it fits NAT  
> better.
>
>