App Transport Security: the truth and the trouble

Apple have introduced a new feature in iOS 9, called App Transport Security, which is meant to make your use of the Web more secure.

Many (perhaps most) app developers will have to turn App Transport Security off, which almost makes the whole thing pointless. We aren’t being evil: we are just trying to make our apps continue to work the way you want them to work.

Here is the explanation.

Why security is needed

The simplest way of reading a web page is that your computer sends a message to a server saying “give me this page” and the server replies with a message saying “here it is”, followed by the text of the page. The messages are in straightforward plain text that can be read by any human being with a silicon-contaminated mind: for instance, the message your browser sent when you asked to read this page started something like GET /2015/08/30/app-transport-security-the-truth-and-the-trouble/ ‎HTTP/1.1.

What man can read, man can intercept. A request goes from your computer (or phone) to the server through many other machines, and although we expect them to be programmed to do nothing more than pass things on, that doesn’t mean that they are. Someone running a wireless router in a café, or someone running a machine deep in the core of the Internet, could record everything you send and everything you receive. This does not just mean the pages you request, but any user names and passwords sent in the process of getting those pages.

What man can intercept, man can alter. A request to transfer money to Bob can be altered to a request to transfer money to Alice; and your bank statement, afterwards, can be altered so that the money still appears to have been sent not to Alice, but Bob.

And so the secure HTTPS protocol was born. It wraps the whole request-and-response transaction with encryption which makes it incomprehensible to whoever intercepts it and impossible to alter without making it unreadable.

HTTPS is unfortunately tied up with a whole bureaucracy of certificates and identity checking – not surprisingly, since a secure connection to your enemy pretending to be your friend would be just as bad as a secure connection to your friend that happened to be intercepted by your enemy. Not surprisingly, sites distributing wholly public information, such as news sites (and in my case, Universalis) see HTTPS as a nuisance without any very clear benefits.

Safe whether you want it or not

Apple’s latest step towards keeping the Internet private is called App Transport Security. It applies to iOS apps built for iOS 9. It means that (i) any request for a web page made by the app is translated to HTTPS automatically and (ii) the HTTPS encryption methods offered by the web server are checked to make sure that they are properly secure according to current thinking. If not – the request fails. The idea is that with millions of devices all demanding the highest fashionable levels of security, there will be pressure on web sites to live up to the security requirements.

Like forcing European economies to align by locking them all into the same currency, this is a brutal approach. In theory the pressure gets applied in the right place, and webmasters all over the world go through the tedious process of getting certificates and slowing down their servers by turning encryption on. In practice, a user will see that an app that used to be able to access a web site whose security settings don’t please apple suddenly fails to do so. Mostly, users will blame the app rather than the site (which still seems easily accessible in web browsers) and will discard the app and look for another. Sophisticated users will know better: they will recognise that it is the fault of the site not the app – but, wanting to access the site, will also discard the app and look for another. Just as with the euro, the pain falls in the wrong place and no change happens.

Unsafety by request

Of course, Apple did think of this. It is possible, in the setup of an app, to say “allow insecure connections to site X”, or even ”allow insecure connections everywhere”. This is intended to be temporary, covering the case where it hasn’t been possible to change a crucial server over to HTTPS.

Why Google want to compromise your security

Google have attracted some adverse publicity by recommending that app developers circumvent the security settings so that users can continue to be pestered by advertising – that is, by web pages they didn’t request and don’t want. They are saying this because some ad distributors aren’t using the proper security on their servers. The adverse publicity is at least half deserved, because, properly wielded, “nobody will see your ads” is a pretty solid incentive for an advertisement distributor to update its security. It would be a perfect example of the correct pressure being applied in the correct place.

Why we all have to compromise your security

At Universalis, we occasionally ask you to give us some of your money (but only if you want to). Like most sites, we don’t want to get involved in handling credit cards or keeping your details secure. We use Worldpay as a payment processor. When you decide that you want to pay us, we send your browser to the Worldpay payment page, saying ”We want £19.99 from this user”. Worldpay ask you for your details, check with your bank, and if everything is all right and the payment goes through, they send us a message saying ”This user has paid you £19.99”. We never know anything about your credit card and we have no information about you that needs to be kept confidential. Worldpay do get your details, of course, but they have specialist staff working full time on security. Online retailers who keep their customers’ credit card details regularly lose millions of them (and forget to tell anyone until pushed); Worldpay never have.

