On 2024-04-17, Federico Giannici <giann...@neomedia.it> wrote:
> On 4/17/24 16:34, Stuart Henderson wrote:
>> On 2024-04-17, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> 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.
