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).