IETF Logo Mail Archive

Re: [TLS] TLS Proxy Server Extension

Yoav Nir <ynir@checkpoint.com> Tue, 02 August 2011 12:18 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8173321F8B3D for <tls@ietfa.amsl.com>; Tue, 2 Aug 2011 05:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.497
X-Spam-Level:
X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWZ8Wlgo9Tus for <tls@ietfa.amsl.com>; Tue, 2 Aug 2011 05:18:49 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C27921F8E17 for <tls@ietf.org>; Tue, 2 Aug 2011 05:18:37 -0700 (PDT)
X-CheckPoint: {4E37F892-E-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p72CIArL007667; Tue, 2 Aug 2011 15:18:10 +0300
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 2 Aug 2011 15:18:10 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 2 Aug 2011 15:18:10 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Marsh Ray <marsh@extendedsubset.com>
Date: Tue, 02 Aug 2011 15:18:11 +0300
Thread-Topic: [TLS] TLS Proxy Server Extension
Thread-Index: AcxRDj2jP8BNBdf7RCKEzB6nCRFniA==
Message-ID: <CA5DAA48.4A6E%ynir@checkpoint.com>
In-Reply-To: <4E36C607.4040504@extendedsubset.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
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 <pgladstone@cisco.com>, David McGrew <mcgrew@cisco.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Proxy Server Extension
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 12:18:50 -0000

On 8/1/11 6:28 PM, "Marsh Ray" <marsh@extendedsubset.com> wrote:

>On 08/01/2011 10:08 AM, Yoav Nir wrote:
>>
>> 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.
>
>You could just send the MD5/SHA-1/SHA-256 hashes of the messages, which
>is what the client cert signs.

Alternatively, we could have the client sign its own ClientHello, and send
that in the Certificate Verify payload. The proxy would send the client's
ClientHello in the extension, and forward the client's CertificateVerify.
Then we don't have the escalation of privilege.

v2.23.0 | Report a Bug | By Email