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.