FreeRADIUS SSL version check

Bruce Bauman bbauman at oit.rutgers.edu
Tue Jan 13 14:59:13 CET 2015


Was this fix ever committed?  I couldn’t find it.

— Bruce

Bruce Bauman - Systems Administrator
Telecommunications Division - Rutgers University
University Network Architecture and Applications
Office:  848.445.6363









> On Jan 13, 2015, at 3:31 AM, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> 
> 
>> 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 
> problem.
> 
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS development team
> 
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html




More information about the Freeradius-Devel mailing list