Re: [TLS] TLS Proxy Server Extension

"Yngve N. Pettersen" <> Tue, 26 July 2011 15:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BBD211E812C for <>; Tue, 26 Jul 2011 08:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wl3Vg8OMFIVQ for <>; Tue, 26 Jul 2011 08:23:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B204811E811C for <>; Tue, 26 Jul 2011 08:23:11 -0700 (PDT)
Received: from lessa-ii.oslo.os ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6QFN2Cd013110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jul 2011 15:23:05 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To:, "David McGrew" <>
References: <>
Date: Tue, 26 Jul 2011 17:23:12 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <>
Organization: Opera Software ASA
Message-ID: <op.vy8foys4kvaitl@lessa-ii.oslo.os>
In-Reply-To: <>
User-Agent: Opera Mail/10.62 (Win32)
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 15:23:13 -0000


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.

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.

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  

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

Yngve N. Pettersen

Senior Developer                     Email:
Opera Software ASA         
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01