Of course Worldpay use HTTPS to protect all your details so that nobody can intercept them (or alter the payment request so that the amount is different from the amount you authorised, or goes to someone else). But this is the point where App Transport Security gets in the way of security.

  1. Fashionably secure: Worldpay use a form of encryption which does not provide what is called ”perfect forward secrecy”. Perfect forward secrecy means that if someone records lots of encrypted Worldpay transactions and later steals one of Worldpay’s secret keys, he still won’t be able to decrypt those transactions. Apple don’t like this: they want our transactions to be secure even if that happens. So App Transport Security blocks the communication with Worldpay. That, in theory, puts the pressure on Worldpay. Indeed, I have raised a technical support request about perfect forward secrecy with Worldpay, and the right people are looking at it there. But until Worldpay do change their encryption methods, the pressure is not on Worldpay but on Universalis. The only thing I can do is to turn off App Transport Security if I want to keep my customers and keep getting money from them.
  2. Links to links to links: Let’s suppose that Worldpay have made their move and added perfect forward secrecy by the time you read this. My troubles are not over, because more often than not, you don’t make a payment just by using the Worldpay site. If your bank operates Verified by Visa or the MasterCard equivalent, at a given point you may be kicked over from Worldpay to a site operated on behalf of your bank which asks you to confirm your identity by entering a few letters of a password agreed with your bank. It’s meant to make you more secure by confirming with your bank a secret that even Worldpay don’t see.
    The bank’s site is an HTTPS site, obviously. It isn’t Worldpay’s site and I can’t tell in advance whose site it is. It’s pretty certain that at least some banks won’t be doing HTTPS in a way secure enough to satisfy Apple. So at that point (if I’ve left App Transport Security on), after letting Worldpay gather all your details my app will suddenly fail to go further through the process. You will get an error message. What happens then? You can’t pay us, even though you want to. You are faced with a confusing error in the middle of an already confusing transaction: you don’t even know if the payment has gone through or not. You won’t think that this is some deep-down technical disagreement about encryption methods, you will think it is a fraud – we all know that the Internet is out to cheat us. You will give up trying to pay. The only thing I can do is to turn off App Transport Security if I want my customers to be able to make payments and not panic.

Although App Transport Security is a good thing, in practice, for really sensitive applications such as web payments, the only safe thing to do with it is to turn it off.

The way forward

Apple are not fools. They want people to wear seat belts for their own safety, and they know that if your seat belt stops you from reaching the gear lever, you won’t use it. I am confident that once there really are millions of users using (or potentially using) App Transport Security, they will turn from the technical business of implementing it to the business business of making it unnecessary for developers to turn it off.

Fashionably secure: This is the easy part. Once ATS is out there and really exists and has to be dealt with, the operators of payment sites will all make sure that their encryption methods conform to current fashion. Moreover, for us application developers, it is easy to check. Turn ATS on, try making one payment, and if the Worldpay payment page appears, everything is all right.

Links to links to links: For now, what a developer needs to do is to say “Allow insecure connections” and also “For Worldpay, insist on secure connections”. As soon as Worldpay tell us they have perfect forward secrecy, this is what we will do. It’s a slightly awkward fiddle, but it works.

The next step is for Apple to take. For example, they could allow us as developers to say “Don’t worry about security if a site has been reached through a Worldpay link” – on the ground that Worldpay will only be linking to sites that Worldpay trust. That way, if some minor bank has not updated its systems, its payment confirmation page can still appear.

The real technical solution would be, every time this happens, for the operator of the site to receive a notification saying ”Your security is outmoded, please update it”. But then we run into interesting questions of privacy, because Apple don’t know (at present) what sites we are visiting, and they quite rightly don’t want to know.

All in all, the interesting technical part of App Transport Security has been done, but that is just the beginning of the really interesting part.