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.

3Comments

Add yours

1

John Valens on July 18, 2016 at 7:22 pm

You’re misconstruing the entire issue, by simply looking at version numbers. The reason for not upgrading OpenSSL is that the library API is not stable between releases. This is a notorious problem for OpenSSL, and why many other applications don’t like to dynamically link into it. It means that if you have software linked to 0.9.8, upgrading OpenSSL to any next version is going to break all of them. I’m sure you wouldn’t appreciate that happening.

What is happening is that Apple is backporting OpenSSL 1.x security patches to its own 0.9.8 version as they come up. This keeps all of the security benefits of patches, without breaking the API for all the other applications on your operating system. Just read the security patch notes (for example: https://support.apple.com/en-us/HT206903 ) to see the details (search for OpenSSL). Many distro maintainers (ubuntu/debian, for example) end up doing this once they decide on a specific OpenSSL version for their release.

LikeLike
- 2
  
  hoakley on July 18, 2016 at 7:26 pm
  
  Thanks, but that still sounds like a real mess, doesn’t it? It also begs the purpose behind version numbers.
  Howard.
  
  LikeLike
3

Anon on May 22, 2018 at 7:52 pm

I know this is an old post, but still relevant. It was not until High Sierra when the builtin Python used LibreSSL instead of the old OpenSSL that didn’t support TLS 1.2. As John mentioned, the reason behind it all was not to break existing things. Sure it is a mess, but how many people are going to read the major changes and then test accordingly. Many would install it, find things are broken and then blame Apple for making changes. OpenSSL 0.9.8 vs 1.02 is totally different. Things that call 0.9.8 may not work calling OpenSSL 1.02. Apple had to make a change in High Sierra though, since things like Curl, Python, etc. were tied to OpenSSL in previous releases, Apple had to provide support for TLS 1.2 , so rather than move to a newer OpenSSL version, they went with LibreSSL (smart move). Curl was changed to the use Secure Transport (this is Apple’s own implementation much like Microsoft has their own) and this was used by Safari for a number of macOS releases. Python was moved to LibreSSL as of High Sierra. Sierra still used OpenSSL 0.9.8 though.

So while you think it is a mess, how does say Apple make it not a mess? Install multiple versions of OpenSSL and force developers to make the appropriate call for the version they need? This eats up space; keep in mind that this would apply to macOS and iOS.

This doesn’t just stop at OpenSSL but with Python, Curl, etc. They are not the latest versions but if Apple just goes and updates them, things will break. If you install other versions, it can cause issues as well.

LikeLiked by 1 person

Share this:

Related