Awesome article, some return from the field

Posted Jan 15, 2026 12:33 UTC (Thu) by Tarnyko (subscriber, #90061)
Parent article: The State of OpenSSL for pyca/cryptography

Awesome article!
Confirms the feedback of this earlier one ( https://lwn.net/Articles/1020309/ ). The tone is harsher, but I support it as it is meant to generate reactions - and ideally, constructive feedback.

I am using OpenSSL3 currently, mainly because it is provided in the default toolchain. Works good enough... but I am not parsing lots of keys & certificates, so the bottleneck is mainly at startup: the rest is just communication, with a limited number a handshakes/negotiations (given it's not a general-purpose server).

That said, I already planned to switch if needed: crypto backend is a parameter in the build system, the software only directly calling an abstraction.

While it is a shame the alternatives (BoringSSL/LibreSSL) don't want to re-use the same public APIs for newer stuff, the article may explain why: their definition (based on generic arrays) is just not convenient.

I can't argue, but I would really like for OpenSSL to catch up though: spreading the effort between 3-4 backends/APIs means lots of extra work & subtle behavior changes, encouraging using wrappers (like we do in the GUI world)... we always managed to avoid that for crypto at least, better keep it this way.

to post comments

Awesome article, some return from the field

Posted Jan 15, 2026 12:45 UTC (Thu) by hkario (subscriber, #94864) [Link] (12 responses)

except that the performance regression of 3.5 compared to 1.1.x is small, but that doesn't get the headlines so that was omitted from the article...

Awesome article, some return from the field

Posted Jan 15, 2026 14:16 UTC (Thu) by Vorpal (guest, #136011) [Link] (4 responses)

Doesn't sound like the regression is small:

> Several years ago, we filed a bug reporting that elliptic curve public key loading had regressed 5-8x between OpenSSL 1.1.1 and 3.0.7. The reason we had noticed this is that performance had gotten so bad that we’d seen it in our test suite runtimes. Since then, OpenSSL has improved performance such that it’s only 3x slower than it used to be.

And

> As a result of these sorts of regressions, when pyca/cryptography migrated X.509 certificate parsing from OpenSSL to our own Rust code, we got a 10x performance improvement relative to OpenSSL 3 (n.b., some of this improvement is attributable to advantages in our own code, but much is explainable by the OpenSSL 3 regressions). Later, moving public key parsing to our own Rust code made end-to-end X.509 path validation 60% faster — just improving key loading led to a 60% end-to-end improvement, that’s how extreme the overhead of key parsing in OpenSSL was.

I cannot reconcile that with your statement. And as they said, performance is not the only problem, the API is terrible too.

Awesome article, some return from the field

Posted Jan 15, 2026 14:35 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> Doesn't sound like the regression is small:
> I cannot reconcile that with your statement

The article you quote specifically is about 1.1.1 versus 3.0.7, whereas the comment you are replying to is about 3.5.x

(3.0.0 was released in September 2021, 3.5.0 was released in April 2025, and a significant chunk of the work during those 3.5 years was focused on improving performance)

Awesome article, some return from the field

Posted Jan 15, 2026 14:41 UTC (Thu) by randomguy3 (subscriber, #71063) [Link] (2 responses)

Since then, OpenSSL has improved performance such that it’s only 3x slower than it used to be.

It doesn't make clear what version is being referred to here, but it's implying a current version with "since then" - i would assume either 3.5 or 3.6.

Awesome article, some return from the field

Posted Jan 15, 2026 16:13 UTC (Thu) by hkario (subscriber, #94864) [Link]

pyca/cryptography folks have been complaining about openssl since the relase of 3.0, so, no, it's not a safe assumption

Awesome article, some return from the field

Posted Jan 15, 2026 18:54 UTC (Thu) by iabervon (subscriber, #722) [Link]

From the fact that the next paragraph is about them switching some non-cryptographic parsing operations to their own Rust code and getting performance better 1.1.1, I would assume that openssl 3.something was 3x slower than 1.1.1 when they switched, and they're not interested in profiling 3.5 or 3.6 unless they hear it's now significantly better than 1.1.1, not just about the same.

Awesome article, some return from the field

Posted Jan 15, 2026 15:02 UTC (Thu) by Tarnyko (subscriber, #90061) [Link] (5 responses)

Sure I agree, and this was also my point: 3.5 seems to be only 3x slower, and mostly during key parsing/negotiation phases (well, for negotiation it is logical to assume, but the latest article doesn't mention it...feel free to correct me if needed).
I don't develop general-use client/servers, so I don't rely so much on it: in short, it is not a deal breaker.

What could be a deal breaker in the future though, would be ecosystem fragmentation: if people start to drift away from OpenSSL, we're not assured to get it in all future development toolchains. Hence why the - currently unused - backend swap option, that I hope not having to use personally.

Awesome article, some return from the field

Posted Jan 15, 2026 16:23 UTC (Thu) by hkario (subscriber, #94864) [Link] (4 responses)

What is expensive in 3.x compared to 1.x is algorithm _fetching_ that's because the 3.x series supports providers, so a lot more stuff needs to be done through generic APIs, not through algorithm-specific APIs. And then the library needs to fetch the concrete implementation and validate all those parameters.

When you compare reusing the same object (without re-fetching the algorithm and re-initializing the algorithm) on 1.x with 3.x then there are minuscule (single percentage point) differences between them: here's example of what happens if you don't use the API in optimal way: https://github.com/openssl/project/issues/1681

Could "optimal" be easier? maybe. But there's always balance between many factors: ease of use, how generic is the API, how easy is to provide the backend...

Upstream OpenSSL decided that having an easy way to add completely new algorithms (or new implementation of algorithms) should be easy, as that allows use of hardware accelerators, PKCS#11 modules, experimental crypto, national algorithms, etc. without having to include them in OpenSSL proper. For some people it's important, for others it's not.

Awesome article, some return from the field

Posted Jan 15, 2026 16:33 UTC (Thu) by Tarnyko (subscriber, #90061) [Link] (3 responses)

Thanks for the link to the benchmark: I value such feedback a lot.
In this case, I can confirm the impact on my specific use case is minimal (algorithm initialization is sparse, mostly done at program startup) and my concern is 99% about ecosystem.
I probably use the deprecated API signatures by the way; not that it matters if I read the results correctly.

Awesome article, some return from the field

Posted Jan 15, 2026 19:31 UTC (Thu) by hkario (subscriber, #94864) [Link] (2 responses)

Actually, there are much more comprehensive test results available: https://openssl-library.org/performance/

Awesome article, some return from the field

Posted Jan 16, 2026 5:06 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

Yes, these ones are really nice and a great improvement. Unfortunately they don't include 1.1.1 so it's not always visible where application faced a significant loss and what makes them complain.

Awesome article, some return from the field

Posted Jan 16, 2026 10:57 UTC (Fri) by hkario (subscriber, #94864) [Link]

They don't include 1.1.1 only for functions that are not in 1.1.1. Look for "evp_setpeer dh" as example of one that has 1.1.1 data...

Awesome article, some return from the field

Posted Jan 16, 2026 5:04 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

> the performance regression of 3.5 compared to 1.1.x is small

In client mode it's not. For us 3.5 and 3.4 basically show the same performance. If you go down to the end of this article https://www.haproxy.com/blog/state-of-ssl-stacks and scroll up to the latest graph, you'll see that we're still facing a roughly 4.5x degradation in end-to-end TLS between 1.1.1 and 3.4 (and hence 3.5), despite the former already being significantly slower than alternatives.

Thus it really depends on use cases, but for those who need to encrypt on both sides, it's a real pain, and explains why some applications are now willing to pay the high price of migrating to alternatives, like explained by the Python guys in this article.