[Libwebsockets] Android websocket client library

Andy Green andy at warmcat.com
Wed May 11 20:31:34 CEST 2016



On May 12, 2016 1:53:23 AM GMT+08:00, Thomas Spitz <thomas.spitz at hestia-france.com> wrote:
>Hello everyone,
>
>This is not really a question regarding libwebsockets but maybe someone
>as
>info...
>I am using library "project tyrus" for Android (v1.12) and for java
>desktop. The java desktop version works perfectly but android version
>has
>some problems. Here are the problem:
>- It doesn't work at all with Android version 5.0  because of SSL (it
>is
>apparently known by project tyrius developers and will be corrected) :
>Here
>the log of lws:
>
>> lwsts[1186]: accepted new conn  port 57692 on fd=21
>> lwsts[1186]: Accepted 0xaea3a8 to tsi 0
>> lwsts[1186]: lws_adopt_socket: new wsi 0xaea3a8
>> lwsts[1186]: insert_wsi_socket_into_fds: 0xaea3a8: tsi=0, sock=21,
>> pos-in-fds=2
>> lwsts[1186]: inserted SSL accept into fds, trying SSL_accept
>> lwsts[1186]: SSL_accept failed 2 /
>error:00000002:lib(0):func(0):system lib
>> lwsts[1186]: SSL_ERROR_WANT_READ
>> lwsts[1186]: SSL_accept failed 2 /
>error:00000002:lib(0):func(0):system lib
>> lwsts[1186]: SSL_ERROR_WANT_READ
>> lwsts[1186]: SSL_accept failed 5 / error:00000005:lib(0):func(0):DH
>lib
>> lwsts[1186]: SSL_accept failed skt 21:
>error:00000005:lib(0):func(0):DH lib

This is failing during SSL negotiation, at key exchange.

The 1.7 lws examples set the ciphers they'll accept to a very restricted list, basically the set necessary for Perfect Forward Secrecy needed to get A+ on the SSL Labs tests.  All weaker combinations are disabled.  This is set in the user code part in the examples (and lwsws)

		info.ssl_cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:"
				       "ECDHE-RSA-AES256-GCM-SHA384:"
				       "DHE-RSA-AES256-GCM-SHA384:"
				       "ECDHE-RSA-AES256-SHA384:"
				       "HIGH:!aNULL:!eNULL:!EXPORT:"
				       "!DES:!MD5:!PSK:!RC4:!HMAC_SHA1:"
				       "!SHA1:!DHE-RSA-AES128-GCM-SHA256:"
				       "!DHE-RSA-AES128-SHA256:"
				       "!AES128-GCM-SHA256:"
				       "!AES128-SHA256:"
				       "!DHE-RSA-AES256-SHA256:"
				       "!AES256-GCM-SHA384:"
				       "!AES256-SHA256";

Maybe it's related to the other side's ability to deal with that (or it selects some other combination we don't deal with correctly somehow).  If so, you could use a less restrictive list here if PFS isn't important to you.

>> lwsts[1186]: lws_close_free_wsi: shutting down connection: 0xaea3a8
>> lwsts[1186]: SSL_accept failed 5 / error:00000005:lib(0):func(0):DH
>lib
>> lwsts[1186]: SSL_accept failed skt 21:
>error:00000005:lib(0):func(0):DH lib
>> lwsts[1186]: lws_close_free_wsi: real just_kill_connection: 0xaea3a8
>> lwsts[1186]: remove_wsi_socket_from_fds: wsi=0xaea3a8, sock=21, fds
>pos=2,
>> end guy pos=3, endfd=0
>> lwsts[1186]: not calling back closed mode=6 state=0
>> lwsts[1186]: lws_header_table_detach: wsi 0xaea3a8: ah (nil) (tsi=0,
>count
>> = 0)
>> lwsts[1186]: lws_free_wsi: 0xaea3a8, remaining wsi 1
>
> - it works partially with Android versions 5.1 and 6.0 : When
>libwebsockets has to send small files (eg: 300kB files sent by trunks
>of
>2055bytes), it sometimes work and sometimes doesn't. Apparently this is
>due
>to libwebsockets high speed for sending trunks because it works much
>better
>if I trigger max lws log level (1023)

Not sure that makes sense, sending on ssl is synchronous and also flow controlled by the ability to send on the underlying socket.  There shouldn't be any way to 'send too fast'.  If the receiver is slower than the lws side can send, after filling the tx side buffers he won't get the WRITABLE callback to send more until the receiver has acked what was sent and made some space.

>What is working:
>- it works perfecly with Android version 4.x

It's a bit suspicious... I guess it negotiates a different cipher or key exchange method depending on Android version.

There are two kinds of problem here, dying at negotiation on 'dh key exchange', and stability.  It's not impossible there's some issue on lws side, but it doesn't seem to appear outside of android, and stability requires both sides to work stably.

>- it works perfecly with all Android versions if SSL is not activated

How about try bulk transfer tests on Android browser with same ssl setup?  That should let you differentiate between generic android os / ssl libs issue and android client lib issue.  Running the test server + test client on a pc with ssl, and look at the mirror test on Android browser (Chrome) works here (Android 5.0.2), that's with the PFS ciphers.

-Andy

>
>Other android libs seem much more complex. Does anyone have exeperience
>with other Android client libraries?
>
>For your info, I use version 1.7.7 of lws and openssl 1.0.2d

It seems today's flavour of openssl is up to 1.0.2h for security problems.

-Andy

>Thanks in advance
>Best regards,
>Thomas
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
>http://libwebsockets.org/mailman/listinfo/libwebsockets




More information about the Libwebsockets mailing list