Re: [TLS] TLS Proxy Server Extension

Yoav Nir <ynir@checkpoint.com> Mon, 01 August 2011 07:16 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 3331721F8548 for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 00:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.483
X-Spam-Level:
X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 8hmmrd-ujC6m for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 00:16:11 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7521F853E for <tls@ietf.org>; Mon, 1 Aug 2011 00:16:10 -0700 (PDT)
X-CheckPoint: {4E366047-8-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 p717G0Ge028225; Mon, 1 Aug 2011 10:16:00 +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; Mon, 1 Aug 2011 10:16:00 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 1 Aug 2011 10:16:00 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Marsh Ray <marsh@extendedsubset.com>, David McGrew <mcgrew@cisco.com>
Date: Mon, 1 Aug 2011 10:15:59 +0300
Thread-Topic: [TLS] TLS Proxy Server Extension
Thread-Index: AcxQGt1e/bSJMaKCSNKc2kOs42RMRg==
Message-ID: <CA5C2B11.4911%ynir@checkpoint.com>
In-Reply-To: <4E364790.3000305@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: "pgladstone@cisco.com" <pgladstone@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: Mon, 01 Aug 2011 07:16:12 -0000

On 8/1/11 9:28 AM, "Marsh Ray" <marsh@extendedsubset.com>; wrote:

>
>> The intent of the authors is to enable TLS to be
>> used when an proxy is present,
>
>But the intent of TLS is to prevent man-in-the-middle attacks, i.e., to
>prevent you from proxying it.
>
>Just because you can exploit it almost reliably with a custom root CA on
>today's clients doesn't mean that it's not deeply contrary to the
>security architecture of TLS.
>
>Design a secure way for the legitimate endpoints to agree to share some
>session key material with you in a way that doesn't impersonate anyone.
>I might even support such an extension (but good luck convincing the
>servers of the world).

Actually, with this extension, the proxy does not need to generate a "fake
certificate". It's fine for the proxy to present a certificate for
"CN=tlsproxy.example.com" and convey the real certificate in the
extension. Of course, clients would have to explicitly trust the proxy,
but that can be added as part of adding support for the extension.

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". Then the servers would be able to reject connections from
proxies. Would that make it more acceptable?

>
>> and to make clients informed about both
>> the proxy and the server, and to provide cryptographically strong
>> authentication of both.
>
>This concept of polyamorous TLS is more radical than its proponents want
>to accept.

Practically, I don't see this happening. The IETF generally does not
radically alter protocols to fit the needs of middleboxes, it's the
middleboxes that have to adapt at least at first. Later we do see how the
active mode of FTP replaces the passive mode because it fits NAT better.