Re: [TLS] TLS Proxy Server Extension

Anders Rundgren <> Tue, 02 August 2011 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3349221F8EB8 for <>; Tue, 2 Aug 2011 02:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.555
X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T7a5mlOh5Vkh for <>; Tue, 2 Aug 2011 02:51:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F326921F8EB6 for <>; Tue, 2 Aug 2011 02:51:02 -0700 (PDT)
Received: from [] ( by (8.5.133) (authenticated as u36408181) id 4E305E970017339B for; Tue, 2 Aug 2011 11:51:10 +0200
Message-ID: <>
Date: Tue, 02 Aug 2011 11:51:06 +0200
From: Anders Rundgren <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS Proxy Server Extension
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2011 09:51:05 -0000

The discussion in a nutshell:

On 2011-08-01 21:15, David McGrew wrote:
> On Aug 1, 2011, at 9:15 AM, Martin Rex wrote:
>> David McGrew wrote:
>>> Again, it seems that you do not quite understand what we are trying  
>>> to
>>> achieve.   There is current practice that uses proxies in a way that
>>> is bad for clients (and you outline many of the reasons below).  We
>>> aim to improve the situation for clients and the security of the
>>> overall solution.  One important point: it is possible to design a
>>> solution in which the proxy does not contain a CA.
>> You're trying to give the proxy the authority to impersonate
>> _every_ server.
> On the contrary, the goal here is to not have the proxy impersonate  
> any other device, at least not impersonate in the cryptographic sense.
>>  Whether it is through an super-CA-cert or whether
>> you're extending the protocol so that the client believes a forwarded
>> certificate with _no_ proof-of-posession for that cert is a mere
>> implementation detail, and has no impact of the size of the security
>> problem that you want to newly create.
> It's hard to parse that sentence, but if I understand you right, you  
> think that it is important for the client to have a strong assurance  
> that the subject of the server certificate is an active participant in  
> the session.   I agree that is a highly desirable property.
> I think the right theoretical approach to analyzing this sort of  
> protocol would be to start with a formal model of TLS as a two-party  
> authentication protocol, and extend it to accomodate a three-party  
> system with the appropriate role definitions.  Fortunately, only the  
> authentication aspects need to be considered, and some of the key  
> establishment goals can be ignored, which makes the analysis easier.   
> If we had the freedom to design the system from scratch, the obvious  
> approach would be to have C, S, and P each issue nonces that get  
> signed by each other party, along with the other data that gets  
> currently signed, and indication of the role of each signer.  What is  
> most interesting is: how close can one get to this ideal protocol by  
> extending TLS?
>>> Propagating TLS session key material is a worse idea for a lot of
>>> reasons.  It would be a fragile solution in which easy-to-make
>>> implementation mistakes could undermine security.
>> I'm sorry, but that is a completely bogus claim.
>> If the proxy is terminating both TLS connections, it will have access
>> to traffic encryption and mac keys of both connections can can leak
>> those just as easily.  Sharing the traffic encryption keys will not
>> make this any worse.
>>> It would require considerable new implementation work.
>> You mean because it would require an additional network channel to
>> talk to the proxy? yes.  It can not happen "by accident".
>>> It would make crypto validation considerably harder if not  
>>> impossible.
>> Nope.  That is orthogonal.
> On the above three points: allowing a proxy to coordinate betwen two  
> TLS sessions allows one to preserve most of the TLS protocol and  
> implementation.   In contrast, a solution that propagates session keys  
> will require new implementation work for the data plane, state  
> management, and so on.  If the proxy attempts to modify the session,  
> all sorts of significant crypto problems will crop up.  There will be  
> HTTP proxies that expect to modify the traffic, and it would be unwise  
> to expect that a proxy implementer would respect the injunction to not  
> modify the session, if a specification for session key propagation  
> were developed.
> It seems like a major difference that we have is that you expect a  
> "read only" solution to be viable, while I don't.  A read-only  
> decryption proxy would be considerably easier to implement correctly.   
> However, I have zero confidence that a read-only decryption proxy  
> would not evolve into a read/write proxy, which would introduce very  
> significant security problems.
>>> If it aimed to preserve end-to-end authentication, it would be
>>> fundamentally incompatible with Authenticated Encryption in general
>>> and the AEAD facility in TSL 1.2 in particular, and it would probably
>>> end up getting misused and abused in practice.
>> Correct, the use of AEAD would break the security, since this mode  
>> does
>> not use seperate traffic encryption and mac keys.  Personally, I  
>> consider
>> AEAD a bad idea, so I don't mind disabling these cipher suites when
>> traversing such a proxy.
> Your personal opinion on AEAD goes against a lot of theory and  
> standards work of the last decade.  Have you considered providing your  
> criticisms in writing?
>>> If it did not aim to preserve end-to-end authentication,
>>> then it would require considerable changes to the TLS protocol, to
>>> prevent keystream insertion attacks and keystream re-use.  Perhaps
>>> worst of all, it would create a mechanism that could more easily be
>>> abused; a server could (mis)use it and give away session keys without
>>> the knowledge or consent of the client.
>> I have no clue what you mean.
> Then think about the situation in which the proxy has the encryption  
> keys and the authentication keys, and yet there is just a single TLS  
> session, and consider the changes that would be needed to the TLS  
> protocol in order to retain security even when the proxy is modifying  
> the session data.
>>  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).
>> in any case
>> and will always have all keying material available to do anything bad
>> to either or both peers.
> In any solution in which a proxy has session keys, it is required that  
> the client and server trust the proxy to do the right thing.
> One thing that really surprises me about your line of thinking is the  
> fact that you feel that a protocol that can propagate a session key to  
> a proxy would encourage better respect of privacy.  A server could use  
> that protocol to pass keys to a middlebox without the knowledge or  
> consent of the client, and the client could do so without the  
> knowledge or consent of the server.   With the key propagation  
> approach, there is very little that you and I can do to prevent this  
> sort of behavior.  (Side note: one could design a solution that  
> required both the client and server to approve of the presence of the  
> proxy; in fact, I've been through that design exercise.  However, it  
> would be easy for implementers to ignore the stipulation that both  
> sides accede to the proxy, and they would be motivated to do so.)
> I think we've both stated our views well enough that people have a  
> reasonable idea of what we think.   It would be good to let others who  
> care about the topic have a chance to offer their own thoughts.
> David
>> So security-wise, the TLS proxy that you are proposing is at the
>> far end of badness, there is _nothing_ that can possibly be worse,
>> but a few thinghs might be *MUCH* better.
>> -Martin
> _______________________________________________
> TLS mailing list