Subject: [TLS] Read-only vs. read-write proxies

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Aug 2011 09:11:41 +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 having 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: Marsh Ray <[email-masked]>
Date: Wed, 03 Aug 2011 10:38:53 -0500

On 08/03/2011 01:11 AM, Yaron Sheffer wrote:
>
> 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 [...] What
> are the reasons proxies need to modify the stream?

But isn't this distinction between RO and RW interception the kind of
thing only a transport layer crypto engineer could consider meaningful?

I mean, look at how authentication is handled on the web: form-submit
passwords and secret session cookies. If the MitM in practice learns all
the plaintext credentials of the end user, of what consolation is it to
say that he couldn't actually modify some particular byte stream?
"Other than that, Mrs. Lincoln, how did you like the play?"

In Tunisia, for example,
the attacker modified the web page only just enough to capture the
credentials. His goal was to read the data in transit and the script
injection was simply a means to that end.
http://www.cpj.org/internet/2011/01/tunisia-invades-censors-facebook-other-accounts.php

Perhaps there are protocols where it makes a meaningful difference, but
for most stuff riding on TLS I'd wager that 3rd party decryption
violates such fundamental assumptions that the overall system is
effectively "pwned".

- Marsh

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Aug 2011 19:52:36 +0300

This is true, but we would like to move forward, possibly towards a 
future where mutual authentication is widely used. Either at the TLS 
level (similar to TLS-PSK and TLS-SRP), or at the HTTP or app level, as 
in the http-auth discussions. The first option would break with a RW 
proxy, but would work fine with a RO proxy. The second option would 
survive either one without being completely pwned - you don't get the 
credentials even if you get the date of the next anti-government 
demonstration. Then the question becomes: you trust this proxy to 
protect you from getting/sending malware. But do you also trust it to 
perform operations on your bank account?

Thanks,
     Yaron