Re: [TLS] TLS Proxy Server Extension

David McGrew <> Tue, 26 July 2011 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5565211E80EC for <>; Tue, 26 Jul 2011 10:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Of1aNelv2zt0 for <>; Tue, 26 Jul 2011 10:38:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7BA0811E8073 for <>; Tue, 26 Jul 2011 10:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3877; q=dns/txt; s=iport; t=1311701921; x=1312911521; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=ab1F44YxC3HLmPP89wiwRTR8HEtAvNj4RpHw3Dv0ALc=; b=mV1d6Wh4H33idzBfcn/kbrFoRmuEkqz1rzvglpyjvkUcqjpoVSkL5amx oFU0m3uJXWfdvGsoKT5J9Nkbo0fTyGEyyEh4rQXoZDreVabBmhxRTtpUg OD0bUbvvFdIOWWNCByJa56AWCkbLC8dhzXL6m69bRAsp2laaMaDQrKRQ7 I=;
X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6571450"
Received: from ([]) by with ESMTP; 26 Jul 2011 17:38:41 +0000
Received: from [] ([]) by (8.14.3/8.14.3) with ESMTP id p6QHcd8i004161; Tue, 26 Jul 2011 17:38:40 GMT
Message-Id: <>
From: David McGrew <>
To: "Yngve N. Pettersen" <>
In-Reply-To: <op.vy8foys4kvaitl@lessa-ii.oslo.os>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 26 Jul 2011 10:38:39 -0700
References: <> <op.vy8foys4kvaitl@lessa-ii.oslo.os>
X-Mailer: Apple Mail (2.936)
Cc: Philip Gladstone <>,
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, 26 Jul 2011 17:38:42 -0000

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?


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



> On Tue, 26 Jul 2011 17:01:31 +0200, David McGrew <>  
> 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
>> _______________________________________________
>> TLS mailing list
> -- 
> Sincerely,
> Yngve N. Pettersen
> ********************************************************************
> Senior Developer                     Email:
> Opera Software ASA         
> Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
> ********************************************************************