Chrome: From NSS to OpenSSL (opens in new tab)

> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.

Why not? NSS is handled by Mozilla. Mozilla prides itself on being open-source. People can submit patches to NSS by filing in Bugzilla.

> The most important code in both NSS and OpenSSL is the SSL state machine. The code for that state machine is incontrovertibly clearer and better expressed in NSS.

I agree with this to some extent (although I don't think it's quite as much better as you suggest), and cleanups in that code are needed. Other parts of NSS can certainly rival OpenSSL on the "dear god" scale however. I'll take the low-level parts of OpenSSL over NSS any day.

> NSS has had better battle-testing as a clientside browser TLS library than OpenSSL, which, apart from Android Chrome, isn't a big factor in TLS clientsides.

This is true. We will have to rack our brains and our bug database for some of the unwritten rules of TLS to port over to OpenSSL. I'm not too worried about this in the long term however.

Ultimately the proof will be in the pudding. Ask again in 12 months :)

I know nothing about crypto, but I found comparing both codebases at a high level very instructive from a pure software engineering / project management standpoint:

ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_16_RTM/src/nss-3.16-with-nspr-4.10.4.tar.gz

https://github.com/openssl/openssl

https://www.openssl.org/source/openssl-1.0.1g.tar.gz

In terms of sheer architecture, those two are almost epitomes of a very well maintained project (NSS) and a very poorly maintained one (OpenSSL). The OpenSSL codebase looks like it evolved for years with seldom any cleanups being done, with many people doing contributions, each person in its own unique style without much unification going on. The directory structure is chaotic, documentation is sparse, commented out code is laying around without any documented purpose, and browsing code at random you find things like this:

  /* This should be using (bs-1) and bs instead of 7 and 8, but
   * what the hell. */
   if (bs == 8)
       l=(l+7)/8*8;

It's pretty much what I would expect to happen if you simply gave everyone interested commit access, reviewed and refactored nothing, and only protested if something gets broken functionally. It's like an orchestra playing without a conductor, just a collection of "stuff" loosely connected together and corrected only as immediate needs surface. It might contain incredible individual pearls of crypto-wisdom of course, and tons of work has been put into it, but the technical debt is huge and paying it now all at once would be hard. I looked at GNU Emacs code a while ago, and had pretty similar overall impression, they for example have a test directory where every individual test suite (file) is done in a completely different style, being by a different author.

If you look at NSS on the other hand, you can tell there is someone who actually cares about the health of the codebase on a day to day basis. The directory structure is much more thought out, there are clear separate modules, there are way more tests, you can generate test coverage statistics, most function signatures are documented, there doesn't seem to be much redundant stuff in it, and so forth.

> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.

This is horrible for a large scale open-source project. Glibc, gcc, as examples. Trying to get them to fix their broken crap or reverse their idiotic decisions takes decades. If OpenSSL is less opposed to change, it's probably a good thing, considering the purpose of it.

> NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of different stakeholders.

Do you not remember the myriad bugs that came out of Microsoft's, Netscape's and others' independently-developed SSL implementations when their only relevant benchmark was their own tools? They didn't give a shit if it broke someone else's tool because they didn't make it to support someone else's tool.

> The most important code in both NSS and OpenSSL is the SSL state machine. The code for that state machine is incontrovertibly clearer and better expressed in NSS.

So clean up the OpenSSL code! If your previous claim that it's easy to get code into OpenSSL is true, fix it! Don't throw the baby out with the bathwater!

> NSS has had better battle-testing as a clientside browser TLS library than OpenSSL, which, apart from Android Chrome, isn't a big factor in TLS clientsides.

OpenSSL is used in hundreds of TLS clients in all kinds of environments around the world. It's the de facto client library for 90% of open source tools. As opposed to whatever environments run NSS applications which is far fewer.

It seems like these are arguments for OpenSSL, not against it.

> Maybe a fork of NSS would be a better plan.

Is forking it actually needed? I was under the impression that Mozilla has many of the same complaints about the current state of NSS as the Chrome team and merely don't want to dedicate the resources to cleaning it up.

> My bet is that the answers to those questions will be more favorable for NSS, even with the crappy certificate handling.

