FreeRADIUS SSL version check
a.cudbardb at freeradius.org
Tue Jan 13 09:31:15 CET 2015
> On 8 Jan 2015, at 20:41, Alan DeKok <aland at deployingradius.com> wrote:
> On Jan 7, 2015, at 8:16 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>> It's hard if you also have other things which want *different* versions of
>> OpenSSL... really, if they shared libraries are not compatible, the .so files
>> should have their version number bumped, but I know that this is hard for
>> some distros.
> OpenSSL has a wonderful habit of making header files for (e.g.) 1.0.1 incompatible with the binaries for 1.0.2. As a result, upgrades can cause your application to crash.
> FreeRADIUS runs into this more than most applications. Most applications just use the SSL_read() and SSL_write() APIs to deal with TCP connections. So they don’t need to get into the internals of SSL behaviour. FreeRADIUS has to extract SSL from EAP, and in turn RADIUS. So it has to do unusual (but allegedly legal) things with OpenSSL.
> The OpenSSL APIs lie to you. They say you can do something, which is true. What they *don’t* say is that they change in random incompatible ways at a moments notice.
> I gave up on APR years ago for similar reasons.
A fix for this was contributed by Philippe Wooding, who doesn't read the lists but
deserves recognition anyway :).
It's due to the OpenSSL libraries on RHEL and its variants having multiple versions of
the SSLeay() symbol (the function used to retrieve the OpenSSL version).
If OpenSSL was only transitively linked to the binary calling SSLeay() the wrong version
was used. Linking libfreeradius-server directly against libssl seems to have fixed the
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
More information about the Freeradius-Devel