Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 2024-04-17, Federico Giannici wrote:
> On 4/17/24 16:34, Stuart Henderson wrote:
>> On 2024-04-17, Kapetanakis Giannis wrote:
>>> One idea if you have old devices that cannot upgrade to a newer SSL/TLS
>>> protocol would be to run some kind of proxy between the client and the
>>> radius server (stunnel?)
>>>
>>> Don't know how well this plays with EAP.
>>> Maybe this will only work with EAP-TTLS ?
>>
>> That isn't going to work.
>>
>>> Another idea, since you run your own custom freeradius, is to recompile it
>>> and link with another openssl library that has old SSL/TLS enabled.
>>
>> That may be an option, if you don't need some other library which pulls
>> in libssl/libcrypto (otherwise there will be a conflict).
>
>
> I'm trying to do that.
>
> I found that with normal linker I can substitute "-lcrypto" with
> "-l:libcrypto.so.50.2", and so long...
>
> But FreeRadius uses libtool and it gives the following warnings and
> don't generate any ".so" file:
>
> *** Warning: linker path does not have real file for library
> -l:libcrypto.so.50.2.
> *** I have the capability to make that library automatically link in when
> *** you link to this library. But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with lib:libcrypto.so.50.2 and none of the candidates passed a file
> format test
> *** using a regex pattern. Last file checked: /usr/lib/libexecinfo.so.3.0
>
>
> Any suggestions on how to make libtool use a specific library version?
Normally by passing directories via -L in the order you want. Though
this may be more complicated than usual in freeradius which uses its
own special libtool ("jlibtool").
(You also need to ensure that the headers from openssl are used, not
mismatching ones).
--
Please keep replies on the mailing list.
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 4/17/24 16:34, Stuart Henderson wrote: On 2024-04-17, Kapetanakis Giannis wrote: One idea if you have old devices that cannot upgrade to a newer SSL/TLS protocol would be to run some kind of proxy between the client and the radius server (stunnel?) Don't know how well this plays with EAP. Maybe this will only work with EAP-TTLS ? That isn't going to work. Another idea, since you run your own custom freeradius, is to recompile it and link with another openssl library that has old SSL/TLS enabled. That may be an option, if you don't need some other library which pulls in libssl/libcrypto (otherwise there will be a conflict). I'm trying to do that. I found that with normal linker I can substitute "-lcrypto" with "-l:libcrypto.so.50.2", and so long... But FreeRadius uses libtool and it gives the following warnings and don't generate any ".so" file: *** Warning: linker path does not have real file for library -l:libcrypto.so.50.2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with lib:libcrypto.so.50.2 and none of the candidates passed a file format test *** using a regex pattern. Last file checked: /usr/lib/libexecinfo.so.3.0 Any suggestions on how to make libtool use a specific library version? Thanks
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 17/04/2024 17:37, Federico Giannici wrote: > On 4/17/24 15:19, Stuart Henderson wrote: >> This is most likely because of: >> >> https://www.openbsd.org/74.html >> "Disabled TLSv1.0 and TLSv1.1 in libssl so that they may no longer be >> selected for use." >> >> I don't think there's anything simple you can do to reenable it. > > They are "disabled" or completely "removed" from the source/compilation? > > Thanks. https://github.com/libressl/openbsd/commit/ddcb4efd6551a982bf29b2e8e83c9c808a1670dc G
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 4/17/24 15:19, Stuart Henderson wrote: On 2024-04-17, Federico Giannici wrote: Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) the FreeRadius EAP authentication no longer works! We are using a custom version of FreeRadius (because we had to do some little changes and a module of our own), and everything worked correctly for many years. Now, with 7.5, it gives the following errors for EAP authentications (everything else is OK): Apr 14 11:29:24 Eldarion radiusd[73262]: TLS Alert write:fatal:protocol version Apr 14 11:29:24 Eldarion radiusd[73262]: TLS_accept: error in SSLv3 read client hello B Apr 14 11:29:24 Eldarion radiusd[73262]: rlm_eap: SSL error error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number Apr 14 11:29:24 Eldarion radiusd[73262]: SSL: SSL_read failed in a system call (-1), TLS session fails. Apr 14 11:29:24 Eldarion radiusd[73262]: Login incorrect (TLS Alert write:fatal:protocol version): [anonym...@myisp.com/] (from client wdsl_neomedia nas 10.10.215.101 port 0 cli FC-EC-DA-2A-F5-7F service wdsl-neomedia) I guess that the new LibreSSL version have some new restricted requirements. And we CANNOT change the client's OpenSSL version or certs (they are Ubiquiti devices). Some time ago (I think upgrading to 7.3) we had to add "SSL_CTX_set_security_level( ctx, 0 );" to make it work. So we already have set Security Level to 0. Is there something else we can do to make LibreSSL accept everything it accepted in previous release? This is most likely because of: https://www.openbsd.org/74.html "Disabled TLSv1.0 and TLSv1.1 in libssl so that they may no longer be selected for use." I don't think there's anything simple you can do to reenable it. They are "disabled" or completely "removed" from the source/compilation? Thanks.
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 2024-04-17, Kapetanakis Giannis wrote: > One idea if you have old devices that cannot upgrade to a newer SSL/TLS > protocol would be to run some kind of proxy between the client and the radius > server (stunnel?) > > Don't know how well this plays with EAP. > Maybe this will only work with EAP-TTLS ? That isn't going to work. > Another idea, since you run your own custom freeradius, is to recompile it > and link with another openssl library that has old SSL/TLS enabled. That may be an option, if you don't need some other library which pulls in libssl/libcrypto (otherwise there will be a conflict). -- Please keep replies on the mailing list.
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 17/04/2024 16:19, Stuart Henderson wrote: > On 2024-04-17, Federico Giannici wrote: >> Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) >> the FreeRadius EAP authentication no longer works! >> >> We are using a custom version of FreeRadius (because we had to do some >> little changes and a module of our own), and everything worked correctly >> for many years. >> >> Now, with 7.5, it gives the following errors for EAP authentications >> (everything else is OK): >> >> Apr 14 11:29:24 Eldarion radiusd[73262]: TLS Alert write:fatal:protocol >> version >> Apr 14 11:29:24 Eldarion radiusd[73262]: TLS_accept: error in SSLv3 >> read client hello B >> Apr 14 11:29:24 Eldarion radiusd[73262]: rlm_eap: SSL error >> error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number >> Apr 14 11:29:24 Eldarion radiusd[73262]: SSL: SSL_read failed in a >> system call (-1), TLS session fails. >> Apr 14 11:29:24 Eldarion radiusd[73262]: Login incorrect (TLS Alert >> write:fatal:protocol version): [anonym...@myisp.com/> EAP>] (from client wdsl_neomedia nas 10.10.215.101 port 0 cli >> FC-EC-DA-2A-F5-7F service wdsl-neomedia) >> >> I guess that the new LibreSSL version have some new restricted >> requirements. And we CANNOT change the client's OpenSSL version or certs >> (they are Ubiquiti devices). >> >> Some time ago (I think upgrading to 7.3) we had to add >> "SSL_CTX_set_security_level( ctx, 0 );" to make it work. So we already >> have set Security Level to 0. >> >> Is there something else we can do to make LibreSSL accept everything it >> accepted in previous release? > This is most likely because of: > > https://www.openbsd.org/74.html > "Disabled TLSv1.0 and TLSv1.1 in libssl so that they may no longer be > selected for use." > > I don't think there's anything simple you can do to reenable it. One idea if you have old devices that cannot upgrade to a newer SSL/TLS protocol would be to run some kind of proxy between the client and the radius server (stunnel?) Don't know how well this plays with EAP. Maybe this will only work with EAP-TTLS ? Another idea, since you run your own custom freeradius, is to recompile it and link with another openssl library that has old SSL/TLS enabled. G
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 2024-04-17, Federico Giannici wrote: > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) > the FreeRadius EAP authentication no longer works! > > We are using a custom version of FreeRadius (because we had to do some > little changes and a module of our own), and everything worked correctly > for many years. > > Now, with 7.5, it gives the following errors for EAP authentications > (everything else is OK): > > Apr 14 11:29:24 Eldarion radiusd[73262]: TLS Alert write:fatal:protocol > version > Apr 14 11:29:24 Eldarion radiusd[73262]: TLS_accept: error in SSLv3 > read client hello B > Apr 14 11:29:24 Eldarion radiusd[73262]: rlm_eap: SSL error > error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number > Apr 14 11:29:24 Eldarion radiusd[73262]: SSL: SSL_read failed in a > system call (-1), TLS session fails. > Apr 14 11:29:24 Eldarion radiusd[73262]: Login incorrect (TLS Alert > write:fatal:protocol version): [anonym...@myisp.com/ EAP>] (from client wdsl_neomedia nas 10.10.215.101 port 0 cli > FC-EC-DA-2A-F5-7F service wdsl-neomedia) > > I guess that the new LibreSSL version have some new restricted > requirements. And we CANNOT change the client's OpenSSL version or certs > (they are Ubiquiti devices). > > Some time ago (I think upgrading to 7.3) we had to add > "SSL_CTX_set_security_level( ctx, 0 );" to make it work. So we already > have set Security Level to 0. > > Is there something else we can do to make LibreSSL accept everything it > accepted in previous release? This is most likely because of: https://www.openbsd.org/74.html "Disabled TLSv1.0 and TLSv1.1 in libssl so that they may no longer be selected for use." I don't think there's anything simple you can do to reenable it.
Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) the FreeRadius EAP authentication no longer works! We are using a custom version of FreeRadius (because we had to do some little changes and a module of our own), and everything worked correctly for many years. Now, with 7.5, it gives the following errors for EAP authentications (everything else is OK): Apr 14 11:29:24 Eldarion radiusd[73262]: TLS Alert write:fatal:protocol version Apr 14 11:29:24 Eldarion radiusd[73262]: TLS_accept: error in SSLv3 read client hello B Apr 14 11:29:24 Eldarion radiusd[73262]: rlm_eap: SSL error error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number Apr 14 11:29:24 Eldarion radiusd[73262]: SSL: SSL_read failed in a system call (-1), TLS session fails. Apr 14 11:29:24 Eldarion radiusd[73262]: Login incorrect (TLS Alert write:fatal:protocol version): [anonym...@myisp.com/EAP>] (from client wdsl_neomedia nas 10.10.215.101 port 0 cli FC-EC-DA-2A-F5-7F service wdsl-neomedia) I guess that the new LibreSSL version have some new restricted requirements. And we CANNOT change the client's OpenSSL version or certs (they are Ubiquiti devices). Some time ago (I think upgrading to 7.3) we had to add "SSL_CTX_set_security_level( ctx, 0 );" to make it work. So we already have set Security Level to 0. Is there something else we can do to make LibreSSL accept everything it accepted in previous release? Thanks.
