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)

One comment received during the Last Call review period from the W3C Web 
Security Context Working Group advised us to get in touch with you about 
channel bindings (RFC 5056):
 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0138.html
We thought we could as well discuss the whole thing...


Content Transformation and HTTPS
--------------------------------
The security issue arises when a user wants to access Web pages that use 
the HTTPS scheme from his mobile device. Since many of these pages 
cannot be displayed properly by his browser, the user might be 
interested to apply Content Transformation to these pages as well.

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.

In practice, this means the proxy replaces the end2end communication by 
an end2proxy + proxy2end communication, and behaves as a man-in-the-middle.


Our position
------------
1/ we recognize that this creates a severe security issue.
2/ we recognize that re-writing HTTPS links may actually not work in 
several cases, mainly:
   - when client certificates are used to authenticate the client
   - more generally when channel bindings [RFC 5056] are used to ensure 
that there is no man-in-the-middle
3/ we recognize that it also raises tricky issues:
   - in terms of validation of the server's certificate (which is de 
facto done by the proxy in that case)
   - in terms of the communication with the user (his browser will say 
"it's secure" whereas the proxy can decrypt the content)
4/ we recognize however that it is a pragmatic solution to a needed use 
case in users everyday browsing life experience.

These concerns will be integrated in the corresponding section in the 
guidelines (which is a bit dry at the moment):
 
http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#sec-https-link-rewriting

The core normative guidelines are likely to remain along the lines of:
  "In case that's really needed, proxies MAY rewrite HTTPS links but...
   they MUST advise the user,
   they MUST use the HTTPS scheme for rewritten links as well,
   they MUST provide the user an option to browse with a secure end2end 
channel".


Questions
---------
a) Are there any specific points (re. channel bindings or any other 
security-related topic) that we might have forgotten and that we should 
consider?

b) we do emphasize that users must be kept informed of the situation. 
 From the server's point of view however, we wonder whether there exists 
mechanisms for the proxy to be detected as a man-in-the-middle so that 
the server may refuse to serve sensitive content in that case.

Even though a proxy reconverted in a man-in-the-middle thing by 
rewriting HTTPS links is probably not a proxy anymore technically 
speaking, we intend to state that it still must behave as such, and in 
particular, that it must add a "Via" HTTP header when it sends the 
request over a secure channel to the server. This Via HTTP header would 
then be a clear indication that there is a man-in-the-middle, since it 
is not possible to have such a Via HTTP header in a normal end2end 
secure communication.

Any other means we should think of?



On behalf of the Content Transformation Task Force,

François Daoust,
W3C Staff Contact,
Mobile Web Best Practices Working Group.

Received on Thursday, 9 October 2008 12:52:58 UTC