httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: httpd and OpenSSL 1.0.2
Date Fri, 29 May 2015 14:20:34 GMT
Am 29.05.2015 um 15:16 schrieb Wang, Andy:
> You might want to reconsider that unless you really really are sure you know what you're
doing.
> On a linux distro, the system installed openssl is considered a fundamental platform
infrastructure library.  I.e. many many things rely on it.  openssl versions are not backward
compatible.
>
> So if you don't rebuild all of your distro installed dependencies on openssl, you've
likedly just screwed up runtime linking of alot of things.
>
> Also, the system installed library and the openssl config makefiles may be using incompatible
soname mechanisms, which could explain why you're able to link but not run (i.e. at linktime
it may be finding the right library, but at runtime it's not).

I didn't follow the whole thread, but about linking versus running:

at link time the linker will use the files libssl.so and libcrypto.so 
(or libssl.a and libcrypto.a). Because all it is given is -lssl and 
-lcrypto as flags.

It will look in those files for an entry named SONAME. On linux you can 
see that name by issuing

objdump -p /path/to/my/libssl.so

and

objdump -p /path/to/my/libcrypto.so

Example output:

/path/to/my/libssl.so:     file format elf64-x86-64

Program Header:
...

Dynamic Section:
   NEEDED               libcrypto.so.1.0.0
   NEEDED               libdl.so.2
   NEEDED               libz.so.1
   NEEDED               libc.so.6
   SONAME               libssl.so.1.0.0
...

Version References:
   required from libc.so.6:
     0x09691a75 0x00 02 GLIBC_2.2.5

Here you can see the SONAME is libssl.so.1.0.0. This name is added as a 
dependency into the linked binary. At runtime the runtime linker will 
look for this file, not for libssl.so.

During installation of lobssl.so (resp. libcrypto.so) typically the 
files get linked using a symlink, so it would make no difference. If you 
start to overwrite parts of the system installation, the two names might 
point to different content.

About compatibility: OpenSSL 1.0.0 up to OpenSSL 1.0.2 have compatible 
APIs, that's why the SONAME ends with .1.0.0 in all three cases. It is 
definitely possible to upgrade, i.e. use a newer version in the 1.0.0 to 
1.0.2 range during runtime than was used during compile/link time. The 
other way round only holds for patch versions with the same first three 
digits.

The SSL_CONF_CTX_* symbols you were originally referring to are only 
part of 1.0.2. So it seems you compiled against header files from 1.0.2 
and likely also loinked against a 1.0.2 libssl.so, but at runtime the 
libssl.so.1.0.0 that the runtime linker finds is version 1.0.0 or 1.0.1. 
The runtime linker has a search path that is defined on the system and 
can be influenced using LD_LIBRARY_PATH. The compile time linker is also 
influenced by compile "-L" flags.

Whether some specific libssl.so (or libssl.so.1.0.0) file contains the 
symbol or not can be checked using the "nm" command:

nm /path/to/my/libssl.so1.0.0 | grep SSL_CONF_CTX

Example output here:

00000000000581a0 T SSL_CONF_CTX_clear_flags
0000000000058180 T SSL_CONF_CTX_finish
0000000000058250 T SSL_CONF_CTX_free
00000000000582f0 T SSL_CONF_CTX_new
0000000000058280 T SSL_CONF_CTX_set1_prefix
0000000000058190 T SSL_CONF_CTX_set_flags
00000000000581b0 T SSL_CONF_CTX_set_ssl
0000000000058200 T SSL_CONF_CTX_set_ssl_ctx

If the symbols are not contained you will get no hits, if they are only 
referred in the lib but contained in another depenency lib, you get a 
"U" marker instead of the "T" (also see the nm man page for more 
possible cases).

HTH

Rainer

Mime
View raw message