11–20 of 77 posts
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: https://groups.google.com/forum/?_escaped_fragment_=msg/mozi... > Strange that "PKCS#11 support" is listed as a "con" for NSS > It was not accidental that it was listed under "Con", nor do I see ENGINE_pkcs11 as a "Pro"
> 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)
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.
Considering how widely it's used, if Google could use some of their resources to better it, I'm all for it!
I found the following part in the cons to NSS amusing, or maybe rather frightening: > 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: $ ldd /usr/lib/chromium/chromium|grep -E tls\|ssl libgnutls.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls.so.28 (0x00007fbae0878000) In fact on Debian most client software is using either NSS or GnuTLS, OpenSSL is more popular server-side of course.
So Chromium may in fact be programmed against OpenSSL but might work when linked to GnuTLS
Can't they use Sodium instead? http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-...
I found the following part in the cons to NSS amusing, or maybe rather frightening: > 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)
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.
Earlier quoted context omitted.
Considering how widely it's used, if Google could use some of their resources to better it, I'm all for it!
Considering how widely SSL is used, and the resources of Google, I wonder if they could come up with their own encryption toolkit? How hard can it be for a company the size of Google to create a library that lives up to eg SQLite's quality standards?
* NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.
* NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of different stakeholders.
* 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.
* 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.
I don't know that anybody loves NSS, but my perception is that more people believe OpenSSL to be hopeless than believe NSS to be.
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.
Maybe a fork of NSS would be a better plan.
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.