Re: [TLS] TLS Proxy Server Extension

Yoav Nir <> Mon, 01 August 2011 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F342D11E80C7 for <>; Mon, 1 Aug 2011 08:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.49
X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGZr9T5lD2ri for <>; Mon, 1 Aug 2011 08:08:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BECB411E80B2 for <>; Mon, 1 Aug 2011 08:08:07 -0700 (PDT)
X-CheckPoint: {4E36CEE5-0-1B221DC2-FFFF}
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p71F89JY000896; Mon, 1 Aug 2011 18:08:09 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 1 Aug 2011 18:08:10 +0300
Received: from ([]) by ([]) with mapi; Mon, 1 Aug 2011 18:08:09 +0300
From: Yoav Nir <>
To: David McGrew <>
Date: Mon, 1 Aug 2011 18:08:17 +0300
Thread-Topic: [TLS] TLS Proxy Server Extension
Thread-Index: AcxQXNL3ArgYUtkXQRyKmg1zfBYong==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 01 Aug 2011 15:08:09 -0000

On 8/1/11 5:19 PM, "David McGrew" <> wrote:

>On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote:
>> 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".
>a further thought in this direction.  The server could sign the
>extension that it gets from the proxy, and that signature could be
>returned to the client, along with the data that was signed.  This
>would give the client a strong confirmation that the server was aware
>of the proxy.   From a security standpoint, this is good.  From a
>deployability standpoint, it would require that servers are modified
>to understand the extension, which is not so good.

That depends on what the clients do with this strong confirmation. For
example, I can see them showing the regular padlock even without the
signature, but displaying the EV indication only when they get it.

I'm also thinking about whether we can get client certificates to work.
The hard problem is that Certificate Verify signs the handshake messages,
and those are not available to the client. I don't think we want to send
all the previous handshake messages in the extension, so getting this to
work would also require a server-side change.