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 18:53:54 -0400
Message-ID: <e920a71c0808041553v716cbd66u9cf932e2d41b04f5@mail.gmail.com>
To: "Luca Passani" <passani@eunet.no>
Cc: public-bpwg-comments@w3.org

I think we agree, yeah. While transcoders aren't subverting HTTPS,
because they can't, they're creating a different security situation,
and one which may not be clear to the end user. The user has to be
clear on that. Hey, maybe I'm OK with the situation. Maybe some forum
site uses HTTPS and I want to post from my phone, and don't care if
the transcoder sees it. It's not unilaterally "wrong" -- could be
really useful in some situations. But not in all cases, and the user
does need to understand what's going on, and control it, and I think
the doc does emphasize those things.

I think the detection of transcoders is a separate question and a good
one (I am all for transcoders being honest, and saying "I am a
transcoder" and not preserving the User-Agent, thereby falsely
pretending to be a phone), but let's not get into that. The HTTPS
connection isn't fake in any sense. It's a real HTTPS connection
between a proxy and origin server.

Why would the origin server care whether it's dealing with a
transcoder, with regard to HTTPS? I understand the other objections to
it in general. From an HTTPS perspective, nothing's wrong. The origin
server isn't the one that cares about dealing with problem we agree on
-- it's the client.

Maybe there are some misconceptions about how HTTPS works here. It is
not used to authenticate the client to the origin server (though it
could be). It is used to a) encrypt traffic, and b) authenticate the
site to the client. From the origin server's perspective, it is still
doing all this correctly. Traffic's encrypted, it's proved to the
proxy it's who it says it is.



On Mon, Aug 4, 2008 at 6:10 PM, Luca Passani <passani@eunet.no> wrote:
>
>
> 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)
Received on Monday, 4 August 2008 22:55:00 UTC

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