W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

[W3C] Draft Mobile Web BPWG / HTTPS comments

From: casays <casays@yahoo.com>
Date: Tue, 05 Aug 2008 17:48:50 -0000
To: public-bpwg-comments@w3.org
Message-ID: <g7a3q2+j33h@eGroups.com>

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

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

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

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 

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. 

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 Tuesday, 5 August 2008 17:49:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:10 UTC