Forthcoming OpenSSL Releases 3.0.8, 1.1.1T and 1.0.2zg | Hacker News Reader

Forthcoming OpenSSL Releases 3.0.8, 1.1.1T and 1.0.2zg

mta.openssl.org

71 pointsjanpio30 comments

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.

Not a cryptographer, just a happy user, so YMMV.

> I don't even know what the official NSS homepage is.

It looks like it's at https://firefox-source-docs.mozilla.org/security/nss/index.h..., but it looks like they might want documentation improvement patches.

> This NSS documentation was just imported from our legacy MDN repository. It currently is very deprecated and likely incorrect or broken in many places.

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.

What about LibreSSL in comparison? Has it become different enough?

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.

> 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 comparing to the last update day it must be medium then :)

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.

To be fair, this is clearly stated on their page.

https://www.openssl.org/support/contracts.html

Old distros still shipping openssl 1.0.2 (RHEL?) will backport this for their customers.

edit: ubuntu 18.04 (still under LTS, no Pro needed as this is main repo) uses 1.0.2, so the fix should ideally show up here: https://packages.ubuntu.com/source/bionic/openssl1.0.

changelog: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl1...

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?

Feel free to flag those comments and find out how many other people agree with you.

I was told OpenSSL 3 was bad for the longest time, I used 1.1x for everything, but switched to Libressl.

Now that I need to switch to AWS Linux they are using OpenSSL 3, my question is should I still be hating on OpenSSL?

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

Sorry, should have been more clear, AL 2022

https://docs.aws.amazon.com/linux/al2022/ug/compare-al2-to-A...

> 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.

https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

haproxy have said during their performance testing that 3.0 performed quite badly so they're sticking with 1.1x

The meta issue for slow performance is https://github.com/openssl/openssl/issues/17627

Thanks!

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

* by this I meant it would make sense if they changed the new version name/number to 4

Guess no QUIC/HTTP3 support until 3.1

Yup, they decided that two years ago:

https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSS...

Every time I see OpenSSL anywhere I get this instant anxiety.

Just use the Tectia (If I remember the name correctly) ssh server. I used it a lot back in the days, as it had an almost immaculate security history.

Doesn't solve problems with ssl/http3 etc.

Also, doesn't look cheap? "request pricing"? https://www.ssh.com/products/tectia-ssh/

Reply on news.ycombinator.com