Re: Some thoughts on HTTPS transcoding

Thanks Bryan.

As mentioned, I had not forgotten your remarks, and had them in mind 
while sending the message to the IETF TLS WG.

I think we're going in the same direction here. The way I see it, there 
are a few things that we should do, a few things that we could do 
although I don't think that's needed, and one or two things that we 
can't do.

I add a few comments below on the light of recent discussions, to 
complete those Jo already sent:
 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0018.html#replies


Sullivan, Bryan wrote:
> Hi all,
> Because we are now getting to the details of HTTPS link re-writing, here are some earlier points I raised when the whole features was in question. We need to address these in the guidelines or at least vendors/proxy-service-providers need to be aware of the issues with HTTPS link re-writing as described below (they will at least discover them, I think unpleasantly so, at some point).
> 
> 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 :-)

Yes, I think we should be clear that this breaks the trust model and 
that it's not a benign decision.
We should also be clear that we do not "standardize" HTTPS links 
re-writing, but that we recognize that it is a pragmatic solution to a 
practical problem, and start from there.
That's what we discussed last Tuesday, and the direction we're aiming 
at. It would not change the normative value of the statements, but put 
the issue into context. It is in the editor's hands for the time being.

I also wish we could envision a solution that would make HTTPS links 
re-writing useless in the future. The lack of technical solution to 
enable both secure end2end communications and content transformation is 
frustrating. I mentioned XML Encryption the other day. See, for instance:
  http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/#sec-eg-Element-Content

I got the idea during the internal project review I held on CT in W3C 
(although XML Encryption was not really mentioned for that). It's not 
implemented by any browser right now, but it could still be something we 
could put in the "Scope for future work" (well, it's "future work" for 
browsers vendors, CPs and CT-proxy vendors, it's already a standard per 
se) to emphasize the fact that we do not think HTTPS links re-writing is 
the way to go but that it's the *only* way to go currently and that some 
encryption at the content level will be necessary in the future to 
enable both CT and end2end security. I do not think that it would have 
any impact in terms of adoption of XML Encryption, and that it will 
necessarily be what the future has in mind, but I think it's important 
to show that something could be done (any other idea would be good as 
well...).

Same as Jo re. allow/deny lists in that case, that's an internal 
mechanism to make sure that the CT-proxy vendor doesn't get into 
problems with highly sensitive stuff such as credit card numbers and the 
like. Provided we insist on what's implied by re-writing HTTPS links, 
that's none of our business, I think.


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

We have the Cache-Control: no-transform directive. I'm afraid we can't 
go any further within this specification, since this would be considered 
to be "new technology".

We should also provide means for the CP to detect the presence of the 
CT-proxy acting as a man-in-the-middle. Requiring it to behave as a 
proxy that must add a VIA HTTP header even in that case, as Rob 
proposed, seems a good and simple idea. There cannot be any VIA HTTP 
header in HTTPS communications, so CPs could use its presence as a clear 
"there's a proxy listening" flag.


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

The "only if the CT Proxy Operator and CP both approve operating in 
link-rewriting mode" seems to imply that a site has to register to 
enable HTTPS links re-writing by the CT-proxy. I suppose one may argue 
that if the user agrees to trust his CT-proxy operator, then that should 
be enough.

The Internet Architecture Board advised us to review comments and 
considerations they issued on OPES (Open Pluggable Edge Services) where 
our CT-proxy seems to fit:
  See RFC 3238: http://tools.ietf.org/html/rfc3238

The first recommendation is:

(2.1) One-party consent: An OPES framework standardized in the IETF
    must require that the use of any OPES service be explicitly
    authorized by one of the application-layer end-hosts (that is, either
    the content provider or the client).

 From their point of view, agreement by the end-user should be enough. 
You seem to suggest that we go further and require both ends to 
authorize this behavior. I would certainly welcome this additional 
restriction to the guidelines. I'm not sure that's practical though: 
e.g. I have a Hotmail, GMail, Yahoo!,...  email account that I only use 
for "light" stuff, it's unlikely that the companies that manage these 
accounts will ever approve this operation for the particular CT-proxy my 
mobile network operator put into place.


> Other points about caveats/implications of HTTPS link re-writing:
> 
> 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

Yes, that's what the guidelines say, although it's not precise enough IMO.
The guidelines only talk about re-written HTTPS links, whereas it's the 
*whole* secure communication between the server and the CT-proxy that 
must also be served over a secure connection between the CT-proxy and 
the end-user.


> 
> 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 the case in which the user-agent bypasses the CT proxy service at some point, and does not return (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.


3), 4), 5), 6) and 7) are getting into too much detail for us, I think.
We're not building a CT-proxy but seeing it from an external point of view.
Up to CT-proxy vendors to tell how to implement things so that it works 
in most cases.

We should say that re-writing HTTPS links cannot work in all cases and 
maybe list a few examples (e.g. use of client certificates, session 
maintenance). But I doubt we should go any further.


Francois.



> 
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Tom Hume
> Sent: Tuesday, October 07, 2008 6:39 AM
> To: public-bpwg-ct
> Subject: Some thoughts on HTTPS transcoding
> 
> 
> Folks
> 
> Some thoughts I've drawn together from various threads on the  
> transcoding of HTTPS links: we've had quite a few comments on this so  
> far.
> 
> My view is that this isn't something which we can condone - and that  
> we should definitely highlight the fact that transcoding HTTPS links  
> breaks end-to-end security and may mean that users can no longer trust  
> a "secure" indication that their browser might give them to the same  
> degree.
> 
> But ... if it is going to be done nonetheless then what can we do to  
> protect the security needs of both end-users and content providers?
> 
> End-users should be warned if they are accessing transcoded HTTPS and  
> given a clear message informing them that what they may believe to be  
> end-to-end security isn't - the wording of this is likely to be  
> tricky. I'd say that they should probably be re-reminded of this each  
> time they start a session, and given the chance to opt out (either by  
> accessing a version free from any transcoding, or by not accessing the  
> resource at all). This would presumably involve injecting content into  
> the exchange between phone and server at some point.
> 
> Content providers must be able to insist on security by using the no- 
> transform directive to prevent any transformation of their content.  
> They could also use the Via: header to detect possible transcoding  
> (presuming this Via: header has been added and hasn't been stripped  
> out). I'd imagine that most CPs who insist on security will implement  
> no-transform, but it's also reasonable to suggest that CPs don't use  
> HTTPS unnecessarily. I'd note there's no middle ground by which a  
> content provider can say "transcode my content, but preserve my need  
> for security".
> 
> On this last point, Jo has rightly pointed out that this would lead to  
> an inconsistent experience, but if there's value in these secure  
> services (e.g. banking) I think users might accept this. In fact I've  
> heard from a UK bank that they have customers accessing their full-web  
> version and putting up with a dreadful experience on mobile devices  
> already.
> 
> Similarly, users should be warned of expired or invalid server  
> certificates that the transcoder receives from an origin server.  
> Francois has also noted the topic of channel bindings (RFC5056) will  
> need discussion with the TLS working group.
> 
> Tom
> 
> --
> Future Platforms Ltd
> e: Tom.Hume@futureplatforms.com
> t: +44 (0) 1273 819038
> m: +44 (0) 7971 781422
> company: www.futureplatforms.com
> personal: tomhume.org
> 
> 
> 
> 
> 
>

Received on Friday, 10 October 2008 12:55:59 UTC