Re: [TLS] TLS Proxy Server Extension

["Kemp, David P." <[e-mail]>]

WARNING: contains banned part

--- Begin Message ---

From: David McGrew
> On Aug 1, 2011, at 9:15 AM, Martin Rex wrote:
>>  If the proxy terminates the clients
>> TLS connection and establishes a new connection to the real server,
>> then it will have to impersonate the real server to the client
>
> No, that's not right, at least not if "impersonate" is meant in the  
> cryptographic sense.   If "impersonate" is meant in the sense that a  
> proxy can modify the traffic passing through it, then yes, that is a  
> goal for the system; it is a requirement if TLS is to be used to  
> protect communications when an HTTP proxy is present (for many types  
> of proxies).

A TLS connection between S and C provides integrity protection (which by
definition is impossible without authentication): C knows that data it
receives is identical to that sent by S.

How do you propose to define roles that extend integrity properties to a
three-party protocol?  C must know that data it receives from S is sent
by S, with no insertions or deletions.  And that data it receives from P
was sent by P with no insertions or deletions.  "Modifying" traffic is
fundamentally incompatible with data integrity - the concept is
meaningless.  There must be either two independent unmodifiable data
streams between C and S and between C and P, or there must be a single
stream between C and P, where C trusts P to be the data provider without
knowing or caring where P got the data in the first place.  That is what
is meant by impersonation.

In an application protocol it would be appropriate to tag sections of
data that have different properties and originated from different
sources - think chat room, or a portion-marked word document.  TLS
claims to protect an application-independent data stream - I have no
idea how you define semantics of a 3-party "session" without becoming
application-specific.

Dave

--- End Message ---