headers
Francois Daoust | 9 Oct 2008 14:52
Picon
Favicon
Gravatar

W3C Content Transformation Proxies guidelines and security


Hi TLS working group,

I'm writing this email on behalf of the W3C Content Transformation task 
force of the W3C Mobile Web Best Practices Working Group. I apologize 
for the length of the email, but thought it was better to introduce the 
context that triggered this message before actually coming to the point. 
I actually tried to keep it short and may go into more details if needed!

Context
-------
The Mobile World is a highly fragmented place: many mobile devices are 
available with many different capabilities, both in terms of hardware 
and software, that may be used in different networks (e.g. UMTS, Wifi) 
with different costs, both in terms of money, bandwidth and latency.

Most Web pages don't display well, if at all, on many mobile devices. To 
enable the access to as many Web pages as possible, several mobile 
network operators introduced content transformation proxies on their 
networks to re-structure Web pages on the fly so that they match the 
end-user's device capabilities.

Re-structuring Web pages creates a number of problems that I won't 
detail here (save the one on security). The Content Transformation Task 
Force was created to define a set of guidelines Content Transformation 
proxies should follow to bring harmony back to the mobile world. The 
latest version of the guidelines working draft is accessible at:
   http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/
   (note many comments were received and are not reflected in the draft yet)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 10 Oct 2008 08:00

Re: W3C Content Transformation Proxies guidelines and security

Francois Daoust wrote:

> HTTPS communications obviously cannot be intercepted by a Content
> Transformation proxy. However, such a proxy can re-write HTTPS links
> that appear in an HTTP response so that the user goes through it when it
> clicks on the link.

Since this is a man-in-the-middle attack, it would be interesting to
know how browsers react in that case. It should be have been made clear
to the user which site he connected to (www.proxy.com instead of
www.amazon.com).

Anyway, about (b). the server cannot detect the attack (unless of course
he requests client certificates) via the TLS protocol, the client could.
The server could detect the attack by noticing few IPs that make many
different transactions.

But actually what you are trying to achieve changes all that is known to
people for "secure" web pages. Now with your scheme you don't trust the
merchant, but the network provider[0]. So for your point (1), I would
say that it is not just a "security" issue, it is a total change of the
protocol currently used for secure web browsing.

[0]. And it is much more than that. Once users get used to have some
proxy between them and the merchant's site, it would be much easier to
attack the TLS protocol that way. That is because noone will verify the
identity of the site they connected to.
Permalink | Reply | 0 comments |

Gmane