Though Ryan disagrees strongly, I think this is unfortunate. I think a case can be straightforwardly made that NSS is the better library. Here's a shotgun blast of reasons:<p>* NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.<p>* NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of different stakeholders.<p>* 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.<p>* 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.<p>I don't know that anybody <i>loves</i> NSS, but my perception is that more people believe OpenSSL to be hopeless than believe NSS to be.<p>Talking to Brian and Ryan on Twitter yesterday, I proposed that someone generate a list of questions to ask of a TLS codebase --- "what's the code path from first ClientHello to validating the public key signature in a certificate", or, "what's the code that determines which extensions are enabled" --- and we'd take a shot at answering them for NSS, SecureTransport, and OpenSSL. My bet is that the answers to those questions will be more favorable for NSS, even with the crappy certificate handling.<p>Maybe a fork of NSS would be a better plan.<p>However, to head off the drama HN is probably looking for here: one inevitable result of Google transitioning fully to OpenSSL is that OpenSSL will get a lot better, probably quickly.
It may actually be a good thing if Chrome migrates to OpenSSL. With their resources, perhaps they can do some testing to see if there are any more vulnerabilities out there. At the very least, their continued eye on the project should help it be more secure going forward.
And here is compulsory email thread explaining some context:<p><a href="https://groups.google.com/forum/?_escaped_fragment_=msg/mozilla.dev.tech.crypto/4F3z644W8BM/aUq9UBh7rNYJ#!msg/mozilla.dev.tech.crypto/4F3z644W8BM/aUq9UBh7rNYJ" rel="nofollow">https://groups.google.com/forum/?_escaped_fragment_=msg/mozi...</a><p>> <i>Strange that "PKCS#11 support" is listed as a "con" for NSS</i><p>> <i>It was not accidental that it was listed under "Con", nor do I see ENGINE_pkcs11 as a "Pro"</i>
I found the following part in the cons to NSS amusing, or maybe rather frightening:<p>> Certificate path building is C code designed to emulate Java code, through indirection of an average of 7 layers of macros, two platform abstraction layers, and then the remaining NSS abstraction layers (listed above)
On Debian Chromium 33.0.1750.152-1 seems to be using GnuTLS, I didn't know that the official Chrome used NSS:<p><pre><code> $ ldd /usr/lib/chromium/chromium|grep -E tls\|ssl
libgnutls.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls.so.28 (0x00007fbae0878000)
</code></pre>
In fact on Debian most client software is using either NSS or GnuTLS, OpenSSL is more popular server-side of course.
The doc mentions this among the cons of NSS: "Certificate path building is C code designed to emulate Java code, through indirection of an average of 7 layers of macros, two platform abstraction layers, and then the remaining NSS abstraction layers (listed above)".
Can't they use Sodium instead?<p><a href="http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/" rel="nofollow">http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-...</a>