At WWDC 2015, Apple announced a new and potentially far-reaching policy called App Transport Security. While the announcement wasn’t headlining any keynote presentation, it could certainly affect any mobile app publisher that deploys their own web services, or the countless other web service providers that most mobile apps depend on. It also represents a concrete step towards fulfilling the decree Tim Cook made about security and privacy that, “We [Apple] must get this right.”
“People have entrusted us with their most personal and precious information and we owe them nothing less than the best protections we can possibly provide by harnessing the technology at our disposal. We [Apple] must get this right.”
- Tim Cook
App Transport Security is a new iOS 9 feature that implements the following policy:
Any app built for iOS 9 or OS X 10.11 (el Capitan) cannot make unprotected HTTP connections.
TLS, the protocol underlying secure HTTPS connections, must be configured on the connecting server with best security practices as defined by Apple.
- minimum TLSv1.2 with forward secrecy
- no known insecure cryptographic primitives like SHA-1 or RC4
- minimum key size of 2048bits of RSA and 256bit for EC
Individual apps can explicitly request an exception on a case-by-case basis from this policy.
In broad terms, this means that Apple is signaling that clear-text, unencrypted communication is not acceptable if you want your web service to work with the iOS/OSX ecosystem. Additionally, many web services will have to audit their TLS configuration further to make sure it complies with industry best practices. The exception clause to this policy is best seen as a grace period during the transition phase and we expect Apple to increase scrutiny for apps that make use of the exception, and eventually not accept apps with the exception at all (except in under extraordinary circumstances).
Users most often experience a secure HTTPS connection as a lock icon in their browser, but there is a wide range of quality in the security provided by the underlying protocols. Under the hood, the TLS protocol starts with a complex negotiation between the client and the server to determine which set of cryptographic technologies can be used. This complexity and variety of outdated solutions has been a source of vulnerability that allows determined attackers to steal sensitive information, in some cases resulting in major negative publicity for companies that experience a widespread data breach.
Forward secrecy is a feature that is not available in TLS v1.2 by default, but is required by Apple’s best practices. This is a property of the cryptographic algorithms that prevents an attacker who has recovered a secret key from also using it to decrypt previously recorded data. This applies in a situation where someone has been intercepting and saving your secure communications in the hope that it could be decrypted in the future when they find some new and undiscovered weakness.
TLS protocols are based on a galaxy of cryptographic algorithms, many of which have been shown to be insecure and flawed over the years, or just outdated in the face of ever-increasing computing power. Examples of these include SHA-1 and RC4, which are not allowed by the ATS policy. Furthermore, the keys used for encryption must be a minimum size that is judged too difficult to break by any known brute force attack.
The details of the dance of cryptographic protocols are often too complicated and impenetrable for a user to make an informed determination if their data is truly secure. Apple is taking on the responsibility of enforcing and implementing the best known security practices across their entire platform. This new and major security initiative also coincides with a broad modernization of the entire network platform with transparent support for IPv6, and brand new support for HTTP/2 protocols. In the process , Apple is using their size and influence to move the entire industry forward for the benefit of the end users.