Re: CTG: HTTPS URL rewriting

We already note that this is a problem in general and not a mobile 
specific problem. We are clearly in favour of the idea of two party 
consent for interception of HTTPS, but we don't know how to do it.

Since we don't know how to do it, I question the value in making a 
normative provision that seems to be non-testable. I could see more 
value in requiring a conformance statement which is in fact already 
required as a result of the NOT RECOMMENDED part of 4.2.9.3.

I think there is already sufficient normative wording regarding the 
requirement for a conforming proxy to insert a Via header, so that 
applications for which this is important are able to detect the presence 
of a conforming proxy.

In summary, we know that there is no satisfactory answer to this and I 
am unsure that further elaboration would achieve much.

Jo

On 06/11/2009 18:40, Eduardo Casais wrote:
> 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
> 
>

Received on Monday, 9 November 2009 12:47:24 UTC