Apple enabled BEAST mitigations in OS X 10.9 Mavericks

Last week, on October 22, Apple released OS X 10.9 Mavericks, the latest version of their desktop operating system. This was a very important update, given that Safari now, in version 7, supports TLS 1.2. We are slowly moving toward a world in which TLS 1.2 is widely supported. Still, I wanted more. I was hoping that this OS X release was also going to have BEAST mitigations enabled by default. After all, the code was already a part of the previous OS X release (Mountain Lion) and the compatibility risks are minimal given that all other major browser vendors enabled the 1/n-1 split in early 2012.

Going through the security release notes, I was excited to see the BEAST attack (CVE-2011-3389) mentioned, but the explanation of the fix was disappointing. It said:

This issue was addressed by enabling TLS 1.2.

The BEAST attack affects only TLS 1.0 and earlier protocols, but client-side support for TLS 1.2 is currently not sufficient as defence because (1) only about 20% of servers support this protocol version and (2) all major browsers are susceptible to protocol downgrade attacks, which can be carried out by active MITM attackers.

There was still hope that the release notes were incomplete and I didn't want to give up just yet. Given that Apple releases parts of their operating system as open source and that the code for 10.9 was already available, I thought that reading the source code would be a good starting point. And I knew where I should look, because I had previously examined the SSL stack of Mountain Lion.

Today, I was delighted to see that the code had been changed, and that the default setting had been changed from disabled to enabled, meaning that the SSL stack that ships with OS X 10.9 uses BEAST mitigations by default. To see for yourself, look for the first mention of defaultSplitDefaultValue in the source code. It's near the top of the file.

Just to be completely sure, I subsequently observed the 1/n-1 split in action using Safari 7 and Wireshark, against a server running TLS 1.0 with only a single CBC suite configured.

Enabling mitigations on Mountain Lion

If you're still running the previous OS X version and do not wish to upgrade at this time, you can manually enable the BEAST mitigations by executing the following command:

$ sudo defaults write /Library/Preferences/com.apple.security SSLWriteSplit -integer 2

At the very least, you will need to restart Safari; it's probably best to restart the computer. (Disclaimer: I don't have a Mountain Lion installation and have not tried this procedure for myself. I did try to disable the mitigation on Mavericks, but without success.)

BEAST has finally been mitigated client-side

With this, we can finally conclude that BEAST has been sufficiently mitigated client-side, and move on.

Update (11 Nov 2013): Even though the source code indicates that the migitation can be controlled, in practice that does not seem to be the case. It is possible that there is a bug in the CoreFoundation framework that prevents the code from reading the settings correctly. Replacing kCFPreferencesAnyHost with kCFPreferencesCurrentHost in the CFPreferencesCopyValue() invocation makes it work, but requires a one-byte patch to the relevant system library. This investigation is the work of Stefan Becker, who also reported the problem to Apple.

Tags