Re: CTG: HTTPS URL rewriting ( LC-2270)

 Dear Eduardo Casais ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Guidelines for Web
Content Transformation Proxies 1.0 published on 6 Oct 2009. Thank you for
having taken the time to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/.

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 11 March
2010. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://www.w3.org/mid/255035.90392.qm@web45012.mail.sp1.yahoo.com
 2. http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/


=====

Your comment on 4.2.9.3 HTTPS Link Rewriting:
> A proposal to endow servers with the possibility to protect their HTTPS
> services from
> URL rewriting.
> 
> 
> I.    CONTEXT
> 
> The CTG allows proxies to rewrite URL, including those indicating that
> the 
> communication between terminal and server is to be established as an
> end-to-end
> connection over TLS/SSL.
> 
> The W3C acknowledges the serious security concerns that arise from such
> rewriting
> operations, but does not provide any mechanism for servers to protect
> their services
> from the corresponding security risks.
> 
> HTTPS URL rewriting has perhaps been the more contentious issue of the
> CTG so far,
> and has serious consequences on the credibility of the mobile Web for
> advanced 
> applications requiring privacy, payment security; it opens up a can of
> worm regarding
> liability and certification of mobile e-commerce solutions.
> 
> 
> II.     PROPOSAL
> 
> The following text is to be added to a new section 4.2.9.4 of the CTG:
> 
> "Proxies must provide a means for servers to express preferences for
> inhibiting 
> HTTPS URL rewriting regardless of the preferences expressed by the
> user.
> 
> Those preferences must be maintained on a Web site by Web site basis."
> 
> 
> III.    RATIONALE
> 
> The proposal addresses the issues raised by HTTPS URL rewriting,
> without imposing
> a specific mode of implementation. As such, it does not prescribe
> (non-standard)
> mechanisms, nor introduces new technology into the CTG, but only sets
> formal
> requirements as to their end-effect.
> 
> I re-establishes the consistency between on the one hand the facts that
> 
> a) the original decision to establish HTTPS connections lies within the
> server; 
> b) the knowledge about what level of security is appropriate for a Web
> application 
> lies on the server side;
> c) problems of liability, customer support, and commercial reputation
> fall back onto
> the server;
> and, on the other hand, the facts that
> d) the server is not given any decision power as to whether end-to-end
> security is to
> be respected or not;
> e) only the end-user, who does not possess all required knowledge to
> assess the 
> situation, is given mechanisms in the current CTG to prevent
> transformations on site
> by site basis.
> 
> It takes into account the fact that none of the available mechanisms
> utilized by
> well-behaved proxies is reliable when it comes for a server to
> detecting whether an
> HTTPS URL rewriting has taken place or not. In particular, "via" fields
> may or may
> not be retransmitted integrally by some HTTP standards-compliant
> proxies, as indicated
> in section 4.1.6.1 of the CTG.
> 
> It is in line with the practice in some countries, where operators have
> set up 
> mechanisms such as "white lists" to exclude financial institutes from
> HTTPS URL
> rewriting. This demonstrates that, notwithstanding whatever is stated
> about the
> relevance of rewriting HTTPS links, the consequences of such operations
> are taken
> quite seriously.
> 
> 
> E.Casais


Working Group Resolution (LC-2270):
We agree that this is important but note that no standard mechanism can be
used for establishing two party consent at the time of writing this
document. A section was added in the Scope for Future Work appendix to
point out that such standard mechanism is needed.

----

Received on Thursday, 11 February 2010 22:32:05 UTC