Re: [TLS] Read-only vs. read-write proxies (resent as plain text)
Martin Rex <mrex@sap.com> Wed, 03 August 2011 18:22 UTC
Return-Path: <mrex@sap.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 9522621F8ADE for <tls@ietfa.amsl.com>; Wed, 3 Aug 2011 11:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Level:
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 f7ubrr1u2ox3 for <tls@ietfa.amsl.com>; Wed, 3 Aug 2011 11:22:34 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC621F8ACC for <tls@ietf.org>; Wed, 3 Aug 2011 11:22:32 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p73IMh9Q010241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 20:22:43 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201108031822.p73IMg5I015846@fs4113.wdf.sap.corp>
To: yaronf.ietf@gmail.com
Date: Wed, 03 Aug 2011 20:22:42 +0200
In-Reply-To: <4E39480F.4020105@gmail.com> from "Yaron Sheffer" at Aug 3, 11 04:07:27 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Read-only vs. read-write proxies (resent as plain text)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 03 Aug 2011 18:22:34 -0000
We do have server-side proxies ("reverse proxies") for TLS for at least 10 years, and they do not need to subvert TLS in an way in order to function. It is trivial to create similar client-side proxies for programmatic(!) clients where the client credentials are either held by or forwarded to the client proxy for all situations similar to the backend, where client and TLS client proxy are software components working under full control of the exact same entity. But having end users with personal, end-user credentials use a web browser on a machine that is so sensitive that it needs to be carefully watched is an extremely stupid idea ("gross negligence" in legal terms), that I do not think we should try to facilitate such stupid ideas in our protocols. The logical equivalent of a server-side reverse proxy would be a client-side remote desktop approach. On some platforms, this even works with PKI crypto tokens / smartcards. Sample scenario for Microsoft Windows, works with the installed base: - end user is in posession of a personalized PKI crypto token - end user uses "Remote Desktop / Microsoft Terminal Services Client" to dial from a sensitive machine into a monitored terminal server machine that is capable of accessing the internet - end user starts MSIE on terminal server and uses TLS client cert authentication with his PKI crypto token (access to the crypto token is forwared by Remote Desktop). Running the browser on a terminal server machine with local filtering/ monitoring is much more reasonable and resposible that accessing the internet with a web browser from a sensible machine, because the is not, and there never will be, a web browser without gaping security holes. -Martin PS: I don't know whether you listend to the IETF plenaries. In one of the studies it was reported, that the fraction of malware-infected client-machines that had an AV-product installed was higher than the fraction of malware-infected machines with no AV-product. (something which should not come as a surprise, and should be predictable from how the design of AV-solutions. AV-solutions are only statistically successful, being able to prevent old, known malware to spread further and cause epidemics/pandemics, but protect very poorly against new malware and targetted attacks (see Stuxnet).
- [TLS] Read-only vs. read-write proxies (resent as… Yaron Sheffer
- Re: [TLS] Read-only vs. read-write proxies (resen… Martin Rex