[Libwebsockets] v2.0 crashes

Andy Green andy at warmcat.com
Thu May 12 16:08:25 CEST 2016



On 05/12/2016 06:50 PM, Andy Green wrote:
>
>
> On 05/12/2016 06:01 PM, Andrejs Hanins wrote:
>> Hi Andy,
>>
>> On 05/12/2016 12:05 PM, Andy Green wrote:
>>>
>>>
>>> On 05/12/2016 04:38 PM, Andrejs Hanins wrote:
>>>> Hi,
>>>>
>>>> Just updated to v2.0 and got crashes. The first one I figured
>>>> out myself - it was necessary to add
>>>> LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT option to ctx. Not sure
>>>> whether it supposed to crash without this option...
>>>
>>> People were complaining that lws always initialized SSL libs if
>>> linked to them... it blows up valgrind due to some mysterious,
>>> hopelessly inextricable incompatibility between at least OpenSSL
>>> and valgrind.  So this option was added (in the examples too) so
>>> that only if we explicitly want to use SSL does it get
>>> initialized.
>>>
>>> And it's item #2 in the changelog summary.
>> Yeah, my bad. I was confused by a crash. So there is no any way to
>> see if SSL was initialized outside of LWS and don't try to call any
>> SSL API if init wasn't done? Anyway, this is not very important,
>> because user error here leads to a guaranteed crash thus will be
>> fixed before code gets to the end-user :)
>
> Examples of how to do it are in the test server and client.
>
>>>> But the second one is more tricky - I get NULL context in
>>>> lws_ssl_server_name_cb from SSL_CTX_get_ex_data. Any ideas? FYI -
>>>> I create two lws contexts inside the process - one for server and
>>>> one for client. Before v2.0 everything worked rock solid.
>>>
>>> Yes: don't use two contexts.
>>>
>>> Use one context, you can mix client and server connections in the
>>> one context just fine.
>>>
>>> Indeed you can have multiple (serving) vhosts and multiple client
>>> connections just fine in one context.
>> Ok, please correct my understanding: if I have one server ctx with a
>> non-zero port, then default vhost is created but the ssl_client_ctx
>> for that vhost is not created, thus when trying to create a client
>> connection from this ctx leads to a crash (null ptr dereference). So
>> the proper solution is to crate a _client_ ctx first (with empty port
>> so that ssl_client_ctx is created), and then add a vhost using
>> lws_create_vhost with a port to listen?
>
> Basically the SSL init code still thinks it should init things to be
> either for server or client.
>
> int lws_context_init_client_ssl(struct lws_context_creation_info *info,
>                      struct lws_vhost *vhost)
> {
> ...
>
>      if (info->port != CONTEXT_PORT_NO_LISTEN)
>          return 0;
>
> However everything else already doesn't distinguish between the two
> uses, before v2.0 http proxying is already working (which binds an
> onward client connection to an accepted server client).  But that was
> only tested on http, not with SSL.

Yes this was the case.  But considering the need for backwards 
compatibility (both client and server context init use the same 
ssl-related members) it's not completely straightforward.

I pushed a patch on master that adds an api to init the client ssl 
context selectively on a vhost after the vhost is created.

https://github.com/warmcat/libwebsockets/commit/fb8be0507ecd4f669997a5dc04e49a02b2bd7a5c

See the docs added to the api comment

+ * lws_init_vhost_client_ssl() - also enable client SSL on an existing 
vhost
+ *
+ * @info: client ssl related info
+ * @vhost: which vhost to initialize client ssl operations on
+ *
+ * You only need to call this if you plan on using SSL client 
connections on
+ * the vhost.  For non-SSL client connections, it's not necessary to 
call this.
+ *
+ * The following members of @info are used during the call
+ *
+ *	 - @options must have LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT set,
+ *	     otherwise the call does nothing
+ *	 - @provided_client_ssl_ctx must be NULL to get a generated client
+ *	     ssl context, otherwise you can pass a prepared one in by setting it
+ *	 - @ssl_cipher_list may be NULL or set to the client valid cipher list
+ *	 - @ssl_ca_filepath may be NULL or client cert filepath
+ *	 - @ssl_cert_filepath may be NULL or client cert filepath
+ *	 - @ssl_private_key_filepath may be NULL or client cert private key
+ *
+ * You must create your vhost explicitly if you want to use this, so 
you have
+ * a pointer to the vhost.  Create the context first with the option flag
+ * LWS_SERVER_OPTION_EXPLICIT_VHOSTS and then call lws_create_vhost() with
+ * the same info struct.

There's also a corresponding flag added to lwsws to control this from JSON.

Testing it was quite tricky... I added a protocol plugin 
"client-loopback-test", if you jump through the hoops to set it up, you 
can trigger it to make a client connection from a browser, at which 
point the browser connection closes.

The client connection connects to the same server and the same protocol 
being served by the same plugin.  The server part sends some data to the 
client part and then they close.

It works here with wss client connection to itself but I am guessing 
it's quicker to try it on your own code.

-Ady

> At any rate, for sure the way forward is you should only use one context
> ( == one event loop) for all your activities.  If there are still
> problems with that, I will fix them.
>
> It seems the first step is adding a protocol plugin that opens a client
> connection back to his own server.
>
> -Andy
>
>>>
>>> -Andy
>>>
>>>> My compile options are:
>>>>
>>>> CMAKE_OPTIONS += -DLWS_WITHOUT_TESTAPPS=ON CMAKE_OPTIONS +=
>>>> -DCMAKE_BUILD_TYPE=DEBUG CMAKE_OPTIONS +=
>>>> -DLWS_WITHOUT_EXTENSIONS=ON CMAKE_OPTIONS += -DLWS_MAX_SMP=1
>>>> CMAKE_OPTIONS += -DLWS_OPENSSL_CLIENT_CERTS=/etc/ssl/certs
>>>> CMAKE_OPTIONS += -DLWS_OPENSSL_SUPPORT=ON CMAKE_OPTIONS +=
>>>> -DLWS_WITH_SSL=ON
>>>>
>>>> BR, Andrey
>>>>
>>>> On 05/05/2016 05:20 AM, Andy Green wrote:
>>>>> Hi -
>>>>>
>>>>> Libwebsockets v2.0 is out.
>>>>>
>>>>> The site is updated
>>>>>
>>>>> https://libwebsockets.org/
>>>>>
>>>>> as is the page about v2.0 new features
>>>>>
>>>>> https://libwebsockets.org/lws-2.0-new-features.html
>>>>>
>>>>> and the changelog
>>>>>
>>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog
>>>>>
>>>>>
>>>>>
>>>
>>>>>
> I replaced apache for my web services some weeks ago and have been using
> lwsws (the new generic webserver wrapper on lws) instead, you can see
> the new server status page here
>>>>>
>>>>> https://libwebsockets.org/server-status/
>>>>>
>>>>> This is an included lws protocol plugin, although you would
>>>>> probably want to put it on a vhost mapped to localhost
>>>>> interface only.
>>>>>
>>>>>
>>>>> Basically the theme of the release is eliminate server
>>>>> boilerplate code and use plugins for ws protocols.  With this
>>>>> method, the test server is reduced to one short file with no
>>>>> protocols or user callback.
>>>>>
>>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/test-server/test-server-v2.0.c
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>>>
> If you use lwsws, the generic webserver wrapper which uses JSON config
> files, you can even eliminate the above code as well.
>>>>>
>>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/README.lwsws.md
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>>>
> Protocol plugins can be be easily built against lws out-of-tree
>>>>>
>>>>> https://github.com/warmcat/libwebsockets/tree/v2.0-stable/plugin-standalone
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>>>
> and distributed in their own directories, lws scans in a given list of
> directories for them at startup (and for lwsws, that list is gleaned
> from JSON config fragments in a conf.d/)
>>>>>
>>>>> In addition to passing the usual Travis + Appveyor it's checked
>>>>> on Coverity today and is zero defects.
>>>>>
>>>>> https://scan.coverity.com/projects/warmcat-libwebsockets
>>>>>
>>>>> Branch v2.0-stable is also set up for the usual ongoing fixes
>>>>> while development continues on master.
>>>>>
>>>>> Enjoy!
>>>>>
>>>>> -Andy _______________________________________________
>>>>> Libwebsockets mailing list Libwebsockets at ml.libwebsockets.org
>>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>>
>>>> _______________________________________________ Libwebsockets
>>>> mailing list Libwebsockets at ml.libwebsockets.org
>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>>
>>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://libwebsockets.org/mailman/listinfo/libwebsockets



More information about the Libwebsockets mailing list