FreeRADIUS SSL version check
On a clean CentOS 6.6 host I built an RPM from the 3.0.x branch from git. It compiles and links OK, but when I run it I get: Wed Jan 7 11:57:35 2015 : Error: libssl version mismatch. built: 1000105f linked: 10000003 and the service fails to start. Am I doing something wrong in building the RPM, or is there a problem with the check? Both my FreeRADIUS sources and my CentOS host are up-to-date. Thanks. Bruce Bauman - Systems Administrator Telecommunications Division - Rutgers University University Network Architecture and Applications Office: 848.445.6363
On Jan 7, 2015, at 12:02 PM, Bruce Bauman <bbauman@oit.rutgers.edu> wrote:
On a clean CentOS 6.6 host I built an RPM from the 3.0.x branch from git. It compiles and links OK, but when I run it I get:
Wed Jan 7 11:57:35 2015 : Error: libssl version mismatch. built: 1000105f linked: 10000003
and the service fails to start. Am I doing something wrong in building the RPM, or is there a problem with the check?
The check is correct. You have two versions of OpenSSL installed.
Both my FreeRADIUS sources and my CentOS host are up-to-date.
Maybe you’re building the RPM on a system with version 1.1.5f of OpenSSL, and installing it on a system which has only 1.0.3. The issue is that OpenSSL changes its internal data structures in minor releases. We’ve previously had FreeRADIUS crash when people “upgrade” their OpenSSL… and the data structures are different. We want to blame OpenSSL for the problem, rather than having people complain that FreeRADIUS crashes. Alan DeKok.
Could static linking libssl in be made easier? I haven't tried recently, but often it's really hard with autoconf. Sure, this means updating freeradius when/if openssl has another security issue, but it also isolates freeradius from system updates. Being able to build on one machine and deploy to another machine such that one doesn't have to install a compiler is a big win to me. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
On Jan 7, 2015, at 1:54 PM, Michael Richardson <mcr@sandelman.ca> wrote:
Could static linking libssl in be made easier?
Systems ship with static libraries?
I haven't tried recently, but often it's really hard with autoconf.
Which is why v3 no longer uses libtool, libltdl. In a modern system, they make life *worse*.
Sure, this means updating freeradius when/if openssl has another security issue, but it also isolates freeradius from system updates.
That’s why it’s configurable.
Being able to build on one machine and deploy to another machine such that one doesn't have to install a compiler is a big win to me.
Then be sure that both systems have the same version of OpenSSL. Or, do: $ ./configure --disable-openssl-version-check And don’t complain if the server crashes inside of OpenSSL. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote: > On Jan 7, 2015, at 1:54 PM, Michael Richardson <mcr@sandelman.ca> > wrote: >> Could static linking libssl in be made easier? > Systems ship with static libraries? whenever you install the -dev package, you usually get the .a as well. So, they don't ship with static libraries, because being static, they are included in the binary :-) >> I haven't tried recently, but often it's really hard with autoconf. > Which is why v3 no longer uses libtool, libltdl. In a modern system, > they make life *worse*. Agreed. >> Being able to build on one machine and deploy to another machine such >> that one doesn't have to install a compiler is a big win to me. > Then be sure that both systems have the same version of OpenSSL. 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. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
On Thu, Jan 8, 2015 at 8:16 AM, Michael Richardson <mcr@sandelman.ca> wrote:
Alan DeKok <aland@deployingradius.com> wrote: > On Jan 7, 2015, at 1:54 PM, Michael Richardson <mcr@sandelman.ca> > wrote: >> Could static linking libssl in be made easier?
> Systems ship with static libraries?
whenever you install the -dev package, you usually get the .a as well. So, they don't ship with static libraries, because being static, they are included in the binary :-)
IIRC solaris stops providing static libs since solaris 10. Redhat did the same around fedora core 6.
> Then be sure that both systems have the same version of OpenSSL.
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.
Distros that I know are sane enough to have compatible versions of programs and libs. Some (like RH) backports necessary security fixes only without bumping major/minor version numbers. There are also ways (e.g. ubuntu ppa, opensuse build service) to enable building for multiple distro versions in the correct environment. Is there a particular case where you experience a distro release two supported programs where one uses lib version X and the other version Y? -- Fajar
On Jan 7, 2015, at 8:16 PM, Michael Richardson <mcr@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. Alan DeKok.
On 8 Jan 2015, at 20:41, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 7, 2015, at 8:16 PM, Michael Richardson <mcr@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 13 Jan 2015, at 15:31, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 8 Jan 2015, at 20:41, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 7, 2015, at 8:16 PM, Michael Richardson <mcr@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.
To clarify that was for the OP's original question, not the largely pointless discussion on static linking that followed. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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@freeradius.org> wrote:
On 8 Jan 2015, at 20:41, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 7, 2015, at 8:16 PM, Michael Richardson <mcr@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@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
On 13 Jan 2015, at 20:59, Bruce Bauman <bbauman@oit.rutgers.edu> wrote:
Was this fix ever committed? I couldn’t find it.
Yes, yesterday. bc31033eb8d5be2cc1aac65e8919b531a1080d89 -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Never mind - I found the commit. — Bruce Bruce Bauman - Systems Administrator Telecommunications Division - Rutgers University University Network Architecture and Applications Office: 848.445.6363
On Jan 13, 2015, at 9:04 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 13 Jan 2015, at 20:59, Bruce Bauman <bbauman@oit.rutgers.edu> wrote:
Was this fix ever committed? I couldn’t find it.
Yes, yesterday. bc31033eb8d5be2cc1aac65e8919b531a1080d89
-Arran
Arran Cudbard-Bell <a.cudbardb@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
On 13 Jan 2015, at 21:37, Bruce Bauman <bbauman@oit.rutgers.edu> wrote:
Never mind - I found the commit.
Yeah it was the one I posted the commit hash for... A whole 9 entries deep in the commit log... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jan 13, 2015, at 3:31 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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).
Huh? I’m sure there’s a reason for that… but it looks insane to me. Alan DeKok.
On 8 Jan 2015, at 02:00, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 7, 2015, at 1:54 PM, Michael Richardson <mcr@sandelman.ca> wrote:
Could static linking libssl in be made easier?
Systems ship with static libraries?
I haven't tried recently, but often it's really hard with autoconf.
Which is why v3 no longer uses libtool, libltdl. In a modern system, they make life *worse*.
Sure, this means updating freeradius when/if openssl has another security issue, but it also isolates freeradius from system updates.
That’s why it’s configurable.
Being able to build on one machine and deploy to another machine such that one doesn't have to install a compiler is a big win to me.
Then be sure that both systems have the same version of OpenSSL.
Or, do:
$ ./configure --disable-openssl-version-check
That only disables the check for vulnerable versions of libssl, not the consistency checks. The patch counter of the libssl version can be incremented without triggering the error. This is the same as the checks OpenSSH does IIRC. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Bruce Bauman -
Fajar A. Nugraha -
Michael Richardson