While OpenSSL is among the building blocks of the Internet, I find NSS to be a higher quality library, mostly because it doesn't break API like OpenSSL does, but also because it's a more complete solution that comes with an OS abstraction layer (thanks to NSPR) a certificate storage component, and lots of other goodies. Not to mention the elephant in the room that is OpenSSL's abysmal track record, but that can change very fast for NSS as well so I don't think it's the biggest factor when comparing the two. At the end of the day, both are well-supported libraries.
The only area where OpenSSL wins hands down vs NSS is documentation, and by extension of its popularity, the easiness of googling a problem and finding its solution. As a comparison, I don't even know what the official NSS homepage is. But IME the source code of NSS is quite readable, so consider having another look at NSS if you need to deal with cryptography in your code.
I once did a Google Summer of Code project with NSS, and tbh I found the codebase quite hard to work with.
It has a lot of what appears to be unnecessary API layers upon API layers that require changes in a lot of places if you want to add something. Also - I don't know if this is still the case, but it was back then - they had bugs in their ASN1 code which they knew about, and workarounds all over the codebase to comply with these underlying bugs.
You could really see that this code is old and has a lot of technical debt - after all it is the "original" Netscape SSL implementation. And the API stability comes at the price that you cannot really get rid of all that complexity even if you wanted to.
That's insightful, thanks. I contributed a script for building NSS on windows to vcpkg and even the build system in use (GYP, abandonware at this point) is technical debt in and of itself.
I vehemently hate the "storage component" in any SSL implementation when it is not just "file per cert"
"Just drop a file in directory" instead of "run a tool that checks whether cert is in store and if it isn't then run import" is so much more automation-friendly.
> This NSS documentation was just imported from our legacy MDN repository. It currently is very deprecated and likely incorrect or broken in many places.
> These are security-fix releases. The highest severity issue fixed in
each of these three releases is High:
And:
> HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control.
So the 1.0.2zg release is only for those paying $50,000 for the enterprise contract? That's understandable, but guess the people paying for lower tiers won't be very happy with that.
Yes. If you're using your distro's version of openssl, then your distro is supporting it for you. What openssl.org upstream claims is supported or not doesn't matter to you.
I've had fun in the past with external auditors¹ who don't really understand what their automated tools are telling them. If the tool reports a version that is no longer supported upstream we have trouble convincing them that it is fine as what we have is a well tested version² with all the security fixes they might be concerned about back-ported³ into it.
----
[1] we provide SASS services to companies regulated industries, like investment banks, they have a high level of monitoring required which includes auditing the security of suppliers like us
[2] possibly more so than the latest upstream version
[3] or even not needed at all because the bug was introduced in a feature that wasn't back-ported
Every time I've seen an OpenSSL security fix on HN, the discussion gravitated towards alternatives.
I think this is a wasted energy, because switching cryptographic providers is the last thing you want to do under the timeline of a routine security release for an open source library.
If you're a Debian user, this might be as simple as "ensure unattended-upgrades is configured on all hosts and this is monitored somehow". However, sometimes it's not so simple.
Eventually one of these releases is going to break something that requires a code change in your applications. (Maybe pass a different flag to OpenSSL? Maybe use a different API for, I dunno, MGF1+SHA256?) And I don't know how many teams are prepared for that kind of rollout.
I'd be interested in hearing from HN users how they plan to respond to these sort of releases.
The discussion about alternatives doesn't need to be related to switching under the timeline of a routine security release, right? I would say that every security release would increase activation energy to switch to another provider, even if that happens asynchronously relative to addressing the security release.
Assuming that good alternatives are available of course. (I'm a rustls maintainer, so obviously I think that's a pretty good alternative -- we have a C FFI, too!)
> The discussion about alternatives doesn't need to be related to switching under the timeline of a routine security release, right?
If not, it certainly doesn't belong in a thread about an announcement for an upcoming security release. Maybe it'd make sense in the postmortem threads?
> I was told OpenSSL 3 was bad for the longest time, I used 1.1x for everything, but switched to Libressl.
Not sure who told you OpenSSL 3 (2021) was bad. It postdates the period where OpenSSL might not have been the right choice. (Among other things, OpenSSL 3 unifies FIPS and non-FIPS consumers, which is nice if you need FIPS.)
> There was a dark period between 2010 and 2016 where OpenSSL might not have been the right answer, but that time has passed. OpenSSL has gotten better, and, more importantly, OpenSSL is on-the-ball with vulnerability disclosure and response.
> Using anything besides OpenSSL will drastically complicate your system for little, no, or even negative security benefit. So just keep it simple.
which AWS Linux are you using that has OpenSSL 3? Linux 2 still has some variant of 1.0.2 which I'm in the middle of dealing with as a recent audit says that's a problem that needs to be at least 1.1.1[someLetter]. even after enabling openssl11 in the amazon-linux-extras, installing it via yum, still remnants of 1.0.2 is popping up.
i haven't seen mention of openssl 3 anywhere within the context of Linux 2
I think you mean "SSL3" (or "SSLv3"), which is a deprecated protocoll. OpenSSL (3) however is a library that supports many different protocols. This confusion is easy to make and is imho reason enough for a jump to Version 4
The only area where OpenSSL wins hands down vs NSS is documentation, and by extension of its popularity, the easiness of googling a problem and finding its solution. As a comparison, I don't even know what the official NSS homepage is. But IME the source code of NSS is quite readable, so consider having another look at NSS if you need to deal with cryptography in your code.
Not a cryptographer, just a happy user, so YMMV.