Re: [TLS] TLS Proxy Server Extension

Yoav Nir <ynir@checkpoint.com> Tue, 02 August 2011 06:19 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 5293D11E8088 for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 23:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.494
X-Spam-Level:
X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 5zn9-uX483L5 for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 23:19:56 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B6BB011E8075 for <tls@ietf.org>; Mon, 1 Aug 2011 23:19:55 -0700 (PDT)
X-CheckPoint: {4E37A498-22-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 p726Jwgd029022; Tue, 2 Aug 2011 09:19:58 +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 09:19:58 +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 09:19:57 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: David McGrew <mcgrew@cisco.com>
Date: Tue, 2 Aug 2011 09:19:58 +0300
Thread-Topic: [TLS] TLS Proxy Server Extension
Thread-Index: AcxQ3DOXcF4GIooHTQmDOrRid1N2Gw==
Message-ID: <EF0AF8BF-F940-4CF0-8077-8BFFBB18C3C5@checkpoint.com>
References: <201108012038.p71KcVDj004957@fs4113.wdf.sap.corp> <568A2EE4-21EF-4BD4-BF0E-84D918D0FB76@cisco.com>
In-Reply-To: <568A2EE4-21EF-4BD4-BF0E-84D918D0FB76@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: Tue, 02 Aug 2011 06:19:57 -0000

On Aug 2, 2011, at 3:13 AM, David McGrew wrote:

> 
> On Aug 1, 2011, at 1:38 PM, Martin Rex wrote:
> 
>>> It seems like a major difference that we have is that you expect a
>>> "read only" solution to be viable, while I don't.  A read-only
>>> decryption proxy would be considerably easier to implement correctly.
>>> However, I have zero confidence that a read-only decryption proxy
>>> would not evolve into a read/write proxy, which would introduce very
>>> significant security problems.

Decryption-only through sharing of keys would not work. Some of the processing to be done cannot be done by a passive eavesdropper. For example, if you send me an MS-Word document to my gmail account, and I would like to download it, the way to check for malware is for the proxy to download the entire file, scan it for malware, and then forward it to my computer. A passive eavesdropper would finish collecting the file too late - by then I already have it. An active proxy is necessary.

>> 
>> Such an evolution would have the prerequisite of a client cooperating.
>> 
>> And your solution to not have pretty TLS loose virginity at some point
>> in the future, is to rape her right away, i.e. start with an
>> almighty TLS proxy?
>> 
>> 
>> -Martin
> 
> Those are colorful metaphors.  I assume that if you are willing to  
> deploy such rhetorical excess, you do not actually understand what is  
> being proposed.

I think he's missing the baseline. The baseline is that TLS proxies work well enough that companies deploy then. Even in Europe. There are some downsides to using them: client certificates and PSK suites don't work. Certificate and CA pinning don't work. The user cannot verify the actual server certificate chain. The EV indication is gone. But all these are not blocking administrators from deploying TLS proxies. They may be blocking sites from using client certificates or PSK suites, although there are plenty of other things blocking those (but that's from another thread)

This extension may help with those deficiencies. With or without the extension, the existence (or possibility) of the proxy is visible to the user, because you need to install a CA certificate. A user can choose not to use the corporate network for accessing HTTPS sites where he's not comfortable with having the content inspected. The fact that the server is not similarly given a choice may be a problem, but that is a property of using TLS without client authentication. The extension can help, but only if the proxy uses it.

Yoav