> 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.