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

Let us keep cool.

> 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. 

First of all, the no-transform (if this is what you are hinting at), applies
to a request or a response, not a document.

Second, and most importantly, there is no way to control from where a URL
will be accessed. The HTTPS link might appear on the search results page
of Yahoo, a blog comment, an e-mail message, a list of "useful links" in
a WWW page -- none of which is under the control of the original site 
(supposedly protected by TLS/SSL) developer. Hence, there is no way to 
enforce a priori a no-transform (or whatever) on these pages referencing the
link. Therefore, once somebody breaks the security protocol by rewriting 
links, it is impossible to un-break it. Thus, associating an attribute to
a target document fails, and the only way out I see is to respect HTTPS URL
as a matter of principle. 

> > I would be happy too. But this solution is not viable. It does not  
> scale.
>
> Absolutely false. 

I do not know about Opera, but proxy vendors must have considered the
scalability impact of white-listing or black-listing acceptable -- after 
all, how else would they endow their proxies with the comprehensive "parental
control" functions some of them are advertising?

Yes, there are schemes for sites to advertise the degree of lewdness or
propriety in their pages or HTTP responses, but they are not systematically
applied. White/black lists constitute the main technique.


E.Casais


      

Received on Tuesday, 20 January 2009 15:56:43 UTC