Bug 55182 - TLS1.3 with freeradius 3.0.17 fails
Summary: TLS1.3 with freeradius 3.0.17 fails
Status: VERIFIED DUPLICATE of bug 55247
Alias: None
Product: UCS
Classification: Unclassified
Component: Radius
Version: UCS 5.0
Hardware: Other Linux
: P5 normal
Target Milestone: ---
Assignee: UCS maintainers
QA Contact: UCS maintainers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-08 12:16 CEST by Nico Stöckigt
Modified: 2024-09-06 10:17 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.229
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2022090721000793, 2022111821000661, 2024061221000267, 2024090421000241
Bug group (optional): Usability
Customer ID:
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Stöckigt univentionstaff 2022-09-08 12:16:46 CEST
Ältere Geräte können sich nicht verbinden.

Nach einiger Recherche sieht es so aus, als würde das Problem durch freeradius 3.0.17 verursacht, in der TLS1.3 noch unvollständig implementiert ist. Siehe dazu hier: https://github.com/FreeRADIUS/freeradius-server/issues/2385

Ein Setzen von 'tls_max_version = "1.2"' in der Konfiguration des EAP Moduls behebt das Problem.
Comment 2 Nico Stöckigt univentionstaff 2022-09-08 12:37:05 CEST
freeradius 3.0.18 seems to be fixed. We should update that component.
Comment 3 Nico Stöckigt univentionstaff 2022-09-09 14:57:16 CEST
(In reply to Nico Stöckigt from comment #0)

Older devices cannot connect.

After some research, it looks like the problem is caused by freeradius 3.0.17, in which TLS1.3 is still incompletely implemented. See here: https://github.com/FreeRADIUS/freeradius-server/issues/2385

Setting 'tls_max_version = "1.2"' in the configuration of the EAP module solves the problem.
Comment 4 Mirac Erdemiroglu univentionstaff 2022-11-21 08:57:09 CET
Same on 2022111821000661
Comment 5 Jan-Luca Kiok univentionstaff 2023-02-14 15:29:53 CET
The customer noted that newer devices can be affected too as long as they do not prioritize a TLS version.
Comment 6 Mirac Erdemiroglu univentionstaff 2023-02-14 17:39:17 CET
To set the TLS Version via UCRV is maybe the sustainably for our product i guess
Comment 7 Mirac Erdemiroglu univentionstaff 2024-06-12 16:16:31 CEST
2024061221000267 - Customer needs to use TLS 1.3

The freeradius version 3.017 is currently available for UCS 5.0-x. Will we make a version of freeradius available with a patch level update or a minor level update so that TLS 1.3 can be used?
Comment 8 Jan-Luca Kiok univentionstaff 2024-07-09 17:05:54 CEST
TLS 1.2 is still a valid and supported version, support for TLS 1.3 in UCS 5.0 would therefore be a feature request for me.

Making the max. TLS version configurable was done via https://forge.univention.org/bugzilla/show_bug.cgi?id=55247

In most cases forcing the version should solve the problem, if not the client can often be configured in a similar way. (see the link below for Windows 11)

Apart from that we evaluated if an update of FreeRADIUS in UCS 5.0 is feasible, but discovered some issues on the way which deter me from investigating this further for now.

So all in all I am going to close this bug as of now. If there is a need to have this solved in an alternative fashion before UCS 5.2 let me know.

FYI: This is also what the Linuxmuster community came up with: https://ask.linuxmuster.net/t/wpa2-enterprise-mit-freeradius-und-win11-22h2/9675/2

*** This bug has been marked as a duplicate of bug 55247 ***