Re: ACTION 813 - https link re-writing

On 16/07/2008 16:50, Sullivan, Bryan wrote:
> 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.

I agree

> 
> 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:
If there is a place where it does this can you point out pls

> 
> a) CT Proxy Operator: the most common method will be the allow/deny
> lists that we have already discussed :-)
> 
How CT Proxies work internally (allow/deny lists, magic, thought 
transference etc.) is up to them, surely. We are interested in the 
externally measurable effects, not the means to achieve them

> 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.
I don't think we have a mechanism by which we can achieve this. It seems 
as though it might be an entry under "scope of future work". The CP can 
tell if a link has been rewritten because a request for an HTTPS page 
will come from a CT proxy and it can return a 406 status.

> 
> 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.

That is what we suggest, isn't it? That if it happens then the user 
should be informed and alternatives offered.

> 
> 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

There was something under the server response section that said that if 
a request was received for an http resource but that it was not 
requested in an HTTPS way then it should note this and take approriate 
action. But that section is gone with the sands of time and I don't 
recall why.
> 
> 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.

I'm afraid I don't understand what, if any, changes you suggest.

> 
> 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)
We don't refer to cookies anywhere at all, I'd rather not do so unless 
necessary.
> 
> 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.

If we can steer clear of how this is all configured in the network that 
would be a good thing.

> 
> 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.

I think we are looking at the case where all requests are potentially 
intercepted. But again would prefer to avoid mention of the 
configuration issues.

> 
> 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 18:23:18 UTC