[Libwebsockets] Creating a second (SSL capable) lws context will break SSL ext_data access

Andy Green andy at warmcat.com
Mon Jun 27 19:18:48 CEST 2016



On June 28, 2016 12:32:00 AM GMT+08:00, "Wenzel, Alexander" <alexander.wenzel at qsc.de> wrote:
>Hi Andy,
>
>thanks for the very quick response :)
>
>> How about you just rearrange things on your side to use one lws
>> context, as does every piece of example code we provide?  Then there
>> will be no problem.
>
>Your suggestion was my first approach, which also failed (SEGFAULT).
>That’s
>why I tried the alternative with the two context objects. But anyway,
>so it
>was easy to reproduce the recent behavior with the single context.
>
>We are using btw the minimal libwebsockets configuration without any
>additional
>libs like libuv or any plugins.
>
>So the current init flow looks like:
># populate lws_context_creation_info
># create context (lws_create_context)
>- LWS_SERVER_OPTION_EXPLICIT_VHOSTS and
>- LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT is set
># create vhost (lws_create_vhost)
># populate lws_client_connect_info
>- set also vhost here to determine related SSL_CTX as explained in lws
>header
># connect to server (lws_client_connect_via_info)

I missed your point for the "two contexts" thing... basically test client works fine for ssl, but he has the old context + default vhost creation.  So I guess as you found --->

>And that’s currently my gdb outcome.
>
>---- 8< ----
>#1  0x7795a1d0 in lws_ssl_client_bio_create (wsi=0xb33840) at
>libwebsockets-v2.0.2/lib/ssl-client.c:47
>47		SSL_set_mode(wsi->ssl,  SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER);
>(gdb) print wsi
>$1 = (struct lws *) 0xb33840
>(gdb) print wsi->ssl
>$2 = (SSL *) 0x0
>(gdb) print wsi->context->vhost_list->ssl_ctx
>$3 = (SSL_CTX *) 0xb30158
>(gdb) print wsi->context->vhost_list->ssl_client_ctx
>$4 = (SSL_CTX *) 0x0
>---- 8< ----
>
>When i follow the path of the functions, the SSL_CTX should be set in
>the
>lws_context_init_client_ssl fct (ssl-client.c:336), but as far as the
>port is
>set to 443 (server setup), the function returns here
>(ssl-client.c:317).
>Furthermore the "SSL_new“ function from ssl-client.c:45 returns 0 and
>the
>SEGFAULT occurs.
>
>Ahhh ;) While writing this mail and again digging deeper i found a
>commit
>in the master branch which probably will cover this issue. I will
>anyway send
>my mail as written, which maybe will help others with a similar
>problem.
>https://github.com/warmcat/libwebsockets/commit/fb8be0507ecd4f669997a5dc04e49a02b2bd7a5c

... to mix ssl client + server you must init the vhost client ssl context as well, since with the listen port set it'll otherwise only set up the server ssl context.

>So if i had used the master, i would probably stumbled upon this
>before.
>I’ll try this tomorrow in our build env. If this is the solution, can
>you estimate
>when this commit will be added to the stable branch? :D

It won't get backported because it adds a new api, so with v2.1 in the next few weeks.

-Andy

>Thanks in advance.
>
>Best regards,
>Alexander




More information about the Libwebsockets mailing list