Subject: [TLS] Read-only vs. read-write proxies (resent as plain text)

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Aug 2011 16:07:27 +0300

First, I strongly dislike this type of corporate proxies, and would take 
the German constitutional regime any time. But in other free countries, 
this scenario is perfectly OK (legal and socially acceptable), and we 
need to cater for this use case.

If we break the TLS architecture as proposed here, we will have killed 
forever any chance of TLS-level mutual authentication (TLS-PSK, 
TLS-SRP). This is IMHO too high a price for the benefits of R/W proxies.

I have not been convinced by David's explanation of the need for R/W 
proxies, nor by Yoav's use case. A malware detection proxy can drop the 
connection precisely at the time malware is detected: the Word document 
would not be received in its entirety and would be rejected by the 
client. Even if a partial document is acceptable (e.g. JPEG), a partial 
malware is (hopefully) not effective.

What are the reasons proxies need to modify the stream?

- Purely informational app-level insertion, of the "sent from my iPhone" 
kind. The *client* has a trusted channel to the proxy, and if this is 
needed, the client can insert this stuff.

- Security-specific signaling, of the "no spam detected here" kind. The 
server wouldn't trust the proxy with that anyway (this is a client-side 
proxy!) so this is not useful.

- Malware detection: just ax the connection.

- Other reasons?

Lastly, it is important that the server should know of the proxy's 
presence, even if the indication relies on the client's and/or the 
proxy's good will. I can think of banks who still use passwords for 
client auth, but would not allow logins where that password is clearly 
intercepted by a third party.

Thanks,

     Yaron

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 20:22:42 +0200 (MEST)

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