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
Hi Guy,
On 02.08.21, 11:43, "Guy Halse" guy@tenet.ac.za wrote: 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.
Thanks for spotting this. Indeed the code does unconditionally set the min version (and thus ignores the system config), and also the max version (to 'any' if not configured). Instead of just documenting this, I would rise the question if this is rather a bug that should be fixed? (i.e. use the system defaults if not set in the radsecproxy config, or from a code perspective, don’t call SSL_CTX_set_min_proto_version() if not configured in radsecproxy)
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
On 2021/08/10 17:26, Fabian Mauchle wrote:
Indeed the code does unconditionally set the min version (and thus ignores the system config), and also the max version (to 'any' if not configured). Instead of just documenting this, I would rise the question if this is rather a bug that should be fixed? (i.e. use the system defaults if not set in the radsecproxy config, or from a code perspective, don’t call SSL_CTX_set_min_proto_version() if not configured in radsecproxy)
Sure, that would be my preference since it would be backwards compatible. However given it was done explicitly, I'd assumed it was an intentional attempt to raise security (hence documenting rather than reverting).
Regards,
- Guy
-
Fabian Mauchle -
Guy Halse