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 Tuesday, 7 October 2008 13:39:54 UTC