Re: [W3C] Draft Mobile Web BPWG / HTTPS comments

Hi Eduardo,

Thanks for the two waves of comments!

I added them to our Tracking System. It may take a bit of time before 
the Mobile Web Best Practices Working Group officially comes back with 
motivated answers, requests for clarification, or proposed changes based 
on your comments, but we will address them as soon as possible.

In the meantime, please note that the (encouraged!) discussion that 
these comments may trigger on the list is a discussion between 
individuals and does not reflect the official standpoint of the Mobile 
Web Best Practices Working Group, or of the W3C.

Francois Daoust,
W3C Staff Contact,
Mobile Web Best Practices Working Group.


casays wrote:
> To the W3C Mobile Web BPWG.
> 
> This is a second series of comments regarding the "Working 
> Draft of the Content Transformation Guidelines" from 1.8.2008,
> focussing on section 4.3.6.2.
> 
> a) Tthe guidelines state: "[...] and must provide the
> option to avoid decryption and transformation of the 
> resources the links refer to."
> 
> This stipulation theoretically allows manipulations of the
> HTTPS stream that are not strictly related to decryption and 
> transformation of the content. 
> 
> What is required is that the client may establish an HTTPS 
> connection with the server in the exact, undisturbed context
> as if the proxy were a transparent one, performing no
> transformations whatsoever. 
> 
> b) The guidelines do not state that the users "must be advised
> of the security implications of rewriting HTTPS links" BEFORE
> they have a chance to perform any operation with the target site.
> If the advice takes place after an operation, then users may 
> unknowingly access the server through the point-to-point HTTPS
> connection instead of the end-to-end one.
> 
> As an example, a small icon (perhaps representing a question
> mark) in a corner of the first page accessed via HTTPS, and
> pointing to a description of the consequences of the rewritten
> HTTPS links, fully conforms to the guidelines. How many users
> would notice it? How many would click on it, take the time to
> read its content fully (and understand it), before performing
> any further action?
> 
> c) Similary, the guidelines leave completely open the way of how
> to "provide the option to avoid decryption...", and do not 
> require it to be an OSTENSIBLE one. If the users miss the
> alternate (or rather, the original) link, they may unwillingly
> and unconsciously access the server without the expected
> security.
> 
> As an example, a small icon (perhaps representing a key) in a
> corner of the first page accessed via HTTPS, and linking to the
> end-to-end HTTPS link, fully conforms to the guidelines. How 
> many users would notice it and understand its significance?
> 
> d) Informing the user that there are security implications in 
> the way he chooses to access the server, and providing him with 
> an alternative link to it risks causing the following reactions:
> i. WWW-beginners may simply not bother reading the advice and 
> always take the default action, which according to the
> guidelines seems to correspond to taking the less safe,
> point-to-point HTTPS connection.
> ii. Somewhat WWW-knowledgeable users, aware of the existence of
> Trojan horses and phishing, may reel at the invitation to try 
> alternative links. If they are curious and examine the URI of
> the current page, they may further suspect foul play, as the
> rewritten URI may not match the one they accessed originally.
> iii. Expert WWW-users will understand the implications of the
> proxy set-up, but may be wary at using its services for HTTPS
> links -- after all, what is the guarantee that the proxy will
> not misuse or unintentionally disclose private information in
> a point-to-point connection? And if there is a proxy acting as
> middle-man, what is the guarantee that the end-to-end HTTPS
> link is actually an end-to-end one and the proxy is not just
> performing some other tricky manipulations?
> 
> Overall, fiddling with HTTPS connections risks reducing, rather
> than increasing, the willingness of end-users to access the
> mobile Web. A relevant point is that these end-users may 
> actually assign the fault with the untrustworthy connections
> to the content or application provider, rather than to the 
> operator of the proxy.
> 
> e) The guidelines allow the client to go through a first
> point-to-point session establishment with the proxy, and if so
> desired, through a second end-to-end session establishment with the
> server. 
> 
> Establishing an HTTPS connection is a somewhat heavy process for
> wireless devices, requiring the delivery and possibly acceptance of
> certificates. A double initiation procedure reduces, rather than
> increases, usability at session start.
> 
> f) In the absence of any requirements regarding the reliability
> of proxies and their operating environment, one can only 
> wonder why anybody would choose a point-to-point connection
> through an uncontrollable middle-man over an end-to-end one
> if the intent is to access private information safely over 
> the mobile Web. The experience of WTLS taught some hard lessons 
> there.
> 
> g) The guidelines rely upon a fundamentally flawed assumption:
> in the HTTPS connection, the client is the only party concerned 
> with security, and which must take a decision as to whether to 
> access resources over a point-to-point or end-to-end link. 
> 
> This is incorrect: there are actually two parties to the secure
> connection, client and server, both with legitimate security 
> concerns. The server has thus as much a right to determine whether 
> it wants to provide services over a point-to-point connection 
> as the client. I can very well imagine that for instance 
> banking, electronic commerce or social networking application
> servers may decide to sever point-to-point connections rather
> than providing services over them, and inform the end-user 
> about the reasons.
> 
> Unfortunately, because of the flawed assumption of the guidelines,
> there is strictly no way a server may reliably detect whether
> it is communicating over a point-to-point link or not. 
> 
> Consider:
> i. The proxy rewrites links but the replacement links must have
> HTTPS; hence for the server communication obviously takes place 
> over HTTPS.
> ii. If the proxy preserves the HTTP header fields (such as 
> user-agent, accept, accept-charset, etc), which is actually
> encouraged by the guidelines, then the proxy cannot detect
> that transformations may be taking place.
> iii. Further, the "via" HTTP header field does not constitute
> a proper mechanism to detect the presence of a transformation
> proxy, and whether HTTPS is point-to-point or end-to-end.
> First, the comment "http://www.w3.org/ns/ct" indicating the
> presence of a transformation proxy is not mandatory, as per
> the guidelines. Secondly, RFC2616 authorizes proxies to use 
> a pseudonym instead of a domain name for the "received-by" 
> part of their hop, which does not necessarily have a meaning 
> for servers.
> 
> The server is therefore not in a position to take educated
> decisions as to its secure communications with clients through
> a transformation proxy.
> 
> 
> Overall, the guidelines follow the rule that accessing the
> WWW is the prime intent of the end-user, and that security
> comes only second. Hence the approach of defaulting to the
> transformation chain, with the possibility of opting out of
> it. This is a questionable assumption precisely in the
> context of secure transactions. There, secure access is the
> paramount requirement, and must therefore be fulfilled by
> any proxy set-up, with the possibility to opt-in to the
> unsecure transformation chain.
> 
> 
> 
> Eduardo Casais
> areppim AG
> Bern, Switzerland
> 
> 
>

Received on Wednesday, 6 August 2008 07:59:14 UTC