Re: Comments on Content Transformation Guidelines?

I think we are saying basically the same thing here. What I am saying is 
that end2middle+middle2end is not the same as end2end security. I go as 
far as considering this some kind of MITM attack. While you don't.
The problem remains, though. HTTPS is associated (and supposed to be 
associated) with end2end security. The CT Guidelines are accepting the 
notion that such e2e security can be compromised under some 
circumstances. All is given is a vague "must advise user of the security 
implications".

Also, you say that content owners can detect transcoders through the VIA 
header and possibly other headers too. Unfortunately, 99%+ of websites 
are not even aware of the existence of such trascoders, so I don't find 
it fair to argue that they get a chance to realize that it is a fake 
HTTPS connection they are managing.

In short, you can turn this any way you want, but it still looks 
unacceptable to me (and I could bet $500 that everyone who seriously 
understands HTTPS will agree with me)

Luca

Sean Owen wrote:
> While I might not actually call this an "attack" I do agree that what
> is really going on here may not match a typical user's expectations.
> You seem to be interacting with your bank, and the browser says you're
> using a secure connection, but in point of fact the entire contents of
> the transaction are visible to the transcoder.
>
> I agree with the doc when it says, at least, please use HTTPS between
> client and proxy and proxy and origin server. I take Bryan's point
> that it may be disruptive to prescribe that the proxy must always
> provide some kind of warning and a certain opt-out mechanism. If not a
> MUST, then a strong SHOULD though -- I do agree this is a case where
> user expectation does not necessarily match behavior with real
> security consequences.
>
>
> To be clear, transcoders are not somehow hacking or fooling HTTPS.
> Unless I missed a big news story, SSL with the kinds of certificates
> used today are still considered secure and have not been cracked.
> There is not an HTTPS session between the client and origin server
> when a transcoder is involved. This is impossible -- unless you have
> cracked SSL. Maybe this misunderstanding leads one to think this is
> really evil. Indeed, that would strike me as most unethical (and
> impressive) to crack SSL and then exploit it to read encrypted
> traffic.
>
> No, the transcoder has just created a different use of HTTPS. The
> client knows it is talking to a transcoder, and has accepted a secure
> session using transcoder.com's SSL certificate. But the issue is --
> does the user understand that? HTTPS is functioning normally at its
> level; it's a user-level issue.
>
> Non-repudiation -- I know SSL can be used to authenticate the client
> as well but I have never seen this used in practice even on the
> desktop. Surely it is not used in mobile? So it is not solving the
> problem of repudiation itself; SSL is not being used for *origin
> servers* to authenticate clients, for purposes of proving a client did
> something. In fact I don't think this is possible with a transcoder.
> The transcoder can't possibly have your device's SSL certificate and
> so cannot authenticate your request to a site that wants SSL
> authentication. At least there, there is no issue, since it is just
> not possible for the transcoder to inject itself in that conversation
> in the same way.
>
>
> On Mon, Aug 4, 2008 at 5:06 PM, Luca Passani <passani@eunet.no> wrote:
>   
>> Having look at the conversation you are having here, I think there are
>> conflicting information about how HTTPS is handled by transcoding servers. I
>> understand that not all transcoders work the same, but some do perform a
>> man-in-the-middle-attack, and IMO this should not be endorsed by the W3C
>> guidelines.
>>
>> The way many transcoders work is that they run instances of real web
>> browsers (talking about tens or hundreds of Internet Explorer instances
>> running in the memory of the server here). This means that there is no way
>> for content owners to protect against transcoders simply because the server
>> is talking to a legitimate web browser, exchanging real certificates,
>> logging-in with real passwords, establishing secure SSL connetions and all
>> the rest.
>>
>> The point of the Content Transformation Guidelines seems to be "some users
>> may want to continue using the service at the cost of degrading security".
>> Well, this is not up to the user to decide, I am afraid. HTTPS is also about
>> non-repudiation and the fact that users must not be able to say "I did not
>> do it" at a later stage. The fact that transcoders have found a technical
>> way to by-pass HTTPS security does not mean that they have the right to do
>> it. Nor does it mean that end-users can take advantage of it.
>>
>> Luca
>>
>>
>>
>>
>>
>>     
>
>

Received on Monday, 4 August 2008 22:11:15 UTC