Re: ACTION 813 - https link re-writing

[Apologies for the noise, re-sending this with an hyphen in ACTION-813 
for the benefits of tracker]

Jo Rabin wrote:
> 
> 
> 
> 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 Monday, 21 July 2008 07:15:53 UTC