At this year’s Fall event, Apple announced support for App Transport Security (ATS), a new SSL feature, which enables secure, encrypted communications.
In fact, the Apple app review process will now require you to register special exceptions where you do not use the default, encrypted connections with ATS. This means that each insecure connection running unencrypted over HTTP, for example, needs to be specifically whitelisted in your app.
These exceptions should be kept to a minimum. Properly encrypting the data that you transfer into and out of your app is definitely the best practice. But with numerous providers and tools that you may already have included in your app, how do we know which of these providers fulfil these requirements - and which need to be whitelisted?
Checking for encryption in open-source SDKs
If you are using open-source SDKs, as is the case with a handful of providers like adjust, it’s very simple to look up the protocol of the network traffic that these SDKs are transmitting.
In the source code, look for the methods that assemble network packages. You can for example search for the native network type NSURL. This is commonly assembled by passing the data as one argument and the “base URL” as another. The base URL also includes the protocol. By finding the calls to NSURL, you can find out what the base URL is called and search for this.
As an example, you can check out the adjust SDK here:
- Search for the NSURL calls.
- We see that the Request Handler declares the base URL with a call to the method ADJUtil.baseUrl.
- By searching for baseUrl, we find that this method simply returns a constant, which is declared in the same file as
You can repeat the same process for any open-source SDK.
What about all the other SDKs, though?
Many SDKs ship without open-source, meaning that the provider does not let you review the source code of the SDK. In this case, we need to do a little more involved sniffing. (We’ve discussed the differences between open-source and compiled SDKs in a little more depth on TechCrunch. )
First, we need to inspect all the traffic that passes through the app. To do this, we need to use a tool that reads and reports the traffic that is being passed. The most common tool of choice is Wireshark. This can rightly be regarded as a little overkill for simple web traffic logging, so a little Googling led me to an Engadget article and a tool called Burp Suite.
With this tool, you set up your desktop computer as a proxy for your iOS device. All traffic from your iOS device will temporarily be routed through your desktop before it’s forwarded to the web. Burp Suite will then log all traffic that you pass through it.
Set up your proxy and device according to the instructions over at Engadget, and then run through the regular usage of your app on your phone. You’ll see a slew of requests, most likely.
Look for the requests that use HTTP, that is, starting with
http:// and not
https://. The rest of the URLs should then clue you in to which providers are still sending unencrypted traffic.
Hopefully, those providers have either added encryption in a later SDK version, or as an option one way or the other. Knowing which of your SDKs don’t yet support this is the first step to being ready for SSL requirements on iOS 9.