Re: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

Some comments:

1) Since (some of) the CT-proxies rely upon browser engines to operate, they
therefore exhibit similar vulnerabilities as the terminal clients -- at least of
subset thereof, possibly new ones. Even when executing within virtual machines,
attacks based on cache pollution, request smuggling, etc, are possible. What is
sorely needed is an assessment by specialists of Web security (not just at the 
TLS/SSL protocol level).

2) As Rotan makes clear, the conditions upon which an end-to-end security
connection is established are actually defined by the end points (server and 
terminal); any intrusion breaks the agreement. Let me mention that practically
all providers of secure sites stipulate in their conditions of use that access
information (e.g. username, passwords, etc) must be kept confidential, and that
access must take place under safe conditions. Many of such providers (especially
those that deal with financial transactions) indicate that failure to do so may
result in blocking or cancellation of the service. Putting a man in the middle 
obviously raises some questions as to these agreements. The fact that, as I
understand, some operators are systematically white-listing the sites of
financial institutes seems to indicate that it is a very sensitive one.

3) François arrives at the conclusion that one cannot infer that a content
provider is opposed to content transformation because of setting up a site
that is to be accessed via TLS/SSL (HTTPS). These are indeed two different
things; HTTPS is a mechanism for an application to achieve authentication
(server, and, with difficulties as he explained, client), confidentiality, and
integrity. CT-proxies intend to adapt content to different classes of devices.
Unfortunately, diverting and slicing TLS/SSL connections via a CT-proxy
subverts authentication, breaks confidentiality and integrity, and, as Tom 
points out, jeopardizes non-repudiation. The question is whether content
adaptation is such an overwhelming requirement that it justifies crippling
security.

4) The discussion between Luca and David raises two issues in my mind -- which
I had not realized that clearly before. First, many people are not necessarily
conscious of what using one of these proxy-based browsers (or a browser via
a CT-proxy) entails in terms of security. Concretely, users are probably not
aware that their HTTPS/TLS/SSL connections is actually point-to-point, and that
there is someone in the middle who can peek at whatever flows within it. They
are probably not even aware -- in some cases, such as TeaShark, not even 
knowledgeable observers of the mobile scene are -- of what kind of company 
is behind the proxy-based browser, where the proxies are located, and how they
are managed. Secondly, enthusiastic commentators are suggesting that terminal
manufacturers start installing these proxy-based browsers as defaults on their
phones -- which would result in the end of their "opt-in" character and an 
increase of the risk. My conclusion is that any such browser that is unable to
provide end-to-end TLS/SSL security and claims to be a "full-Web" browser is 
severely misrepresenting its capabilities.

5) There is an ironic historical footnote to the whole affair. When WAP was
introduced, it featured point-to-point secure connections (WTLS and TLS on
different sides of the gateway), and proxy-based compilation of content to a
compact format directly interpretable by the terminal. This architecture was
the target of deafening broadsides -- some famous ones being "HTTP-NG & WAP; 
Proxies are Good, Gateways are Bad" (a presentation by the W3C) and "W* Effect 
Considered Harmful". WAP was considered inherently insecure (point-to-point 
instead of end-to-end), and against the spirit and architecture of WWW because
of its reliance on pre-compiled content. At least the criticism on security was
justified -- and resulted in a number of corporations, especially banks, hosting
their own WAP gateway in-house. Nowadays the architecture of proxy-based 
browsers (OperaMini, UCWEB, TeaShark, Bolt, Skyfire) is eerily reminiscent of 
WAP (fixed intermediary node mediating all communications, content digested into
a proprietary, interpretable format, point-to-point sessions) and has similar 
consequences on end-to-end security -- as have CT-proxies. However, and 
curiously enough, all arguments against such schemes, once so decisive are now
considered to be of little import...

This being said: The message starting the thread was a
first shot. The discussion is not yet ready to be concluded. 

E.Casais

Received on Tuesday, 20 January 2009 10:34:52 UTC