Apple – whose high-profile battles with the US government over iOS device encryption earned repeated headlines earlier this year – is taking another big step towards ubiquitous encryption.
At its annual World Wide Developer’s Conference (WWDC), Apple’s security experts announced plans to mandate secure network communication via HTTPS for virtually all App Store apps, starting 1 January 2017.
A quick refresher: HTTPS is the secure, encrypted, version of the Hypertext Transfer Protocol – the language that your web browser or app uses when it’s talking to a website.
Using HTTPS instead of HTTP means that any data you send or receive, such as pages, cookies, images, comments, personal data or passwords, is encrypted and therefore unintelligible to anyone trying to eavesdrop on what you’re doing.
On web browsers, the well-known padlock icon says you’re on HTTPS, but on many mobile apps you just can’t tell. Apple’s out to change that. According to Ivan Krstić, Apple’s Head of Security Engineering and Architecture:
By the end of 2016, when your apps communicate with your own server back ends, they must do so using a secure TLS channel using TLS 1.2, unless the data being communicated is bulk data such as media streaming and data that’s already encrypted.
In 2015, Apple introduced App Transport Security (ATS) for iOS 9.0 and OS X 10.11, which enforced HTTPS connections when enabled. With ATS turned on, attempts to establish network connections with insecure HTTP simply fail. But Apple gave developers the option of switching ATS off, and many did so. (Notoriously, Google offered iOS developers “last resort” code designed to evade ATS, thereby enabling non-HTTPS-compliant ad systems to keep serving ads to iOS 9 apps.)
Now, says Apple, ATS will have to be turned on in nearly all cases.
Noting that a gradual industry-wide migration is well underway, TechCrunch observes:
App developers who have been wondering when the hammer would drop on HTTP can rest a little easier now that they have a clear deadline…
Possibly, but not all of them sound quite so relaxed yet.
Apple’s Developer Forums are attracting worried messages from coders who see trouble with apps linked to low-cost (non-HTTPS) sites they host themselves, or sites linked to devices or embedded hardware that can’t be made HTTPS compliant, or large public databases hosted by folks who are unlikely to upgrade to HTTPS by January.
It’ll be interesting to see how many exceptions Apple will be coaxed into offering. But, a year from now, it seems highly likely that most modern mainstream iOS apps will be HTTPS-only. And that can only be good.
4 comments on “Apple: iOS to require HTTPS for apps by January”
The cost of implementing HTTPS on your own site is a lot lower now than it used to be. Let’s Encrypt offers free certificates for any site, and some web hosts have software integration that make ordering, verifying and installing a cert as simple as checking a box and clicking a button. Amazon now has a certificate manager for CloudFront that’s free (as long as you don’t need static IP addresses, anyway) and only takes a few minutes to set up. CloudFlare is offering universal HTTPS even on its free tier.
Widespread compatibility with SNI means that in most cases you don’t need a static IP address either, unless you need to support IE6 on Windows XP, or really old Android devices.
If you run the site your app is connecting to, it’ll be a lot less pain to implement HTTPS now than it would have been last year.
Third-party sites and appliances will still be a challenge, though.
Nice movie apple. Way to go.
If an app is not sharing personal data why do it?
Because HTTP almost always *does* share personal data – from cookies identifying to you in the headers, to login tokens that could be used to impersonate you, to giving away a full browsing history (every GET request includes the URL you are askng for, which creates a complete logging trail), to personalised content in the web page, to details of what you searched for, to the prices you were offered…
…and on and on and on.
Because HTTPS also helps confirm the identity of the site through digital certificates (to reduce the risk of spoofed sites and man-in-the-middle attacks) as well as providing confidentiality through data encryption.
Because if you encrypt everything, you never need to worry about whether there was something you forgot to encrypt inamongst the plaintext stuff.
After all, if you’ve got nothing to hide, then there’s no reason for anyone else to need to see it, unless you especially want them to.