RE: ACTION 813 - https link re-writing

Here is my input on this subject. Overall I'm skeptical whether a normal HTTP proxy (as compared to a specialized client-server solution for CT) can reliably transform HTTPS links without a number of caveats and options for opt-out.

The CT Proxy Operator needs to recognize that not only are there user-related security implications of rewriting HTTPS links, but there may be reliability-related concerns as well, such as breaking the trust model for server certificates and site assets trusted based upon the trust of the server. There may be very good reasons why the application itself may not work when transformed.

1) This is a fairly complex subject. The CT guidelines need to recognize that and not put vendors, service providers, and users in unchartered waters without adequate fallback/opt-out, under control of the:

a) CT Proxy Operator: the most common method will be the allow/deny lists that we have already discussed :-)

b) CP: there should be a mechanism whereby the CP can indicate that a specific link should not be rewritten. NOTE this requires something in the anchor and link tags, in the page that references the HTTPS URI to be rewritten.

c) User: the user should be given this option/responsibility (I would even call it a burden to most users), only if the CT Proxy Operator and CP both approve operating in link-rewriting mode, for the current site/resource.

Other points (initial ones, for discussion):

2) to maintain security/privacy, secure resources (defined by the CP with having HTTPS URI) MUST be served to the user-agent over a secure connection

3) depending upon whether it is operating in transparent mode or not (i.e. from the user-agent perspective, whether the user-agent is configured to use the CT proxy as its normal HTTP proxy), the CT proxy will need to handle secure resource requests that are initiated by:
  a) in configured HTTP proxy mode, requests are initiated via HTTP CONNECT 
    - If the CT proxy has a different address from the configured HTTP proxy address, the user-agent will initiate the request via the HTTP CONNECT method, and
      - If the CT proxy is an internal function behind a HTTP proxy front end (and operates more link a local content server), for already re-written URI's, the HTTP proxy would setup a local SSL connection to the CT proxy.
      - For un-rewritten URI's, normal behavior would have the HTTP proxy setup an SSL connection to the CP, bypassing the CT proxy. Only if the HTTP proxy was "CT proxy function-aware" would it setup an SSL connection to the CT proxy instead. 
  b) in transparent HTTP proxy mode, requests are initiated via SSL connection (first) for URI's that the CT proxy has already re-written. Note that un-rewritten URI's would not be directed to the CT proxy unless the transparent HTTP proxy has the same "CT proxy function awareness" described above.

4) cookies must be re-written to refer to the CT proxy domain, but this may break some cookies (implications need to be investigated... It is risky just to assume there will be no side-effects) 

5) Note that not all secure links can/will be re-written; only links that actually delivered through the CT proxy so that it has a chance to re-write them. There are many methods of URI discovery (email, SMS, MMS, WAP Push, IM, other device clients...) via which the browser may obtain URIs. If one of those is a secure URI, only if the CT proxy is configured as a normal proxy will it have a chance to intercept/transform the request. 

6) (5) also relates to Heiko's point about the user-agent bypassing the CT proxy service at some point, and not returning (since it's going direct from that point on). Unless the CT proxy is operating as a normal or transparent proxy (as compared to just a site that I browse to and get transformation service thru), then the user-agent can surf away from it and never return except by the same method it was originally accessed.

7) Things can get really screwed up if some resources are rewritten and others not, e.g. with cookies and javascript functions.

Separately: I think I know what is meant by "link mode" but is it a common term? I can't find any references to it in this sense. Do you mean whether the CT proxy is operating as a normal (configured) HTTP proxy?

Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Gerlach, Heiko, VF-Group
Sent: Wednesday, July 16, 2008 12:06 AM
To: public-bpwg-ct@w3.org
Subject: ACTION 813 - https link re-writing


Hi All,

Please see below:

3.3.6.2: 
New:
Due to the nature of a transforming proxy, there will not be end to end security for HTTPS, when content transformation will be applied.

If the response contains links whose URIs have the scheme https the proxy may only rewrite them so that it can transform the content, if it meets the following provision: 

If a proxy does rewrite such links, it must advise the user of the security implications of doing so and must provide the option to avoid decryption and transformation of the resources the links refer to, by bypassing the CT proxy for accessing the original content without touching the proxy.

Note: If the user decides for the latter option, the session might never return back to content transcoding, based on the technical integration of the CT proxy (link mode)

OPEN TO DISCUSS: How about proxy mode integration??? Do we need to menntion those tech integration options?


Old:
If the response contains links whose URIs have the scheme https the proxy may only rewrite them so that it can transform the content, if it meets the following provision. If a proxy does rewrite such links, it must advise the user of the security implications of doing so and must provide the option to avoid decryption and transformation of the resources the links refer to.


Cheeers

Heiko Gerlach
Vendor Manager / Product Owner
Global Consumer Internet Services & Platforms
Tel: +49 211 820 2168
Fax: +49 211 820 2141
Mobile +49 172 20 40 50 7
E-Mail: heiko.gerlach@vodafone.com 
  

Vodafone Group Services GmbH
Mannesmannufer 2, D-40213 Düsseldorf
Amtsgericht Düsseldorf, HRB 53554
Geschäftsführung: Dr. Joachim Peters, Rainer Wallek
 
 
This message and any files or documents attached are confidential and may also be legally privileged or protected by other legal rules. It is intended only for the individual or entity named. If you are not the named addressee or you have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Thank you.  Please also note that transmission cannot be guaranteed to be secure or error-

Received on Wednesday, 16 July 2008 15:51:45 UTC