W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

Re: Comments on Content Transformation Guidelines?

From: Sean Owen <srowen@google.com>
Date: Mon, 4 Aug 2008 17:39:16 -0400
Message-ID: <e920a71c0808041439q66b056fcq845bebeef17b0fc4@mail.gmail.com>
To: "Luca Passani" <passani@eunet.no>
Cc: public-bpwg-comments@w3.org

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 21:40:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC