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

[Yaron Sheffer <[e-mail]>]

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

On 08/03/2011 06:38 PM, Marsh Ray wrote:
> 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