[Cryptography] Apple and OpenSSL

[Jon Callas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 18, 2014, at 5:35 PM, Jerry Leichter <leichter at lrw.com> wrote:

> Be aware that this is a strongly pro-Apple site, and that comes through plainly in the article.  Still, it's an interesting history of how one company has been dealing with the issue of crypto software.
> 
> http://appleinsider.com/articles/14/04/18/how-apple-dodged-the-heartbleed-bullet

It's an amusing read, as I was the developer who gave the 2011 WWDC talk. It's not completely accurate. Some of the places where it says "API" it actually should be "ABI" but it's understandable how you'd confuse those, especially when transcribing from the spoken word.

The fuller story is that OS X, like many modern operating systems is rather fond of dynamically linked libraries. It shipped with OpenSSL dylibs through much of the history. However, in and around the 0.9.8 to 1.0 versions of OpenSSL, there were flurries of activity in OpenSSL and long stretches where it remained stable.

The problem is, as I said above, that OpenSSL does not have a stable ABI. That's Application Binary Interface, and if that's not familiar to you, it means a number of things like that if you add a field to a data structure, you have to add it to the end, not the middle. If you add it to the middle of the data structure then code that dynamically links to that updated library will look at the old offset for the field, not the new one.

Consequently, if you made an OpenSSL dylib and people expected it to work, uh, you know, with dynamic linking, their code will break. This causes dismay. Some people express their dismay through the use of lawyers, or at least the threat of them. That lead us to think that Something Must Be Done.

We talked to the OpenSSL people and noted that we really needed to be able to be able to make and ship dylibs, and asked if there was anything we could do to help. Also at this time, we were culling security libraries. An open question was whether we should keep an Apple-written SSL package, or just start using something open source, and the favorite on this was OpenSSL. The consensus as I felt it was drifting away from chucking Secure Transport because that year's flurry of SSL bugs affected everything *but* Secure Transport. There was still a lot of sentiment for stopping supporting an internal SSL toolkit and devote resources to an external one, and that was part of that discussion.

I wasn't part of the discussions between Apple and the OpenSSL team, but I know it didn't go well. OpenSSL rebuffed Apple and I gathered that the rebuff was actually insulting. It probably wasn't literally, "why don't you go back and make lickable buttons" but that would have given a similar result.

One thing I know that OpenSSL said was that the unstable ABI was a feature, not a bug, and that anyone who really cares about security should statically link OpenSSL. The message we gave at WWDC about static linking was the OpenSSL team's advice to us. We expected that to rile people up, and I made sure that I said that static linking was the OpenSSL team's suggested fix.

Nonetheless, we were left with no solution to the *real* problem, which was that our own customers were on our asses because the dylibs were breaking, and we're left having to tell them that the OpenSSL team told us that it was our fault for being so stupid as to dynamically link OpenSSL. Thus, OpenSSL is intrinsically not supportable in system that likes dylibs. We had to fix that underlying issue.

So what fix? While thinking and researching options, we stumbled across Marco Peereboom's hilarious essay on the subject, "OpenSSL is written by monkeys" <https://www.peereboom.us/assl/assl/html/openssl.html> (which he's updated to say, "Hah! I told you so!" recently). 

The camps divided up possible fixes into several main categories, which I'll summarize as:

(1) Be careful what you ask for, you might get it.
(2) Take OpenSSL out behind the shed, shoot it, and leave its corpse for the crows.
(3) Take OpenSSL out, shoot it, and give it a decent burial.
(4) Take OpenSSL out, shoot it, give it a decent burial, and hire "mourners" to dance on its grave.

Option (4) was really to fork OpenSSL with a team we fund, and fix things. It was dismissed as unworkable and would get a lot of bad press. (If it was workable and got bad press, it might not have been dismissed.) 

Option (3) meant to scrub OpenSSL from the OS, and that was unworkable because there was still the implicit need to maintain the existing dylibs. 

The decision went to option (2). That's what you see now. OS X still ships OpenSSL 0.9.8y (or at least that's the version on my laptop), and the entire system is as it was in 2011. 

Option (1) was to keep shipping an up-to-date OpenSSL, but stop shipping dylibs. That was the one I was in favor of -- OpenSSL may be written by monkeys, but it's written by monkeys that you know. The argument against is that you either have to support it or not, and that puts you in a position where you still have to do a lot of work, but the work is different from what you do with other supported libraries. Thus, inevitably, you revisit the decision every time OpenSSL is updated.

I think that someday, someone's got to give OpenSSL the decent burial. That OS X ships with 2011 OpenSSL command line tools and dylibs is a bug. Option (1) is also still viable, but likely far less viable post-Heartbleed.

On top of this, there's something I really want to point out. Heartbleed isn't a crypto problem. It's a software engineering problem. It's a software engineering problem related to the difficulties of writing, maintaining, and supporting a *system*, where that system includes things like ABIs and dynamic linking and the implied support into the future. Apple's decision to chuck OpenSSL was also a software engineering decision, not a crypto decision.

	Jon



-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii

wj8DBQFTUuk/sTedWZOD3gYRAttCAKChf/XURONp1N+XqFx995AKgHjZ5ACg8LJl
CqwAaiMOTR+dOtnv+KHXWSs=
=CgV/
-----END PGP SIGNATURE-----