Re: [CTG] Draft 2008-11-07 / HTTPS link rewriting

comments below

On 11/11/2008 09:36, Eduardo Casais wrote:
> a)	no-transform
> 
> Section 4.2.8.2 states:
> 
> 	"Servers can prevent users from exercising 
> 	this choice by applying a Cache-Control: 
> 	no-transform directive."
> 
> This is inexact: a no-transform directive exactly
> means that the response sent by the server must
> not be modified. It has no bearing on the SSL/TLS
> setup. It does not apply to previous HTTP exchanges
> that might have led to https URL rewriting. In other
> words, it is not the right mechanism to prevent
> breaking a secure connection, or to signal a refusal
> to handle point-to-point connections instead of
> end-to-end ones -- except by widely stretching its
> signification outside the specifications of RFC2616.
> 
I don't think I agree. If a server doesn't want HTTPS links rewritten 
then it can prevent this happening by adding no-transform. Once a secure 
link is established it's moot as the proxy has no sight of that traffic.
> 
> b)	Connection setup
> 
> This is something that has been already stated by 
> several commentators: a response with the 
> cache-control directive comes too late. By that
> time, the secure connection is already interrupted
> at the proxy level. Consider the following example:
> 1. Client accesses a page with a list of links (e.g.
> from a web directory), one of them is an https URL.
> 2. The page gets transcoded, the https URL rewritten.
> 3. Client access rewritten URL.
> 4. Server gets rewritten https request and responds.
> 
> At (4), a no-transform directive will only ensure
> that the content will not get transformed further.
> If the page only contains relative URL, there is 
> a possibility that the exchange may continue over
> the broken secure connection, as the base URL on
> the client side may be taken as the rewritten URL.
> At this stage, there is no guarantee that the
> connection may actually be secure, even for 
> further exchanges specifying no-transform. The 
> most probable behaviour of a server under these
> circumstances is to return the code 403.
See above. The no-transform applies to the page with the original HTTPS 
link in -i.e. 1 - so 2 can't happen.
> 
> 
> c)	Signalling with the server
> 
> The correct approach is to enable the server to
> distinguish whether the secure connection is 
> end-to-end or point-to-point. Somebody familiar
> with the details of SSL/TLS may suggest something
> at this level.
> 
> Otherwise, the necessity of including a reliable,
> mandatory marker of transcoder presence in the HTTP 
> header is once again evident.

And that is the Via header. It's not possible to find a Via header in an 
HTTPS connection that hasn't been intercepted. Francois has an action to 
discuss your earlier point with relevant folks.

> 
> 
> E.Casais
> 
> 
>       
> 
> 
>

Received on Tuesday, 11 November 2008 10:03:54 UTC