Last week, About Mobility and Masabists ran a story on the difficulties mobile transcoders have with secure HTTP connections and how they can put themselves into the the connection and thereby breaking end to end security. I've done some research on my own and since I am quite opinionated on the topic I wanted to post my results and thoughts here as well.
O.k. so first of all, what is the fuzz all about in simple words: Today, when somebody uses his mobile browser to connect to his bank, a secure HTTP (HTTPS) web connection is established to the mobile portal of his bank. HTTPS means that before any data is exchanged the banking portal sends a certificate the browser can cross check to ensure that the browser really talks to the server of the bank and has not been redirected to another site. After the certificate has been received, an encrypted end to end connection is established that no one, not even a mobile transcoder in the network can put itself into.
So for the user this is good since he can trust HTTPS to verify that he is really connected to the bank and he can also trust that all data that is sent and received is encrypted from end to end. For the transcoder this is bad since it has no chance to transcode the content and do other things with it.
So some smart people came up with what is called link rewriting to circumvent this 'issue', if you want to call it that way. With link rewriting, the transcoder doesn't forward a web page to the user with an original HTTPS link but with an HTTPS that points to the transcoder itself. When this HTTPS connection is established a secure connection is only established to the transcoder itself. The transcoder then establishes a second HTTPS link to the original server.
This means that the user no longer has a end to end encrypted protection but has to trust that the transcoder keeps his data secret. Also, the user can no longer verify if the transcoder contacts the original server, as the certificate that can be queried in the browser is that of the transcoder and not that of the original site.
In addition, this is totally transparent to the user as he will still see the "lock" icon that suggests an end to end secure and encrypted connection. Only when the user actively looks at the certificate will he actually see that the connection is terminated at the transcoder.
Counter measures: The only way for the user to ensure that this does not happen is to save the original https link as a bookmark. This way the transcoder has no possibility to rewrite the URL and hence can not put itself in the transmission chain.
From a user point of view I consider breaking a HTTPS connection in two parts as very harmful. It only takes one incident where data is stolen via a leak in the transcoder to damage HTTPS' reputation. Also, if it is suddenly acceptable to break HTTPS connections in two parts for reformatting purposes, why not also use it for statistics or to ensure no content the provider does not approve of traverses the network!? No way, the data inside an HTTPS connection only belongs to the user and the server at the end and to no one in between, no matter how good the intentions of the party in the middle are.
Wow! I had no idea. As a mobile web user, “transcoding” is not a feature I want! Transcoding is not the right word for what’s going on here. Re-writing, Fiddling, Corrupting, Destroying, Eaves-dropping are more appropriate terms. Yet more nonsense from mobile operators.
This has been done for yrs – even w/ WAP you are/were being proxied. Openwave tried to solve this problem in 2K by deploying gateways at the banks themselves – that didn’t scale.
I think the key for transcoders is to make sure they follow best practices as outlined in the Manifesto: http://wurfl.sourceforge.net/manifesto/ as well as proper notification in the browser (ie you are going to make a secure connection to Bank via Transcoder etc) – at that point it’s user choice.
I did not understand what do you mean by “transcoder” in this context.
A transcoder takes care of the voice channel coding. It should have nothing to do with user-level packets.
What is the “transcoder” you are referring to?
Where is it located? What is its function?
Davide
A transcoder is an HTTP proxy that modifies content in transit. They exist at several ISPs already for modem-based services. Basically, it downgrades the quality of images and compresses the html/javascript.
I can’t believe how truly vile this idea is.
Insightful article, however I think this problem can be eventually solved by deploying a designer-controlled transcoder instance to the customer’s hosting server.
Mobile will always be quite different from desktop as far as the use case is concerned!