[openssl-users] [ssllabs-discuss] Apache configuration

Jakob Bohm jb-openssl at wisemo.com
Thu Jul 20 20:32:31 UTC 2017


On 20/07/2017 21:06, Tom Browder wrote:
> On Thu, Jul 20, 2017 at 1:57 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>>> Am 20.07.2017 um 18:02 schrieb Tom Browder
>>>>> On Thu, Jul 20, 2017 at 10:54 AM, Reindl Harald <h.reindl at thelounge.net>
>>>>> wrote
> ...
>>> P.S.  Of course the other part of my motivation in the past has been
>>> to see if it can be made to work, regardless of need (due to my
>>> butt-head gene from my father's side of the family)
> ...
>> well, openssl is the straight to hell
>>
>> load something into your webserver built against 1.1 and have fun when a
>> system library loads 1.0.x by watching the crash
> Then what about Ivan's recommendation about installing openssl
> alongside a system-wide one?  If that can't be done reliably, surely
> there has been a bug report submitted. (I haven't looked at bugs in a
> long time)?
The "DLL hell" problem only happens if someone either:

- Doesn't install with proper so-versioning (with proper so-versioning
  1.0.x is installed as libssl.so.1.0.0 and libcrypto.so.1.0.0 while
  1.1.x is installed as libssl.so.1.1.0 and libcrypto.so.1.1.0).

- Uses a non-unix-like OS where the compilation script doesn't include
  a version number in the DLL file names (that would be a bug in OpenSSL
  1.1.x).

- Uses a 3rd party web server plugin (not an out-of-process cgi) and
  either that plugin or the web server which is compiled/linked to not
  use strongly versioned imports for the OpenSSL functions (this only
  happens with the silly unix-style DLL loader semantics that default
  to ignoring the DLL from which a symbol is imported).

Question to OpenSSL devs: Do the recommended instructions for linking
applications to OpenSSL 1.1.x on unix-like systems ensure strong symbol
versioning so the dynamic loader doesn't mix up symbols from another
OpenSSL version loaded elsewhere in the process?


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



More information about the openssl-users mailing list