Hacker News Reader

Comment by hannob | Hacker News Reader

I don't see "we fixed some of the the excessive performance regressions that we introduced in 3.0". Unfortunate...

Context: https://cryptography.io/en/latest/statements/state-of-openss...

It has improved significantly since the early days of 3.0. Not back to 1.1.1 levels of performance, but enough that it's probably not a dealbreaker for most people.

Still a shame that it went backwards.

To put that in perspective: I noticed that private key parsing was 70 times slower in early 3.x versions. I think it's only 8 times slower in current versions. That's still... a lot slower. For no good reason.

>We do not fully understand the motivations that led to the public APIs and internal complexity we’ve described here. We’ve done our best to reverse engineer them by asking “what would motivate someone to do this” and often we’ve found ourselves coming up short.

Surely they thought of it but didn't say it out loud... to keep it exploitable, maybe?

No, that's not what's being implied. They're just saying they don't understand why OpenSSL has added so many indirections to otherwise straightforward operations.

Source: I am friends with the maintainers who wrote this and was one of the people who reviewed it in draft form.

yet you too dont have an idea why asinine decisions were championed

I have a pretty good idea. And it has nothing to do with malice or exploitability.

Care to share...???

Didn't they say it already? They basically think that the OpenSSL API is convoluted. That's my understanding of the comment above, at least.

Unnecessarily complicated APIs are a security code smell precisely because they help hide bugs, leaky abstractions, insecure state, and other exploitable issues.

Did I say they weren't? Not sure why I'm being downvoted here.

Op did immediately above you i.e.: "nothing to do with malice or exploitability"

and when asked to explain you responded with: "Didn't they say it already?"

Which any reader can verify they have not at the time of 1:42pm EST Oct 23 2026.

There are two different things here: there’s code that is vulnerable because of unnecessary complexity, and there is imputing malice or an intent to hide exploitability through complexity. OpenSSL exhibits the former, not the latter.

> OpenSSL exhibits the former, not the latter.

The OpenBSD folks came to the exact opposite conclusion after auditing the code:

"In a nutshell, This was a very effective exploit mitigation technique countermeasure. It could not have been designed better to make an attack like heartbleed both hard to detect and have dire consequences. OpenBSD's memory allocator, Valgrind, and Coverity do not notice the memory issues."

https://www.openbsd.org/papers/bsdcan14-libressl/mgp00007.ht...

Just a single damning slide among many here: https://www.openbsd.org/papers/bsdcan14-libressl/

More here: https://www.libressl.org/papers.html

Further, known exploits like the one crafted for XZ take advantage of plausible deniability and trust in contributors at every opportunity. Meaning that even if you wanted to disclaim malice, you cannot do so effectively.

They don’t appear to, at least not in my reading. “It could not have been designed better” reads more like an indictment of quality than an accusation of malfeasance.

The chosen phrasing is literally one step short of accusing the author of intent. "It could not have been designed better to [avoid detection] and cause harm" leaves open the possibility of accident, in the way that saying "this guillotine could not have been designed better to chop heads" leaves open the possibility of one spontaneously assembling from raw materials.

I mean, that seems intentional to me.

Better your threat model depend on that assumption than mine.

In my experience the phrase "it couldn't have been designed better to [negative thing]" is typically used, in a sarcastic, and usually exaggerated way, to mean "they did such a bad job, that they couldn't have done [negative thing] better, even if they had been intentionally trying to do [negative thing] (which they weren't)."

These days OpenBSD aren’t testing code with Valgrind. IMO the move to limit syscalls to known libs like libc was not a very smart move. It totally breaks Valgrind and from what I’ve seen (I’m not a security expert) it isn’t difficult to circumvent https://isopenbsdsecu.re/mitigations/pinsyscall/.

Gee, I wonder what it could’ve been…

Never attribute to malice what can sufficiently be explained by the love of software developers for overengineering and complexity.

Seriously, I have no trouble explaining this. Overengineering is just how many people think software development works. It's unfortunate, it causes plenty of problems, but it's not a sign of malicious intent.

> the love of software developers for overengineering and complexity

How noob exactly are the people working on... checks notes... OpenSSL for crying out loud?! These are beginner's mistakes.

AWS-Lc looks very promising replacement for OpenSSL these days.

I looked into this and was tempted as there is less read locking and better RNG performance but they stripped the SSL_get1_curves() API which I depend on for bot detection plus I would have to recompile nginx and all its modules everywhere so in the end it was not tempting enough for me. Perhaps I am just lazier in my older age.

We ran a number of tests, including sending a percentage of real traffic to endpoints running AWS-LC and Wolfssl. Technically yes, OpenSSL 3.X is slow, measurably so, but not enough that we wanted to deal with it. That's for our use case, I can easily imagine there being others, where maybe you have different hardware or way more traffic, where it would be worth while. For basic TLS termination in haproxy, it wasn't really worth it to us.

It also depends on exactly which version of OpenSSL. We ran similar tests with multiple versions of openssl. Openssl 3.0, which was the version in the official packages of our LTS distro was unacceptably slow. With 3.4, it was still worse than 1.1.1 but the regression was an acceptable level.

It also definitely depends on your hardware, and how you use it. The main source of the performance regression is more lock contention, so it is more noticeable if you have more threads running on more cores.

Nothing wrong with being frugal with your time!

There were massive improvements to performance in some of the areas criticized by PyCA and haproxy. X.509 handling will also be faster in the average case, with more improvements planned for 4.2.

See https://openssl2026.sched.com/event/2VSQR/performance-the-li... and its slides https://2026.openssl-conference.org/slides/2026-d3-1400-perf.... Recording should also be available soon-ish.

But even with those massive improvements, it's still slower than 1.1.1.

Reply on news.ycombinator.com