Post #1950095
2026-01-15 21:22 UTC
It seems that py/cryptography's thoughts about OpenSSL (https://cryptography.io/en/latest/statements/state-of-openssl/) are doing the rounds at the moment.
I've not touched OpenSSL directly in a long time. In fact, it appears that the 10-year anniversary of that (https://www.imperialviolet.org/2015/10/17/boringssl.html) passed by a few months ago!
So I've no direct comments on the piece but, a long time ago, I was in the position where I was landing changes in both OpenSSL and NSS (Mozilla's TLS library). OpenSSL was somewhat famous for having bad code. And, indeed, if you looked at it back then the functions were full of single-letter variable names with pointer arithmetic everywhere and context-free, somewhat scary comments. It wasn't outside the norm for 1990s C code, but I understand why people recoiled.
In contrast, if you looked at NSS code, it looked good! Consistent formatting (before clang-format), good naming, good comments.
But NSS had a PKCS#11 abstraction layer and, even after years, I never could understand how the control flow worked there. I would have to single-step in gdb every time to figure out where an operation grounded out into actual code. I was reminded of that when reading py/cryptography's descriptions of OpenSSL 3.0.
I had a pet theory at the time that, because OpenSSL was repulsive on the surface, it inhibited people enough that they couldn't add much deeper complexity. But NSS, with its invitingly clean-looking code, was understandable and then people had enough capacity left over to add deeper complexity.
There might be something to it, although you shouldn't discount the fact that entities who are willing to fund cryptography libraries often have demands that are contrary to clean code. Things like FIPS compliance and compatibility with a zoo of different accelerators and bespoke needs.
So rather it might have been that old OpenSSL was old OpenSSL because it was mostly unfunded. That meant that it looked pretty ragged, but also there weren't so many demands in tension with good design.
NSS was funded by interests that really cared about PKCS#11 compatibility so that you could use a super-expensive, certified-everything HSM with it. When OpenSSL got shocked into switching to a higher-funding model, that brought lots of those same sorts of competing interests, and then the incentives pointed towards adding slow, impenetrable layers of abstraction all over.
Replies (3)
-
@alwayscurious@infosec.exchange 2026-01-15 21:41
@agl@infosec.exchange I’d have all the complex HSM stuff be in a separate process, and take the same approach to FIPS that Microsoft does: we are working on getting a version certified, but that version might well be end of life before the certification finishes. Alternatively, I’d put the complex abstraction stuff in a proprietary “enterprise” version, and leave the open source version free of that junk.
-
@letoams@defcon.social 2026-01-15 21:45
@agl@infosec.exchange to be fair, I think NSS now has three abstraction layers for PKCS11 🤣
-
@simo5@fosstodon.org 2026-01-15 22:29
@agl@infosec.exchange this is not wrong.