RE: Comments on Content Transformation Guidelines?

Hi Luca,
There is perhaps a difference between "attack" and "service". What the
CT Guidelines focus on is the delivery of a service. Every tool may of
course be usable for undesirable ends, but that is little justification
for remaining in the stone age.

There is an assumption of user trust in accessing and using a service.
That trust should be established via informed consent. Once established,
the terms of service should be adhered to, including disclosure of HTTPS
link transcoding (however disclosed).

If the user trusts their service provider (e.g. CT Proxy Operator,
whoever that is, whether associated with their network service provider
or not), then they should have the right (barring local legal
constraints) to access HTTPS links via CT proxies. Of course, it's only
useful to do so *if* they can get it to work reliably enough. I have
earlier pointed out some weaknesses in the technical feasibility of
this.

To Sean's point, "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?": I know of no instances of client certificate
use by mobile browsers, at least in the US market.

WAP Gateways can be configured to do domain-name checks on SSL server
certs, but that is the only validation that I am aware of, and it is
specific to WAP1. It's reasonable that mobile devices can do the same
(they need the root certs anyway), but the user experience issues (SSL
server certs are often out of sync with the hostname via which HTTPS
links are served) mean that user prompts on domain validation errors
would likely soon be turned off by the user. The point here is that
users are often trusting that unauthenticated (or at least
server-authenticated) SSL encryption is good enough. This included
operation across the famous "WAP gap" of WAP1, which not
unsignificantly, supports many successful banking and brokerage services
offered to mobile users. WAP2 of course provided true end2end security
as one of its main objectives, but as users sometimes find out, the
direct pipe does not always deliver compatible content.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-comments-request@w3.org
[mailto:public-bpwg-comments-request@w3.org] On Behalf Of Luca Passani
Sent: Monday, August 04, 2008 3:11 PM
To: public-bpwg-comments@w3.org
Subject: 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:23:06 UTC