Here's the thing, the SSL libraries are so much more than "just" SSL libraries, and products that use them have to weigh a lot of things in when comparing.

- Platform abstraction layers

* NSS builds atop NSPR, which is the Netscape Portable Runtime from ye-old

* OpenSSL doesn't have much of an abstraction layer - short of perhaps BIO* hiding the nature of POSIX FDs

- Scope of what they try to do

* OpenSSL attempts to provide basic BER/DER parsing, some mid-level abstractions (eg: X509* and the related structures), a "high-level" protocol (SSL), but without any 'productization'

* NSS attempts to provide a hardware abstraction layer (PKCS#11), a full certificate verification library (for both SSL/TLS and S/MIME/CMS - multiple ones, I should add), abstract notions of 'trust domains' within multi-process and single-process servers, etc

- How much flexibility they give developers

* OpenSSL gives you enough rope to hang yourself, and many developers often do. However, at the same time, it's popularity is in part due to it's generous supply of rope

* NSS is wildly inconsistent, with public APIs being adhoc (eg: for any given object, you're lucky if you find all four functions for CRUD, and even luckier if they're internally consistent, and you hit the jackpot if they're externally consistent).

As I mentioned on Twitter, there is no doubt that the SSL state machine of NSS is probably cleaner than OpenSSL's, having worked with both. However, there's a ton of hidden magic that NSS tries to handle, by design, that makes it impossible to reason about how well something will behave, what side-effects it might have, and what the security impact might be.

For an application like Chrome, I will highlight that some of the biggest challenges we've had is in ensuring proper privilege separation when validating certificates with different trust scopes. Some connections only wish to trust certain authorities, others may be ambivalent, and yet other connections may have a mixture of 'default' authorities plus administratively configured settings. Actually ensuring the separation of these authorities is a monumental task within NSS.

That's not because NSS doesn't want to deal with that problem - no, there have been multiple, half-completed attempts to do so, which have simply introduced layer upon layer of abstraction.

NSS is an excellent piece of software for some tasks. But for security software, the last thing you want is "magic surprises", which NSS is full of. Even though the SSL state machine is possible to reason about, if you can't reason about whether or not a given certificate will be marked as "trusted", then you're still in the danger zone.

This makes me wonder what will happen with the level of security in NSS, now that Google is quitting it. Can Mozilla keep maintaining it properly on its own?

Actually I think the Heartbleed vulnerability was most probably found because of this migration, as it was found by Neel Mehta of Google (and the Codenomicon guys). The date of this draft is 2014-01-26, so it makes sense, that the OpenSSL code is evaluated by the security team before the migration.

Considering how widely it's used, if Google could use some of their resources to better it, I'm all for it!

Those were my thoughts exactly, I think OpenSSL just needs a bit of care and refactoring (possibly a lot depending on which blogs you read) for which they need devs and resources, both of which google has.

This conversation circles back to Theo de Raadt's argument that developers are caring too much about performance in security-critical applications.

Smartcard support is pretty important for a lot of people. If Chrome drops that feature, that would be a huge shame.

IIRC... That is in reference to libpkix, the certificate validation component of NSS. I believe Mozilla developers are working on a replacement for it, called mozilla::pkix, in large part due to libpkix being overly complex. Last time I checked mozilla::pkix was pretty far along.

https://bugzilla.mozilla.org/show_bug.cgi?id=915930

Note that NSS contains a classic certificate verification engine, which was originally written in C.

The above statement refers to an external contribution that was added to NSS. It added a second validation engine to NSS, libpkix.

It's true that the libpkix portion is very complicated code, but the above statement doesn't apply to NSS in general.

Due to (mostly ideological) licensing incompatibilities some package maintainers and/or distributions link software with GnuTLS instead op OpenSSL. GnuTLS provides a basic compatibility layer with OpenSSL.

So Chromium may in fact be programmed against OpenSSL but might work when linked to GnuTLS

One but really important reason: https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432...

vs.

http://www.openssl.org/source/license.html

No. Not only is Sodium (more accurately: NaCl) not a TLS library, but it doesn't even implement the primitives that TLS needs; it can't really even serve as a component of another TLS library.

Sodium does not implement TLS.

AFAIK Heartbleed was found during one of Googles code-reviews of OpenSSL.