//
you're reading...

Programming

Is Your Server Ready for iOS 9 and El Capitan?

Apple’s latest operating system updates – iOS 9 and OS X El Capitan – are enforcing stronger network encryption. This is wonderful for users – however it could mean extra work for developers and system administrators.

In short, applications are strongly encouraged to use HTTPS, TLS 1.2 and perfect forward secrecy. You might be saying to yourself, “We’re already serving through HTTPS, so we’re good.” As it turns out, it may not be that simple. It isn’t for Microsoft and you could be affected as well. Yes, at least one of Microsoft’s web services isn’t yet up to Apple’s security standards as of this writing.

First some background story. We sell a desktop client for Yammer, which in turn Yammer is an enterprise social media service that was acquired by Microsoft. I’ve recently compiled the application on Xcode 7 and run it on OS X 10.11 GM candidate.

It failed, badly.

Security dream

Practically all network requests failed with SSL handshake failures. The error was:

An SSL error has occurred and a secure connection to the server cannot be made.

Error Domain: NSURLErrorDomain
Code: -1200 

Strange, but true. Then I turned off Application Transport Security as part of my diagnostics. The app works again. But then I thought to myself, “I couldn’t just turn this off – my users could become vulnerable to downgrade attacks.”

Suspecting that El Capitan doesn’t like Yammer’s wildcard certificate, I traced deep into AFNetworking’s code. I hoped to find some sort of “allow wildcard certificate” flag or response during negotiation with NSURLSession. I couldn’t find any answers there.

Then as I as I re-read the Application Transport Security Technical Note I thought, “Is it the TLS version?” I turned the setting down all the way to TLS 1.0. Still didn’t work.

At this point I’m just shooting in the dark. Fortunately there isn’t many other toggles to try. Then I toggled NSExceptionRequiresForwardSecrecy to NO and… Eureka! It worked!

Learning from my experience, if you’re developing an app that connects to Yammer, you need to place an additional entry in your app’s Info.plist called NSAppTransportSecurity and it should look like this:

Yammer app transport security

Why NSAllowsArbitraryLoads = YES ? Wouldn’t that effectively disables App Transport Security? Yes, that’s kinda true. However users might need to use their Yammer accounts alongside a corporate intranet. For instance, some Yammer networks requires a 2nd level login through a Corporate intranet. Corporates tend to be very slow in updating to these technologies. If Yammer themselves are even not yet up-to-date with their security, expect intranet deployments to be even slower in adopting these more strict HTTPS requirements (nor since it’s an intranet, they may choose not to use HTTPS at all).

In any case we add an exception to yammer.com so that all access to Yammer API is secured. That is, App Transport Security would be in effect for yammer.com and its subdomains.

Furthermore we add NSExceptionAllowsInsecureHTTPLoads = NO just to make sure. You don’t really need to add this entry since NO is the default entry, but there’s a twofold reason for this:

  • Just in case the default value changes in the future.
  • Sometimes there’s a snobby user with only half-working security knowledge that likes to make a big fuss about this, and the presence of this key should calm him down. (Seriously, I came across such users from time to time).

Most importantly you should set NSExceptionRequiresForwardSecrecy to NO for yammer.com because Yammer doesn’t seem to support it as of this writing. Upon further investigation, apparently Yammer only supports the SHA–1/128 bit of the forward secrecy algorithm but El Capitan wants the stronger SHA–2/256 bit version.

You can use SSL Lab’s Scanner to test your own backend’s SSL conformance level. Otherwise if your backend is not accessible from the Internet, this script from SuperUser could be useful as well.

SSL Scan for Yammer

In any case this App Transport Security will take effect only if you build your app on the latest SDK. This way iOS 9 and OS X 10.11 won’t break old apps that aren’t yet updated. Of course if you’re too lazy (or can’t be bothered), you could just stick to the older Xcode to build/update your app and you can get away from handling this SSL thing for now.

That’s all folks. Until next time.



Do you enjoy this post? Enter your e-mail address below to receive articles like this one in your mailbox.
* indicates required

Discussion

No comments yet.

Leave a Reply

Free Updates!

Learn how to grow your indie business while keeping your day job.

Categories

Archives

Keep updated!

Don't miss out on new articles!