W3C home > Mailing lists > Public > public-bpwg@w3.org > January 2009

Re: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

From: Francois Daoust <fd@w3.org>
Date: Tue, 20 Jan 2009 16:35:11 +0100
Message-ID: <4975EF2F.2000207@w3.org>
To: Jose Alberto Fernandez <jalberto@cellectivity.com>
CC: public-bpwg@w3.org

Jose Alberto Fernandez wrote:
> Either you are taking the Mickey out of everyone on the list or you 
> never learn about what SSL is or means. An SSL connection is an 
> encrypted connection between to servers. Requiring sending some header 
> on the connection in order to decide whether the connection can be snoop 
> on or changed in any manner requires that you snoop on the connection to 
> start with, which means that you would be violating the confidentiality 
> of the communication in order to know whether you are allowed to break 
> the confidentiality of the communication.

That is right.
We are not considering the use of Cache-Control: no-transform on the 
HTTPS exchanges themselves. That's just too late.

> Second, it is not a question of not being allowed. It is a question of 
> not being possible to snoop on the SSL tunnel. So the only way you have 
> is to break the tunnel before you even know what the tunnel is all 
> about. Which bring us back to the question of transcoding requests or 
> documents? The only way to inform a gateway whether I allow an HTTPS 
> reference to be snoop on, is by specifying it on the document containing 
> the link. But as you have already decided, from what I read on the 
> minutes, you do not allow the resources of one document to be affected 
> by the options specified on it. Meaning that even if I say I do not want 
> my document transformed, you seem to believe that does not disallow you 
> from transforming its resources (i.e. the referenced HTTPS document).

That is not true.
The Cache-Control: no-transform on the referring page would prevent the 
rewriting of links on that page. In particular, the HTTPS links would 
still target the origin server, and the CT-proxy would not be able to 
snoop on the SSL tunnel. HTTPS documents referenced from a 
non-tranformed page cannot be transformed, and it's not linked to our 
decision not to allow the resources of one document be affected by the 
options it specifies.

Note I am merely saying that the directive works here, not that it's 

> So you see, every decision you are taking only works to makes matters 
> even worst for everyone involved (well, except for the transcoder vendors).

Just a reminder that we haven't really taken any decision on HTTPS yet.
The discussion is still raging on.
I hope the final result will be better than just "the worst possible 
one" for everyone involved.

Received on Tuesday, 20 January 2009 15:35:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC