Radsecproxy application is unable to establish secure connection with the RADSEC server, after OpenSSL upgrade from 1.1.1t to 3.0.8.
It was working earlier in OpenSSL v1.1.1t.
Getting below error messages in radsecproxy logs
Wed Jan 31 05:02:59 2024: tlsconnect: SSL connect to 13.200.253.194 failed: error:0A000126:SSL routines::unexpected eof while reading
Radsecproxy version : v1.9.1
Hi Irfan,
On 26.04.23, 08:20, "Irfan Sheik" <irfans(a)niagaranetworks.com <mailto:irfans@niagaranetworks.com>> wrote:
We are trying to do cross-compilation (ARMv7(32-bit) on an X86 PC)
The build system is not primarily intended for cross-compilation. It uses gnu autotools, so maybe their guide can give you some guidance:
https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilatio…
Or you have to refer to the cross-compile build system that is used for the base system (openwrt, buildroot or the like).
I'm sorry I can't help you any more with that.
BR,
Fabian
--
Fabian Mauchle, Network
SWITCH
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39
Hi Irfan,
On 25.04.23, 15:46, "Irfan Sheik" <irfans(a)niagaranetworks.com <mailto:irfans@niagaranetworks.com>> wrote:
Is the radsecproxy supported on a 32-bit ARM processor?
Generally yes. radsecproxy is a source code release (written in C), so it should compile on any posix like system that provides the required libraries (openssl and nettle). In fact, Debian package are built for armel, armhf and arm64.
If yes, Kindly share the configuration procedures
For configuration of radsecproxy, please see the radsecproxy.conf manpage and example radsecproxy.conf.
BR,
Fabian
--
Fabian Mauchle, Network
SWITCH
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39
Dear colleagues,
Recently I tried to install radsecproxy 1.9.1 from source to Red Hat 9 server for our Kazakhstan eduroam server, but received the error:
"checking for nettle_sha256_init in -lnettle... no configure: error: required library nettle not found"
I checked whether the nettle library has been installed. It has:
"Package nettle-3.7.3-2.el9.x86_64 is already installed."
Please, help me to solve the problem.
Regards, Talgat Nurlybayev
KazRENA
Hi All,
I'm currently working on pull-request #72. This uses some language features of C99 to make the code somewhat more readable (previously, all code was C90 style).
Enabling C99 style should not be an issue for modern systems (even down to Debian jessie).
But: is anyone out there using a compiler that won't support C99 dialect?
Thanks and best regards,
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39
Hi
Just a heads up for people who're upgrading to 1.9.0: if you have been
using an OPENSSL_CONF environment variable to change the way radsecproxy
handles TLS connections, then the new TLS options (TlsVersion,
DtlsVersion) may introduce breaking changes.
In our environment, we set:
MinProtocol = TLSv1
CipherString = DEFAULT@SECLEVEL=1
in an OpenSSL config file pointed to by OPENSSL_CONF. We were doing this
because a number of NROs (and eduroam CAT) don't support the newer TLS
versions mandated by our operating system, and fail to connect if TLS
1.0 cannot be negotiated. I'm led to believe that there's also a bug in
Radiator (widely used) that results in this behaviour.
We had incorrectly (and perhaps naïvely) assumed that leaving out the
new TlsVersion options would result in radsecproxy using OpenSSL's
defaults, including honouring OPENSSL_CONF (the release notes don't hint
otherwise, and nor does the manual page). However, that does not appear
to be the case and after we upgraded to 1.9.0, this stopped working.
Unfortunately because our monitoring system was testing using a modern
TLS version, we didn't notice this until someone complained :-/.
Post upgrade, it seems there's a hardcoded default minimum TLS version
of TLS 1.1 even if the OS itself defaults to a lower minimum. The only
way to restore the previous behaviour is to explicitly set a lower
minimum TlsVersion/DtlsVersion in the config file.
We've fixed the problem. I'm really just mentioning it here so that
others aren't caught by surprise/don't make the same mistake :-). I'll
submit a pull request/issue updating the documentation too.
Regards,
- Guy
--
https://www.tenet.ac.za/ Guy Halse
Executive Officer: Trust & Identity
Tertiary Education & Research Network of South Africa NPC
Fault Reporting: +27(21)763-7147 <tel:+27(21)763-7147> or
support(a)tenet.ac.za <mailto:support@tenet.ac.za>
Office: +27(21)763-7102
http://www.tenet.ac.za/contact <http://www.tenet.ac.za/contact>
https://orcid.org/0000-0002-9388-8592
<https://orcid.org/0000-0002-9388-8592>
A vulnerability has been found in the dyndisc example scripts (naptr-eduroam.sh, radsec-dynsrv.sh) provided with radsecproxy.
For details, see https://github.com/radsecproxy/radsecproxy/security/advisories/GHSA-56gw-9r…
Updated example scripts are provided with the 1.9.0 release. Note that the scripts are not part of the installation package and are not updated automatically. If you are using the examples, you have to update them manually.
Best regards,
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39
Dear radsecproxy community,
radsecproxy 1.9.0 release has now been published:
https://github.com/radsecproxy/radsecproxy/releases/tag/1.9.0
Many thanks to all who have helped in developing, testing and fixing it!
Best regards,
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39
Hi all,
The release candidate for radsecproxy 1.9.0 has just been published:
https://github.com/radsecproxy/radsecproxy/releases/tag/1.9.0-rc1
Any testing is highly appreciated.
Please report any issues on github or on this mailing list.
Best regards,
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39
