TLS and Development with OS X Server

I was working on an application for my own usage, and I was using my iMac as a webserver to test some APIs. Now I had originally built this application as an iOS 8 application, but I wanted to update it to iOS 9 and possibly add some 3D Touch shortcuts.

The issues began with the first compile and attempt to run on my iPhone 6s Plus. As expected the application compiled, installed and ran, except when it did run, I got an error stating “Cannot connect to server”. Since I built the application from scratch, I knew that this was a custom message for when the server is down, or if you put the wrong server name in for the settings. As with any issue, I took a look at the Xcode debug window and noticed what the error said.

NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824).

Now, I thought about this and realized that this was likely due to iOS 9’s new feature App Transport Security (ATS). App Transport Security is the new feature that does not allow, by default, in-secure connections. Well, I knew I have a valid SSL Certificate, so I knew that was not the issue. After doing some searching, I began thinking about what the issue could be. On a whim, I opted to check my server against SSLLabs’ site. This is what I received as a result:

The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.

This server accepts the RC4 cipher, which is weak. Grade capped to B.

The server does not support Forward Secrecy with the reference browsers.

To verify that my hunch was correct, I used an Apple provided application, nscurl, to get Application Transport Security information. The syntax for this application go to terminal and perform the following:

/usr/bin/nscurl — ats-diagnostics [URL] Where URL is the URL you want to check.

The results you receive will indicate whether or not the server passes. If the server does not pass, it will show you why it does not pass.

Configuring TLS exceptions for 
2015-10-18 19:33:17.400 nscurl[2053:84062] CFNetwork SSLHandshake failed (-9824)
2015-10-18 19:33:17.401 nscurl[2053:84062] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
Result : FAIL
2015-10-18 19:33:17.410 nscurl[2053:84062] CFNetwork SSLHandshake failed (-9824)
2015-10-18 19:33:17.411 nscurl[2053:84062] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
Result : FAIL
2015-10-18 19:33:17.425 nscurl[2053:84062] CFNetwork SSLHandshake failed (-9824)
2015-10-18 19:33:17.426 nscurl[2053:84062] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
Result : FAIL

This is the result I get for my test server. This exact error message means that Perfect Forward Secrecy is not enabled. Hence, my test server is not capable of being able to do any development without modifying the application. As a side note, this is the exact same result for as well.

As mentioned above, there is a fix that developers have to add to their Application’s info.plist file. The exact information is below. In the code below, replace “” with your server.




What bothers me about this result is that developers cannot use the latest security best practices by default. I briefly looked into how to enable perfect forward secrecy on Apache, the underlying web server on OS X Server. But, I quickly learned that even if I wanted to modify the Apache configuration, it would be futile. In order to support perfect forward secrecy, you need to have at least OpenSSL 1.0.1c. The version of OpenSSL that is installed with OS X 10.11 El Capitan, which is also utilized by Server, is 0.9.8zg. As of this article, the latest version is OpenSSL 1.0.2d, and 1.0.1p.

I get the fact that Apple would not expect a majority of their developers to utilize OS X as the basis for testing. Many would instead be using services like Amazon S3, a virtual private server, or some other test server. However, that does not mean that some users would not want to use their Mac as a test server.

Yes, Apple does provide the ability to opt out of Application Transport Security, but if a developer is building an application for a small business who runs some of their web services on a Mac running OS X Server, it is not feasible to force developers to reduce security when running Apple’s own products.

Unfortunately, until Apple updates OpenSSL to be 1.0.1c, or later, applications cannot be hosted by OS X 10.11 El Capitan without developers adding exclusions.

I do realize that it is entirely possible to do an OpenSSL upgrade using either brew or compiling it myself, however this is not always feasible and can ultimately cause system instability. It would be much preferred for Apple to upgrade the bundled version with OS X. Ultimately this would provide everyone with the best security.

I really hope Apple fixes this. I know OpenSSL is used to perform a number of different actions within OS X, but I do not understand how Apple could not accommodate developers who want to use their Apple’s own platform for testing applications. It just seems counter-productive. In addition to perfect forward secrecy, TLS 1.2 is not supported either. This was also introduced in 1.0.1c.

Originally published at Wayne’s Workshop.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.