If you run ~arch you probably noticed the a few days ago that all Telepathy-based applications failed to connect to Google Talk. The reason for this was a change in GnuTLS 3.1.7 that made it stricter while checking security parameters’ compliance, and in particular required 816-bit primes on default connections, whereas the GTalk servers provided only 768. The change has since been reverted, and version 3.1.8 connects to GTalk by default once again.
Since I hit this the first time I tried to set up KTP on KDE 4.10, I was quite appalled by the incompatibility, and was tempted to stay with Pidgin… but at the end, I found a way around this. The telepathy-gabble package was not doing anything to choose the TLS/SSL backend but deep inside it (both telepathy-gabble and telepathy-salut bundle the wocky XMPP library — I haven’t checked whether it’s the same code, and thus if it has to be unbundled), it’s possible to select between GnuTLS (the default) or OpenSSL. I’ve changed it to OpenSSL and everything went fine. Now this is exposed as an USE flag.
But this made me wonder: does it matter on runtime which backend one’s using? To be obviously honest, one of the reasons why people use GnuTLS over OpenSSL is the licensing concerns, as OpenSSL’s license is, by itself, incompatible with GPL. But the moment when you can ignore the licensing issues, does it make any difference to choose one or the other? It’s a hard question to answer, especially the moment you consider that we’re talking about crypto code, which tends to be written in such a way to be optimized for execution as well as memory. Without going into details of which one is faster in execution, I would assume that OpenSSL’s code is faster simply due to its age and spread (GnuTLS is not too bad, I have some more reserves for libgcrypt but nevermind that now, since it’s no longer used). Furthermore, Nikos himself noted that sometimes better algorithm has been discarded, before, because of the FSF copyright assignment shenanigan which I commented on a couple of months ago.
But more importantly than this, my current line of thought is wondering whether it’s better to have everything GnuTLS or everything OpenSSL — and if it has any difference to have mixed libraries. The size of the libraries themselves is not too different:
exec data rodata relro bss overhead allocated filename
964847 47608 554299 105360 15256 208805 1896175 /usr/lib/libcrypto.so
241354 25304 97696 12456 240 48248 425298 /usr/lib/libssl.so
93066 1368 57934 2680 24 14640 169712 /usr/lib/libnettle.so
753626 8396 232037 30880 2088 64893 1091920 /usr/lib/libgnutls.so
OpenSSL’s two libraries are around 2.21MB of allocated memory, whereas GnuTLS is 1.21 (more like 1.63 when adding GMP, which OpenSSL can optionally use). So in general, GnuTLS uses less memory, and it also has much higher shared-to-private ratios than OpenSSL, which is a good thing, as it means it creates smaller private memory areas. But what about loading both of them together?
On my laptop, after changing the two telepathy backends to use OpenSSL, there is no running process using GnuTLS at all. There are still libraries and programs making use of GnuTLS (and most of them without an OpenSSL backend, at least as far as the ebuild go) — even a dependency of the two backends (libsoup), which still does not load GnuTLS at all here.
While this does mean that I can get rid of GnuTLS on my system (NetworkManager, GStreamer, VLC, and even the gabble backend use it), it means that I don’t have to keep loaded into memory that library at all time. While 1.2MB is not that big a save, it’s still a drop in the ocean of the memory usage.
So, while sometimes what I call “software biodiversity” is a good thing, other times it only means we end up with a bunch of libraries all doing the same thing, all loaded at the same time for different software… oh well, it’s not like it’s the first time this happens…
When comparing crypto libraries, I looked at the certifications they had acquired:* GnuTLS has never applies for any security certifications* OpenSSL has applied for FIPS-140 in the past, and was granted it, but this was then later withdrawn. The design of OpenSSL means that attaining FIPS-140 certification of a dependent application requires individual certification of each application* NSS has applied for and been granted FIPS-140 certification several times. Applications can extend that certification over themselves by following defined and simple rules.All in all, I’d say this indicates good things about the NSS codebase and design. It’s become my preferred SSL library for all uses.
Yes, NSS is nice in many cases, and the fact that it’s implemented through PKCS#11 modules helps as well.But the problem is that most utilities and application that are not _huge_ like Chromium and company don’t use it. @curl@ can use it (but even then it can be a pain in the ass due to a number of compatibility reasons), and so can @liboauth@ (which is used by bti in turn)… but that tends to be it, as far as I can tell.
seems you inspired a gnutls 3.1.8 that fixes this http://thread.gmane.org/gma…workarounds side, there’s a good upstream here 🙂
Yeah never said that GnuTLS upstream is bad… actually I think it’s one of the most promising _especially_ after breaking off from the GNU project.
GnuTLS forces you to manage global state, it was evolved from single threaded model and have not cured yet.OpenSSL is much sane in this regard, it is also quite modular, so easier to manage. It also has better extensibility aka “engines”, it lacks advanced certificate store, and direct PKCS#11 support, but it is easier to used than GnuTLS.NSS is an overkill, it is not a standard library as it requires external configuration, and it enforces its view of the crypto world into PKCS#11 interface. The requirement of the PKCS#11 provider is to be a full provider, but most providers for hardware cryptography only allow private key operations.From development for GnuTLS, OpenSSL and NSS, I think that OpenSSL was the easiest and most complete, well after fighting with documentation and reverse engineer the code…For the licensing issue, there is PolarSSL now which is GPLed, simple and modular.
Alon, I’ve seen PolarSSL author presenting it while I was at FOSDEM in 2012 — it looks interesting but I doubt it’s going to get the same coverage… 🙁
PolarSSL is good in a sense of providing an option for GPLed applications… Up until now there was no choice but GnuTLS. Coverage is not important for most application… all they want is either crypto engine or TLS implementation.