Download Openssl 1.1.1 Ubuntu
Indira Rossetto
After test different haproxy versions (the one shipped by ubuntu, 2.4, and 2.7.3) and different openssl versions (the one shipped by ubuntu, 3.0.2, and 3.0.7) we always see blocking issues in the TLS handsake under high load.
Unfortunately there is no solution, other than to downgrade. Openssl 3.0 is extremely problematic for multi-threading loads, this has nothing to do with haproxy but with changes within openssl 3.0 itself, please see:
This would be particularly useful given it's often impossible to get an older openssl version on a system
(and if one compiles their own, then system packages like databases won't link against the manually-compiled libssl and so typically segfault due to 2 libssl loaded in the same process).
Thank you for the idea Mame. I think that would maybe not work with people using bundle exec to load their program as that gem is not on the load path, but I could consider compiling without openssl and then detecting and requiring customers to add that gem to their Gemfile via logic in the buildpack. I'm assuming that if someone adds that gem to their buildpack all other gems depending on openssl would "just work" even if Ruby is not compiled with openssl support? It sounds like that is the case.
I am curious about the difference between and I do not fully understand the cost or difficulty of maintaining openssl support in Ruby. On the surface it seems that they are the same. I am curious if there is a deeper issue preventing using the newer version in Ruby 2.7 and 3.0?
However, doing this will introduce slight incompatible changes. The changes are outlined in openssl gem's changelog ("Compatibility notes" section for 3.0.0 (and also for 2.2.0 if backporting to ruby_2_7)):
Having helped several co-workers to install ruby-2.7 and 3.0 on their Ubuntu-22.04, I support backporting the openssl-3.0 gem to these ruby versions, similar to how Ubuntu patched their ruby-3.0 package. While it's preferable to use the latest ruby version in development, it's often necessary to verify or debug issues on older versions.
@mame (Yusuke Endoh) I tried your approach and it seems to work (I tried on Fedora 36).
I was thinking the make would fail but CRuby 3.0.3 has an early check for openssl 3 and so it works as described.
CRuby 3.0.2 OTOH does not have that check, so needs ./configure --prefix=... --without-openssl.
It's not convenient and it feels suboptimal to have to replicate this workaround manually and in various Ruby installers though.
FWIW, in the context of ruby-build and how to deal with system openssl version mismatch, I was wondering if this technique also works for older Rubies (e.g. Ruby 2.3's openssl gem which wants libssl 1.0), but probably not given that the openssl gem 3.0.0 release needs Ruby >= 2.6.
So I guess for building really old Ruby versions on latest OS (when there is no choice, e.g. setup-ruby, obviously best to avoid the combination), one needs to build their own openssl.
I think backporting openssl gem 3.0.0 to Ruby 2.7 and Ruby 3.0 (and have releases of these 2 with it) would be very helpful.
That'd mean dropping OpenSSL 1.0.1 support in 2.7/3.0, which seems fine enough, only pretty old OS have that, and they can still use older Ruby releases until those users update their OS and ancestral OpenSSL.
(They could maybe even apply your workaround in the other way, to install an older openssl gem.)
Issue at ruby/openssl to have a release supporting OpenSSL 1.0.1 - 3.0.0:
If there is such a release it should be a no-brainer for Ruby 2.7 and 3.0 to directly support OpenSSL 3.
The next TruffleRuby release supports Ruby 3 and OpenSSL 3, and we did not have even have to drop any supported platforms since OpenSSL 1.0.1 is only used by ancient OS.