RE: Some thoughts on HTTPS transcoding

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

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

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.

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 Thursday, 9 October 2008 14:11:23 UTC