W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > November 2008

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

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 11 Nov 2008 10:02:45 +0000
Message-ID: <49195845.9010900@mtld.mobi>
To: casays@yahoo.com
CC: public-bpwg-ct@w3.org

comments below

On 11/11/2008 09:36, Eduardo Casais wrote:
> a)	no-transform
> Section 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC