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.
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.
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
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
NSAppTransportSecurity and it should look like this:
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
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
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.
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.