After reading the interesting discussion about mobile transcoders and HTTPS security on the MoMo London mailing list (may require sign-in), based on some related discussion around the new W3C guidelines for transcoding, I thought there was some value in a blog post which explains the issues from more of a layman’s perspective.
First up – transcoders are servers which sit between a mobile phone and a web site, and reformat the web site to (hopefully) make it easier to navigate and use on a handset. A number of operators have installed them, and their customers generally not aware of this – hopefully they just receive a better user experience. This is a subject with a chequered past, that arouses considerable passion among those for and against – I’ll take a neutral stance in this blog post and purely discuss the security implications of what is going on!
In a conventional HTTPS connection, as made by a desktop browser, the browser makes an “unbreakable” connection directly to the web site you are accessing - anyone between you and the site can view the bytes passing between the two, but cannot understand what they mean. Note that, for our purposes here, an “unbreakable” connection is one which is impractical to break within weeks using currently available technology assuming no compromise of the server’s private key – in reality nothing is completely unbreakable! The same should hold true for an HTTPS Wap2 connection between a phone and a web site, without any transcoders:
If you double click on the little padlock on your browser when accessing a site over HTTPS, you'll see a certificate from a trusted certificate issuer (eg. Verisign) stating which domain you have the end-to-end connection with:
On phones, you should be able to do the same thing through the menu system – here’s one on Nokia S40:
Alarmingly, on this same Nokia S40 browser, the Organisational Unit label of the certificate is displayed instead of the Organisation name if both are specified, which often has no meaning to the user. For example Barclays Bank does an excellent impression of being a fake certificate to users not in the know:
However, in principle and when well implemented, the certificate system allows users to trust they are talking to the correct server with some rigorous maths in the background confirming everything. Desktop browsers are increasingly finding ways to automate additional certificate checks and flag up anything unusual, and the mobile web (with its more fiddly certificate checking) will doubtless follow along slowly.
It is worth noting that older Wap1 “secure” connections were not really secure. The handset communicated to the operator’s gateway over a WLTS connection, which was allowed in most cases to use lower key strengths and weaker algorithms which could be broken more easily. The gateway server on the edge of the operator’s network would then decrypt the information and send it on to the end web server over a true HTTPS connection. There were therefore two weaknesses - interception between handset and gateway, and hacking of the gateway to view the connection in plaintext:
These days almost all handsets use Wap2 – which allows for true end-to-end HTTPS. However, as an aside you can easily skip – and here I hold my hands up and declare I know nothing definitively – it is ambiguous what happens when a Wap2 handset connects using Wap network settings. Wap2 is allowed to work just like Wap1 through a gateway, but also prefers end-to-end TCP/IP that is bridged through the gateway but does not need extra translation done there, conventionally configured using “Internet” network settings on the handset. Most operators also provision “Wap” settings on handsets, which were traditionally used to connect an old Wap1 browser to the gateway using a different protocol which emulated some aspects of normal web protocols. When a Wap2 browser (that is also able to handle Wap1, as most are) tries to connect to a server over HTTPS through a Wap connection, is it using weak WTLS to the gateway as in an old Wap1 connection, or is it still using a true HTTPS connection? I am not certain of the answer, and I imagine it would depend on the handset model, browser software and network’s setup (as some gateways can auto-switch between both transparently) so it is difficult to test definitively. If anyone knows please clarify in the comments!
Back to transcoders. The controversial aspect is the way that a transcoder inserts itself into this secure connection in order to “improve” the page markup (I’ll leave the argument about whether transcoders do or don't improve the markup to others). The transcoder forces the browser to make its secure connection to the transcoder, which then makes a subsequent onward connection to the real web server – a model which looks remarkably like Wap1, with better security between handset and intermediary:
Click on that browser padlock while using this scenario, and you would see the transcoder’s certificate and not the certificate of the site you are connecting to. The end result is: whereas in a conventional HTTPS connection, you only share your private information with the site you have chosen, in the transcoding case you share it with the target site and any employee of the transcoder company who has access to the transcoding servers, plus anyone who has hacked the transcoder server.
In reality, any responsible transcoder company would operate their servers with PCI-DSS compliance (the standard required of any company which takes credit card payments), and this would be a minimal risk, but it is more risk than if they weren’t in the loop.
I have discussed this with Novarra (who run Vodafone’s transcoder service in the UK) and they confirmed that they do operate their servers to these standards, but I haven’t talked to any others – and I think some of the concern people feel is that this is not an opt-in service, it is something done to your “secure” connection without your knowledge.
As an aside, Opera have long operated this sort of system with their Mini browser, and their FAQ makes it clear that you should not use the browser for any confidential connections such as accessing your bank – however Barclays Bank, for example, have long recommended Opera Mini for customers wishing to access their accounts on a mobile (recently they have added a disclaimer stating they have no responsibility if you do this):
There is a second problem with any system – Wap1 or transcoders – that obscures the certificate of the end web server. One of the key advantages of HTTPS is that, by providing end-to-end security and trusted certificates, you always know who you are talking to. A major class of attack is the “man in the middle” attack, where a server sits between your browser and the end site and takes a copy of all confidential information passing between them. If a server tried to do this with a true HTTPS connection you would be able to tell, because the certificate you saw would not match the server you thought you were connecting to:
If there was a thief’s server pretending to be the web server, it would not have the correct certificate and you could tell an attack was taking place:
A transcoder in the middle prevents this, because the end user only ever sees the transcoder’s certificate – the end web server’s certificate is only seen by the transcoder. As the user knows nothing about the features of the transcoding software, and the specific deployment configuration of that transcoder on their operator, they cannot tell whether the transcoder has been implemented to correctly verify the end certificate against what the user was expecting:
A thief could easily sit on the other side of the transcoder, and the user would know no better:
This is clearly a retrograde step – moving back towards the insecurity and uncertainty of Wap1. The worry is, if breaking HTTPS security becomes "allowable", we are setting a very worrying precedent for trust in HTTPS and the security of mobile web commerce in the future. History shows that thieves and hackers are becoming rapidly more sophisticated with no signs of stopping – it is difficult to argue that, under those circumstances, we should make things easier for them.
Transcoding servers may take steps to confirm the identity of downstream web server's certificates, and they may not (I am waiting for some confirmation on this from Novarra, for example, and will update the post if and when they provide it). They may prevent the user from accessing sites which have incorrect certificates, or allow the user to choose whether to continue. They may have the ability to do this but allow operators to make these policy decisions, who may not understand the implications. Already we know that some transcoders will not break HTTPS for some banks, but that would be no consolation to a corporate IT department who may unwittingly open up a potential hole in their corporate network, for example.
This is a company blog so I have to mention - the lack of certainty and lack of security on mobile was a key motivator behind Masabi’s creation of EncryptME, which powers our secure applications. We always provide our own full end-to-end security to wrap up transactions, either over the top of SMS or HTTP, giving true desktop-strength security from the mobile, regardless of what the operator or transcoder attempts to do in the middle. Because we understand security and have complete control over application workflow, we also know when to use more than just end-to-end encryption, which is a component of system security but never in itself a guarantor of full security.