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

Section 4.3.6.2: HTTPS link rewriting

From: Tom Hume <Tom.Hume@futureplatforms.com>
Date: Tue, 9 Sep 2008 18:33:53 +0100
Message-Id: <54283738-EB78-4F42-9835-D671BBD102D1@futureplatforms.com>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

Hello everyone :)

After today's call I've taken an action to review comments section  
4.3.6.2, concerning the rewriting of HTTPS links by a transforming  
proxy - of which there are many.

To summarise:

1. It's clear that a proxy which rewrites HTTPS links will break end  
to end security [1]

2. Prohibiting proxies from doing this will prevent sites which  
require HTTPS for access and do not provide mobile-specific variants  
from being transcoded, and therefore from being accessed. This will  
reduce the available quantity of mobile-accessible content. [6]

3. If a proxy does nevertheless rewrite HTTPS links, it should always  
rewrite them as HTTPS links, alert the end-user and inform them of the  
security implications. [2]

4. There is currently no mechanism by which a proxy can indicate to  
the browser that a specific link has been rewritten [3]

5. There may be good reasons why a HTTPS-accessible resource should  
not work when transformed, and why selective transformation might  
break security models or cookies [4]

6. Content providers might reasonably wish to enforce true end-to-end  
security and themselves avoid rewriting of links. [5]

My own opinions on the matter:

1. Security is a technically complex area; it doesn't seem reasonable  
to require that all users of mobile services understand security  
architectures or the trade-offs they are making.

2. It's not unreasonable for either a user or a content provider to  
insist on having their end-to-end security preserved, and it's not  
only the user who stands to lose in the event of a security-related  
problem.

3. The only mechanism by which a transforming proxy can currently  
alert the user as to a trade-off is by inserting content into the  
response to the user. It would be difficult for users to distinguish  
such content interposed by a proxy from identical content interposed  
by any other third party (e.g. via phishing through email), though  
it's fair to say this problem exists on the wider web too. The proxy  
may also contradict alerts provided by the device itself (for  
instance, my N82 reassures me when I enter a https:// URL that my data  
is safe).

4. There's an open question about the persistence of preferences.  
Should a user be warned each time they access a link without E2E  
security? Each time they access a site without E2E? For the duration  
of a session? Once only per site? Can they manage this preference and  
easily opt to increase their security settings if needs be?

5. Unless I've missed a post (which is entirely possible) there's no  
mechanism for a content provider to insist that its end-to-end  
security not be preserved.

My preference would be for HTTPS links not to be rewritten at all.

Apologies in advance for any breach of etiquette on this list or the  
call - it'll take me a little while to find my feet ;)

Tom

[1] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0011.html
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0041.html
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0008.html

[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0018.html

[3] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0018.html

[4] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0017.html

[5] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0022.html

[6] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0045.html
--
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
Received on Tuesday, 9 September 2008 20:03:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 September 2008 20:03:35 GMT