TLS errors and clients sometimes rejected

[Alan DeKok]

On Sep 17, 2024, at 11:06 AM, Rodrigo Abrantes Antunes <rodrigoantunes at pelotas.ifsul.edu.br> wrote:
> cipher_list = "DEFAULT at SECLEVEL=0"
> tls_min_version = "1.0"
> tls_max_version = "1.2"
> 
> These options doesn't say that freeradius should support all tls versions until 1.2? Why freeradius wouldn't like the TLS version used by the client?

  That configuration tells FreeRADIUS to use TLS 1.0, 1.1, and 1.2.

  But it disallows TLS 1.3.  So... if FreeRADIUS doesn't like the TLS version, that would likely be it.

> And why sometimes the same clients are accepted?

  Look at the logs.  It's not possible to debug complicated TLS issues by looking at 3-4 lines of TLS logs.

> I have another freeradius server version 2.2.5 that don't have this problem, all users can use the internet no matter the client's tls version.\

  2.2.5 doesn't support TLS 1.3.

  Plus, what is likely here is that the server running 2.2.5 is also running a very old version of OpenSSL.  Which allows many deprecated TLS ciphers, etc.

  The server running 3.2 is using a new version of OpenSSL, which doesn't allow old / deprecated / insecure TLS ciphers.  That's likely why old systems fail to connect.

> 
>> There's little to do except upgrade the client.
> 
> These are android devices that can't upgrade. I can't ask the students to buy another cellphone and I need to allow them to access the internet.

  Then use 2.2.5 and an old version of OpenSSL.

  At some point, the old TLS ciphers will be officially deprecated and unsupported.  At which point they won't work.

  This isn't really a FreeRADIUS issue.  FreeRADIUS uses OpenSSL for all TLS negotiation.  If OpenSSL says it doesn't like the client (or vice versa), then there is often very little that FreeRADIUS can do to fix it.

  Configure OpenSSL (e.g. cipher_list) so that it works with a new version of OpenSSL.  Or, use an old version of OpenSSL.  There really aren't many other choices.

  Alan DeKok.