Bug#919234: ttls fails with tls 1.3, enabled by default

2023-03-07 Thread Bernhard Schmidt

Control: tags -1 + pending

Hi Fabio,

Am 07.03.23 um 17:00 schrieb Fabio PEDRETTI:

Hi, 3.2.1 currently in testing fixed most issues, however there is
still an issue preventing freeradius working with TLS 1.3.

The issue was reported upstream at:
https://github.com/FreeRADIUS/freeradius-server/issues/4878
and the commit fixing it is:
https://github.com/FreeRADIUS/freeradius-server/commit/0812bc1768cedc420adc03e86893d798fa19e872

That commit is already included in upstream 3.2.2.

So please consider upgrading to 3.2.2 (suggested, given this release
also fixes some other bugs), or apply the mentioned commit.

I updated the severity and forwarded bug reflecting this.


Thanks a lot for the investigation.

I have just uploaded 3.2.1-2 to the archive, could you please test this 
version? Importing the new 3.2.2 upstream version at this stage of the 
release freeze is not possible, see 
https://release.debian.org/testing/freeze_policy.html .


Bernhard



Bug#919234: ttls fails with tls 1.3, enabled by default

2023-03-07 Thread Fabio PEDRETTI
Hi, 3.2.1 currently in testing fixed most issues, however there is
still an issue preventing freeradius working with TLS 1.3.

The issue was reported upstream at:
https://github.com/FreeRADIUS/freeradius-server/issues/4878
and the commit fixing it is:
https://github.com/FreeRADIUS/freeradius-server/commit/0812bc1768cedc420adc03e86893d798fa19e872

That commit is already included in upstream 3.2.2.

So please consider upgrading to 3.2.2 (suggested, given this release
also fixes some other bugs), or apply the mentioned commit.

I updated the severity and forwarded bug reflecting this.

Thanks!

-- 


Informativa sulla Privacy: https://www.unibs.it/it/node/1452 




Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

2022-10-13 Thread Rafael Varela Pet



We have detected a number of issues in the Eduroam service with the 
latest Windows 11 22H2 that are related with the newly 
enabled-by-default usage of TLS v1.3 for EAP-TTLS and PEAP. This 
problems have been detected by other Eduroam providers:


https://lists.geant.org/sympa/arc/cat-users/2022-10/msg00040.html

It seems that only the newest Freeradius v3.0.26 and v3.2.0+ support TLS 
v1.3 correctly and since Windows 11 22H2 has now enabled TLS v1.3 by 
default also for EAP-TTLS and PEAP, the issue started emerging and 
diffusing quickly as the Windows update started being rolled out to users.


So this is becoming a big issue for those Eduroam providers that run 
Freeradius on Debian and it would be great to have the 3.0.26 necessary 
patches migrated to the stable package.


Thanks in advance.

Kind regards,
--
Rafael Varela Pet
Subdirector de Infraestructuras
Área de Tecnoloxías da Información e Comunicacións

Universidade de Santiago de Compostela
15782 Santiago de Compostela
https://www.usc.gal/atic



Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

2019-01-14 Thread Sam Hartman
control: forwarded -1
https://github.com/FreeRADIUS/freeradius-server/issues/2385

I'll try to get a patch for this if we don't hear something interesting
from upstream soon.
I think I'm in a better position than most in Debian to write such a
patch.
However I'm fairly busy.



Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

2019-01-13 Thread Michael Stapelberg
I have no time to look into this. Can you send a patch please?

On Sun, Jan 13, 2019 at 11:33 PM Sam Hartman  wrote:

> package: freeradius
> severity: important
> version: 3.0.17+dfsg-1
> justification: regression that totally breaks connectivity
> tags: upstream
>
>
> I've cc'd Kurt because he requested openssl 1.3 test results a while
> back.
>
> While writing automated tests for moonshot-gss-eap, I discovered that
> by default freeradius will not constrain  the version of TLS in use
> (probably good), but that its ttls implementation fails with TLS 1.3.
> Things work fine if I explicitly set the max TLS version to 1.2.
>
> Based on the errors I suspect that  the issue had to deal with the
> handling of the ttls TLS session ticket used by TTLS for fast
> reauthentication.
> My suspicion (and recollection from the spec) is that ttls knows more
> about session internals than it should.
>
> As a quick fix, I think the ttls code should limit the maximum TLS
> version to 1.2 until the code can be fixed to work with 1.3.
>
>
> Please do not limit all freeradius uses of TLS to 1.2: in particular I'd
> really like to be able to use tls 1.3 with radsec.
> Also, I strongly recommend making this change in code not in config
> files.  People tend not to update their configs once they get one
> working.
>
> To reproduce, grab the moonshot-gss-eap sources.
> Comment out the TLS_MAX_VERSION on line 366 of
> debian/tests/freeradius/eap and then rerun autopkgtest on the resulting
> source package.
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael


Bug#919234: ttls fails with tls 1.3, enabled by default

2019-01-13 Thread Sam Hartman
package: freeradius
severity: important
version: 3.0.17+dfsg-1
justification: regression that totally breaks connectivity
tags: upstream


I've cc'd Kurt because he requested openssl 1.3 test results a while
back.

While writing automated tests for moonshot-gss-eap, I discovered that
by default freeradius will not constrain  the version of TLS in use
(probably good), but that its ttls implementation fails with TLS 1.3.
Things work fine if I explicitly set the max TLS version to 1.2.

Based on the errors I suspect that  the issue had to deal with the
handling of the ttls TLS session ticket used by TTLS for fast
reauthentication.
My suspicion (and recollection from the spec) is that ttls knows more
about session internals than it should.

As a quick fix, I think the ttls code should limit the maximum TLS
version to 1.2 until the code can be fixed to work with 1.3.


Please do not limit all freeradius uses of TLS to 1.2: in particular I'd
really like to be able to use tls 1.3 with radsec.
Also, I strongly recommend making this change in code not in config
files.  People tend not to update their configs once they get one
working.

To reproduce, grab the moonshot-gss-eap sources.
Comment out the TLS_MAX_VERSION on line 366 of
debian/tests/freeradius/eap and then rerun autopkgtest on the resulting
source package.