Re: [ssllabs-discuss] Apache configuration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [ssllabs-discuss] Apache configuration

Tom Browder
On Thu, Jul 20, 2017 at 1:57 PM, Reindl Harald <[hidden email]> wrote:
>>> Am 20.07.2017 um 18:02 schrieb Tom Browder
>>>> On Thu, Jul 20, 2017 at 10:54 AM, Reindl Harald <[hidden email]>
>>>> 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)?

-Tom
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [ssllabs-discuss] Apache configuration

Tom Browder
On Thu, Jul 20, 2017 at 2:14 PM, Reindl Harald <[hidden email]> wrote:
...
> before having the cluster 2015 in VMware EVC mathcing sandybridge i thought
> "well, the hardware is capable" but VMware filtered out AVX instrcutions and
> everything using openssl crashed with "illegal cpu instuction" which proved
> the compile flags worked but the binary where magnitudes slower with AES
> than the ordinary Fedora ones - hard to say but i guess something optimized
> the AES instructions from the runtime detection away....

It sounds to my novice ears that at least some of the problem is in
the VM layer.  My system is a native-iron one so shouldn't I have a
better chance at success?

-Tom
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [ssllabs-discuss] Apache configuration

Jakob Bohm-7
In reply to this post by Tom Browder
On 20/07/2017 21:06, Tom Browder wrote:

> On Thu, Jul 20, 2017 at 1:57 PM, Reindl Harald <[hidden email]> wrote:
>>>> Am 20.07.2017 um 18:02 schrieb Tom Browder
>>>>> On Thu, Jul 20, 2017 at 10:54 AM, Reindl Harald <[hidden email]>
>>>>> 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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users