| ▲ | hannob 5 hours ago |
| 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... |
|
| ▲ | dralley an hour ago | parent | next [-] |
| 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. |
|
| ▲ | chemodax 3 hours ago | parent | prev | next [-] |
| AWS-Lc looks very promising replacement for OpenSSL these days. |
| |
| ▲ | Bender 2 hours ago | parent [-] | | 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. | | |
| ▲ | mrweasel 2 hours ago | parent | next [-] | | 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. | |
| ▲ | otterley 2 hours ago | parent | prev [-] | | Nothing wrong with being frugal with your time! |
|
|
|
| ▲ | ahartmetz 3 hours ago | parent | prev | next [-] |
| >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? |
| |
| ▲ | woodruffw 2 hours ago | parent [-] | | 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. | | |
| ▲ | pseudosaid 2 hours ago | parent [-] | | yet you too dont have an idea why asinine decisions were championed | | |
| ▲ | woodruffw 2 hours ago | parent [-] | | I have a pretty good idea. And it has nothing to do with malice or exploitability. | | |
| ▲ | noitpmeder 2 hours ago | parent | next [-] | | Care to share...??? | | |
| ▲ | palata 2 hours ago | parent [-] | | 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. | | |
| ▲ | timschmidt an hour ago | parent [-] | | Unnecessarily complicated APIs are a security code smell precisely because they help hide bugs, leaky abstractions, insecure state, and other exploitable issues. | | |
| ▲ | palata 31 minutes ago | parent [-] | | Did I say they weren't? Not sure why I'm being downvoted here. | | |
| ▲ | timschmidt 11 minutes ago | parent [-] | | 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. |
|
|
|
| |
| ▲ | incanus77 an hour ago | parent | prev [-] | | Gee, I wonder what it could’ve been… |
|
|
|
|
|
| ▲ | spacesez-ai 3 hours ago | parent | prev [-] |
| [flagged] |
