use libwebsockets with OpenSSL was upgraded from 1.1.1u to 3.0.9 on the android-arm platform, and when connecting to WebSocket, an error occurred: SSL routines::legacy sigalg disallowed or unsupported

[chanhomer]

Hi, I have setup my project, using libwebsockets(v2.1.0) with OpenSSL was upgraded from 1.1.1u to 3.0.9 on the android-arm platform, and when the app connecting to WebSocket, an error occurred: “SSL routines::legacy sigalg disallowed or unsupported”

ERROR : SSL connect error 167772493: error:0A00014D:SSL routines::legacy sigalg disallowed or unsupported

while there was no problem with android-arm64 platform when use OpenSSL 3.0.9. At the same time, using OpenSSL 1.1.x version on android-arm platform also did not have any problems.

OpenSSL compilation command: ./Configure android-arm -D__ANDROID_API__=16 -static no-tests

[pvouzis]

I have a similar issue where I use ssl 1.1 under cygwin, but when I upgrade to ssl 3 it crashes.

[lws-team]

The OP is trying to use v2.1 which is many years old, much older than openssl v3. There's no reason to expect it to work.

There's no point looking at his or your problem unless you're using lws main or perhaps v4.3-stable.

If you find a problem with current lws, "crashes" is not worth anything for figuring out what it is, compared to, eg, a backtrace.

[pvouzis]

I am using 4.3. I can reproduce it reliably on my code, but I can't share any minimal example as of now. I can give some more information though.

• The application is build and runs under cygwin. Libwebsocket has been build under cygwin as well.
• My application can use either a libwebsocket to establish a connection with a server, or a custom tcp socket.
• When it uses the tcp socket there are not issues.
• When it uses the websocket it crashes.
• The application launches multiple threads (including one to handle the WS connection) and if any application thread exits it crashes).
• When any application thread exits (because it's done processing) it crashes. The thread that exits is not related to the websocket thread.
• I started noticing the problem when I upgrade from libssl1-dev to libssl3-dev on cygwin. I reverted back to libss1-dev and the issue doesn't happen any more
• I don't see the issue under Linux that I use ssl 3.0

I executed it under gdb but when it crashes there is not stack available (I compiled libwebsocket with debug information). I just see something like this

Thread 19 "nbagentgdb" received signal SIGSEGV, Segmentation fault. [Switching to Thread 15764.0x6358] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?)

If you have any pointers let me know. I am debugging as we speak so I will update you with any more findints.

Thanks for the prompt response.

[lws-team]

You cannot randomly throw threads on lws.

Have a read of this

https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.event-loops-intro.md

and make sure what you are trying to do is consistent with it.

[pvouzis]

I looked at that in the past, and we had to develop our application on a mulithreaded basis because it has to handle both the tcp and the websocket connection (for legacy reasons). Everything works fine with ssl 1.0. The issue was introduced in ssl 3.0.

[lws-team]

The event loop can handle multiple connections, with and without tls, without threads.

You can find out if it's related by disabling your thread temporarily and just run one connection from the event loop... if it's some tls integration problem like you prefer to imagine, it will still fail the same.

If it's because of multiple threads clashing with the event loop, it will work happily when those threads are disablef.

[pvouzis]

Our application is a client (not a server), so we just establish one websocket connection with the server. There is a thread that is launched off of the main execution thread and handles the websocket connection. The websocket connection handling runs on a single thread, so there are not multiple threads calling the websocket api.

Does that satisfy the requirement of a single thread handling the websocket?

This is the setup that I use and I observer the failing.

Let me know if you need any more information.

[lws-team]

The websocket connection handling runs on a single thread, so there are not multiple threads calling the websocket api.

In my experience mystery crashes where there are threads + lws are usually down to the threads.

If you back up and try to use lws + openssl3 + one of the out-of-the-box minimal examples that's similar to your situation, ie, eliminate your user code and threads from the equation but keep the same lws + openssl3, do you still have a problem?