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

Thank you Jose, and my apologies for not being clearer in my  
communication.

What we're discussing here is not, of course, transcoders breaking SSL  
encryption, but rather rewriting links on sites which refer to  
resources accessed over SSL.

I believe my point stands: there may be an overlap between two  
possible motives for SSL (adding security and preventing alteration of  
content) but they are nonetheless different motives, and HTTP/HTTPS  
provide separate support for them.

The point in the minutes was around referenced resources inheriting  
the properties of their parent documents. We rejected it because this  
would be adding the notion of parent documents to HTTP, might lead to  
recursive references, and generally seemed to be a new and subtly  
different use of the protocol which could easily cause problems. When  
you read the minutes you'll note that it was myself and Eduardo who  
made these points, and not, sadly, representatives of transcoder  
vendors.

On 20 Jan 2009, at 14:52, Jose Alberto Fernandez wrote:

> Tom Hume wrote:
>
> >
> > Personally I would say that a CP using HTTPS has stated they wish to
> > have their service accessed securely, but not that they're opting  
> out
> > of transcoding by doing this.
>
> 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.
>
> 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).
>
> So you see, every decision you are taking only works to makes  
> matters even worst for everyone involved (well, except for the  
> transcoder vendors).
>
> Jose Alberto
>
>

--
Future Platforms Ltd
e: Tom.Hume@futureplatforms.com
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422
company: www.futureplatforms.com
personal: tomhume.org