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.
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.
>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.
Unnecessarily complicated APIs are a security code smell precisely because they help hide bugs, leaky abstractions, insecure state, and other exploitable issues.
tangential, but I've always wondered what the point of these random pictures of a lock, gears, or unrelated little voxel art are for? Pre-LLMs, they were often hit or miss in terms of how much they added depending on if they were a random stock image or something someone drew.
But now, with LLMs, they're more available to customize, and it seems like people aren't actually thinking anymore about why they should be there. I think I'm implicitly biasing against the rest of the content in articles which have them as a result, since it's probably a sign of some level of lack of care/thought.
I kinda wonder what if Microsoft (or any major software company) would give their engineers a few decades of time just to refactor their existing systems, opposite of piling on new features. Will it result a much cleaner code, better architect, and stable product?
The last Windows I daily use was Windows 7 Home (same era with Windows Server 2008). The newer ones don't really improved much featurely from my (user) point of view, and from what I've heard, it's getting more sloppyer every newer version.
> what if Microsoft would give their engineers a few decades of time just to refactor their existing systems
They wouldn't, even if they didn't care about shipping new features. The technical complexity inside Windows/Office/old core MS offerings arises only in small part from ordinary tech debt--that is, things fixable without changing observable behavior. The lion's share of that complexity is because of Microsoft's priority to avoid breaking compatibility (backwards, or with hardware/software combos that work) at all costs.
That means that a refactor-only decade would achieve little unless that compatibility priority were changed.
The Windows user-mode innards have been significantly refactored. Many of the core system DLLs that apps link to are just redirects to the actual implementation now. Much of the jank seems to be in the UI.
It's just as likely it would end up as an overengineered mess. And that's without considering backwards compatibility constraints, which are one of the biggest maintenance burdens.
Make you wonder what they've been testing this on. Even NetBSD doesn't have a recent release for Itanium. Crazy that you can run NetBSD 11.0 on HPPA, but not Itanium, given that HPPA is in some sense the pre-cursor to Itanium.
> Support for DTLS 1.3 (RFC 9147).
Refer to the ossl-guide-dtlsv13(7) manual page for details.
DTLS 1.3 is a huge improvement over 1.2 for efficiency and simplicity. I can’t speak to the OpenSSL implementation but it’s great that support is finally released.
Interesting they're adding new support for DTLS 1.3 when afaict most new applications are defaulting to QUIC datagram mode. I have something built around DTLS 1.3 and am using wolfssl for that reason, will have to check this out.
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.
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.
Nothing wrong with being frugal with your time!
>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.
Gee, I wonder what it could’ve been…
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.
[flagged]
I think it's too little too late, people have started moving on https://www.haproxy.com/blog/state-of-ssl-stacks
tangential, but I've always wondered what the point of these random pictures of a lock, gears, or unrelated little voxel art are for? Pre-LLMs, they were often hit or miss in terms of how much they added depending on if they were a random stock image or something someone drew.
But now, with LLMs, they're more available to customize, and it seems like people aren't actually thinking anymore about why they should be there. I think I'm implicitly biasing against the rest of the content in articles which have them as a result, since it's probably a sign of some level of lack of care/thought.
You need an image for the thumbnail that's essentially required for most blog templates and in social media.
So why not put a bit of care into the image representing your work?
SEO-maxxing.
> Dropped Windows-on-Itanium (VC-WIN64I) and Windows CE (VC-CE) targets from Configurations.
What a throwback. afaik Windows Server 2008 R2 had Itanium updates until 2020 and paid support until this year. Pretty good run to say at least
Glad they kept big endian x86_64, at least.
https://github.com/openssl/openssl/blob/c69b5af10a754051274e...
Not sure if the Stratus reference is correct. Big-endian x86-64 is a real thing on HPE NonStop:
“ The executable format that works on HPE Nonstop Compute's OSS is ELF64-bit, Big_Endian, X86_64. ”
https://inbox.sourceware.org/gcc-help/AM7PR02MB6483A12F6B98D...
I kinda wonder what if Microsoft (or any major software company) would give their engineers a few decades of time just to refactor their existing systems, opposite of piling on new features. Will it result a much cleaner code, better architect, and stable product?
The last Windows I daily use was Windows 7 Home (same era with Windows Server 2008). The newer ones don't really improved much featurely from my (user) point of view, and from what I've heard, it's getting more sloppyer every newer version.
> what if Microsoft would give their engineers a few decades of time just to refactor their existing systems
They wouldn't, even if they didn't care about shipping new features. The technical complexity inside Windows/Office/old core MS offerings arises only in small part from ordinary tech debt--that is, things fixable without changing observable behavior. The lion's share of that complexity is because of Microsoft's priority to avoid breaking compatibility (backwards, or with hardware/software combos that work) at all costs.
That means that a refactor-only decade would achieve little unless that compatibility priority were changed.
The Windows user-mode innards have been significantly refactored. Many of the core system DLLs that apps link to are just redirects to the actual implementation now. Much of the jank seems to be in the UI.
It's just as likely it would end up as an overengineered mess. And that's without considering backwards compatibility constraints, which are one of the biggest maintenance burdens.
This will NOT please the shareholders. And that's all that matters.
Make you wonder what they've been testing this on. Even NetBSD doesn't have a recent release for Itanium. Crazy that you can run NetBSD 11.0 on HPPA, but not Itanium, given that HPPA is in some sense the pre-cursor to Itanium.
Age is probably less relevant than current installed base/active users
More than likely in "government"; they are always behind and keeping legacy stuff around. I found Windows 1.0 floppies in a drawer, back-in-the-day.
Honestly more HPPA gear to test against than Itanium
> Support for DTLS 1.3 (RFC 9147). Refer to the ossl-guide-dtlsv13(7) manual page for details.
DTLS 1.3 is a huge improvement over 1.2 for efficiency and simplicity. I can’t speak to the OpenSSL implementation but it’s great that support is finally released.
I think this is the only software project I use that still requires me to have perl
Interesting they're adding new support for DTLS 1.3 when afaict most new applications are defaulting to QUIC datagram mode. I have something built around DTLS 1.3 and am using wolfssl for that reason, will have to check this out.
QUIC for embedded? I haven’t seen that, but there is a lot of DTLS. Particularly with 1.3, it makes QUIC look like a behemoth in code.
Wait, OpenSSL didn't support GREASE until now? The RFC standard landed 6 years ago...
I've been linking a lot of stuff against boringssl during that time, I suppose...
I wonder what is the current marketshare of Libressl and OpenSSL ?
Mandatory reminder libressl[0] exists.
0. https://www.libressl.org/
Do you know of TLS 1.3 has been added?
Was in 2020.
[dead]
> Dropped Windows-on-Itanium
A sad day. End of an era *salute*
Microsoft pulled the plug earlier
seems like a versioning-induced death
i think a project like this would slough old architecture like mad and let major versions tick, but they forge on...
MS ended paid extended support for Itanium, so it's kind of a dead target
[flagged]
Was it verified by AI?
(Not a strange question given the recent PHP vulns found by AI.)