[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Read-only vs. read-write proxies (resent as plain text)
From:       Martin Rex <mrex () sap ! com>
Date:       2011-08-03 18:22:42
Message-ID: 201108031822.p73IMg5I015846 () fs4113 ! wdf ! sap ! corp
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]