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>