Serious question: why is GnuTLS very often not considered as an alternative to OpenSSL?
Chrome: From NSS to OpenSSL
51–60 of 77 posts
Re: Chrome: From NSS to OpenSSL
#52Though 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: * 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 d…
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;
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.
Re: Chrome: From NSS to OpenSSL
#53Though 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: * 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 d…
> 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.
"Don't want to" is a bit uncharitable. We want to, but have limited resources and a lot to do. We actually recently rewrote the certificate validation library and it is currently on Nightly. Check it out!
Of course, it is open source, so patches are always welcome. (Firefox dev here)
Re: Chrome: From NSS to OpenSSL
#54Serious question: why is GnuTLS very often not considered as an alternative to OpenSSL?
One but really important reason:
https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432...
vs.
Re: Chrome: From NSS to OpenSSL
#55I 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)
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
It landed on Nightly a week ago, check it out! You can help us by testing it [0] or reviewing the code [1].
[0] https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing... [1] https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing...
Re: Chrome: From NSS to OpenSSL
#56I 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)
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
To be even more precise, this new certificate validation library is the current default in nightly (ff-31), testing is welcome.
Re: Chrome: From NSS to OpenSSL
#57Earlier quoted context omitted.
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?
Google has already written and released a complete crypto stack for Go. Where you restricting your comments to C/C++ implementations?
The last time I looked at it the go stack was very weak compared to any of the mature C SSL stacks. IIRC it only took me a few minutes to find a security bug (which I reported and is now fixed) that I'd reported against various browsers several years earlier. In short, I highly doubt the go SSL stack is production ready.
Re: Chrome: From NSS to OpenSSL
#58Earlier quoted context omitted.
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?
Google has already written and released a complete crypto stack for Go. Where you restricting your comments to C/C++ implementations?
Good point. Though it only claims to "partially implement TLS 1.2". http://golang.org/pkg/crypto/tls/
Re: Chrome: From NSS to OpenSSL
#59Serious question: why is GnuTLS very often not considered as an alternative to OpenSSL?
One but really important reason: https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432... vs. http://www.openssl.org/source/license.html
Also, it uses `strlen` and `strcat` on binary data: http://www.openldap.org/lists/openldap-devel/200802/msg00072...
Re: Chrome: From NSS to OpenSSL
#60Though 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: * 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 d…
> 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 c…
Would clean up of the OpenSSL code be accepted? I mean just from a quick glance at the fragments that have been posted, the first thing that would need to be done would be to get rid of all the ifdefs, i.e. decide on a canonical value for each of the flags in question; would this be accepted, or would the existing stakeholders respond with a list of reasons why they are committed to keeping the status quo?