This patch documents the hardcoded minimum TLS version in the man page.

Per my email to the mailing list:

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.