The TLS mess in OS X El Capitan

Secure internet connections, using what used to be the Secure Sockets Layer (SSL) but has now been superceded by Transport Layer Security (TLS), are vital to OS X: they do the donkey work for HTTPS connections, and provide extensive cryptographic and related functions to many apps. In recent years, a succession of vulnerabilities have been discovered in the most popular open source implementation OpenSSL, resulting in a fairly rapid ascent of version numbers.

In 2014, LibreSSL was forked from OpenSSL, and with El Capitan Apple has opted to use LibreSSL while still providing OpenSSL. I was therefore a little surprised to read that, among the many security fixes in OS X 10.11.4, LibreSSL was updated to version 2.1.8, and OpenSSL to 0.9.8zh.

LibreSSL 2.1.8 is relatively recent, having been released on 15 October 2015; the current version is 2.2.6, though. For OpenSSL the version numbers are even more worring: according to the security notes, OS X 10.11.4 released on 21 March 2016 has version 0.9.8zh, whose support was discontinued at the end of 2015 and “should not be used” according to OpenSSL. The current stable versions of OpenSSL are 1.0.1s and 1.0.2g, which address the serious vulnerability detailed here.

It is not as simple as that, though. OS X has a command line tool openssl which reports that it is running OpenSSL 1.0.2d of 9 July 2015, just the same as OS X 10.11.3 did, and according to OpenSSL suffering the serious vulnerability. OS X Server version 5.1, which is the version recommended for use with OS X 10.11.4, is claimed to support TLS 1.2, which is the current standard, and has been since publication of RFC 5246 in August 2008.

Notwithstanding two apparently different but outdated and vulnerable versions of OpenSSL, and one more recent version of LibreSSL, Apple advises developers to provide their own SSL/TLS support in apps, so that they can be confident of it working the way that they would expect it to.

This sounds like a mess, which could readily see users and their apps using implementations of SSL/TLS which are horrifyingly vulnerable.

It is, unfortunately, partly the result of the messy situation for clients: because there are so many different versions of SSL/TLS in use, it is often valuable to be able to use an older implementation, so that it will be fully compatible with the old and flawed versions being used on many servers. Users are normally happy to be warned that a connection is not as secure as they might expect it to be, but to have to refuse the secure connection because of incompatible SSL/TLS implementations would quickly incur the wrath of users.

This is unsatisfactory, and the whole SSL/TLS area needs to be cleaned up, leaving one secure and capable service which will do the job properly in OS X. It is not good for a new revision released on 21 March 2016 still to be reliant on versions of OpenSSL which are unsupported and “should not be used”. OS X 10.11.5 needs a more secure way ahead.