Get the SKID of client certificate when establishing the connection on http server side

[gennadiyvt]

Dear libwebsockets team,

We are trying to use libwebsockets http server built with the mbedtls on a small embedded platform. One of our requirements is to have a list of trusted SKI on http server side and make sure that client connected matches one of that list items. The issue is that when in lws_context_creation_info->options the LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT is present, mbedtls handshake fails (looks like it requires a valid CA in this case), but if LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT is off — then we cannot fetch any peer certificate related info. With OpenSSL it is possible to check the SKID without CA, that is what we really appreciate if possible somehow with mbedtls-based libwebsockets.

Should we try some more specific libwebsockets or mbedtls options to get the SKID check working without providing a CA or is that just not possible?

Thank you in advance

[lws-team]

Yes you need LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT in order to trigger the client to send his certificate.

The server is going to validate the client cert against the CA, that's why it wants it.

I would try hacking your way around it and see if it will go on to send you to certs, if so, you might be able to intercept it before validation.

I did not write mbedtls, it has been a struggle to work with compared to openssl, you may find the quickest way to a solution or at least a result where you know what's possible it to debug your way through it.

[gennadiyvt]

So far I did a very rough hack with the only benefit — it somehow works, the SKID is printed as expected in http server callback (see below). Options I set:

      .options = LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT 
                 | LWS_SERVER_OPTION_SSL_ECDH
                 | LWS_SERVER_OPTION_H2_JUST_FIX_WINDOW_UPDATE_OVERFLOW
                 | LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT,

In the http server callback:

    case LWS_CALLBACK_ESTABLISHED: {
      union lws_tls_cert_info_results results = {0};
      int err = lws_tls_peer_cert_info(wsi, LWS_TLS_CERT_INFO_SUBJECT_KEY_ID, &results, 64);
      // Print SKID as hex
      if (!err && results.ns.len > 0) {
        printf("SKID: ");
        for (size_t i = 0; i < results.ns.len; ++i) {
          printf("%02X", results.ns.name[i]);
        }
        printf("\n");
        ret = CheckSkid(results.ns.name, results.ns.len);
      }

In mbedtls I did the main hack — forced the mbedtls_ssl_verify_certificate() return earlier with the success result (before calling the failing checks).

Probably if we can load the certificate but skip the extra checks within mbedtls_ssl_verify_certificate() is the question to mbtls team (e.g. if we can have there option like MBEDTLS_CERT_LOAD_ONLY meaning that check can be done on client side afterwards or something like that).

But what about the libwebsockets side, is that more or less usual way to get the SKID or could you propose some better one? Please let me know if I am moving too wrong way.

Thanks once again

[lws-team]

The lws bit just looks normal, not a hack, except I doubt LWS_SERVER_OPTION_SSL_ECDH is doing anything useful.

Take care about the mbedtls side, you can turn off cert validation https://sourcevu.sysprogs.com/espressif/lib/mbedtls/symbols/mbedtls_ssl_conf_authmode but actually you want it to care about all the niceties like valid-to except that the chain is treated as always trusted.

[gennadiyvt]

I've briefly checked the article and seems I have to set the MBEDTLS_SSL_VERIFY_OPTIONAL mode. Then I scanned the source code for MBEDTLS_SSL_VERIFY_OPTIONAL and it is set in the ssl_pm.c, ssl_pm_reload_crt() like this:

static int ssl_pm_reload_crt(SSL *ssl)
{
    struct x509_pm *ca_pm = (struct x509_pm *)ssl->client_CA->x509_pm;
    struct ssl_pm *ssl_pm = ssl->ssl_pm;
    int ret = 0;
    int mode;

    struct pkey_pm *pkey_pm = (struct pkey_pm *)ssl->cert->pkey->pkey_pm;
    struct x509_pm *crt_pm = (struct x509_pm *)ssl->cert->x509->x509_pm;

    if ((ssl->verify_mode & SSL_VERIFY_PEER) > 0)
        mode = MBEDTLS_SSL_VERIFY_REQUIRED;
    else if ((ssl->verify_mode & SSL_VERIFY_FAIL_IF_NO_PEER_CERT) > 0)
        mode = MBEDTLS_SSL_VERIFY_OPTIONAL;
    else if (ssl->verify_mode == SSL_VERIFY_CLIENT_ONCE)
        mode = MBEDTLS_SSL_VERIFY_UNSET;
    else
        mode = MBEDTLS_SSL_VERIFY_NONE;

    //...
}

For the first test I've just hardcoded the mode = MBEDTLS_SSL_VERIFY_OPTIONAL and that seems to work. But it seems to be no way to have the SSL_VERIFY_PEER reset but SSL_VERIFY_FAIL_IF_NO_PEER_CERT set as:

int
lws_tls_server_client_cert_verify_config(struct lws_vhost *vh)
{
	int verify_options = SSL_VERIFY_PEER;

	/* as a server, are we requiring clients to identify themselves? */
	if (!lws_check_opt(vh->options,
			  LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT)) {
		lwsl_notice("no client cert required\n");
		return 0;
	}

	if (!lws_check_opt(vh->options, LWS_SERVER_OPTION_PEER_CERT_NOT_REQUIRED))
		verify_options |= SSL_VERIFY_FAIL_IF_NO_PEER_CERT;

	lwsl_notice("%s: vh %s requires client cert %d\n", __func__, vh->name,
		    verify_options);

	SSL_CTX_set_verify(vh->tls.ssl_ctx, verify_options, NULL);

	return 0;
}

verify_options is initialised with SSL_VERIFY_PEER and then SSL_VERIFY_FAIL_IF_NO_PEER_CERT is just added but no possibility to clear the SSL_VERIFY_PEER. Assume it is correct but that obviously blocks MBEDTLS_SSL_VERIFY_OPTIONAL be set in ssl_pm_reload_crt()

Considering this, I would expect something like following in ssl_pm_reload_crt():

static int ssl_pm_reload_crt(SSL *ssl)
{
    struct x509_pm *ca_pm = (struct x509_pm *)ssl->client_CA->x509_pm;
    struct ssl_pm *ssl_pm = ssl->ssl_pm;
    int ret = 0;
    int mode;

    struct pkey_pm *pkey_pm = (struct pkey_pm *)ssl->cert->pkey->pkey_pm;
    struct x509_pm *crt_pm = (struct x509_pm *)ssl->cert->x509->x509_pm;

    if ((ssl->verify_mode & SSL_VERIFY_PEER) > 0) // SSL_VERIFY_PEER set
    {
        if ((ssl->verify_mode & SSL_VERIFY_FAIL_IF_NO_PEER_CERT) > 0)
           mode = MBEDTLS_SSL_VERIFY_REQUIRED;
        else
           mode = MBEDTLS_SSL_VERIFY_OPTIONAL;
    }
    else // SSL_VERIFY_PEER reset
    {
        if (ssl->verify_mode == SSL_VERIFY_CLIENT_ONCE)
            mode = MBEDTLS_SSL_VERIFY_UNSET;
        else
            mode = MBEDTLS_SSL_VERIFY_NONE;
    }

    //...
}

Please let me know if I understood the logic correctly and some fix is to be applied.

Thank you once again for review and hints

[gennadiyvt]

Dear @lws-team,

Could you please review the assumption in the message above?

Thank you in advance

[lws-team]

My concern is we change something for existing users. It may instead be better to add a new option bitfield with gates any new behaviours related to checking the peer cert.

[gennadiyvt]

I see, thank you. I would be happy with any alternative that provides a possibility to set the MBEDTLS_SSL_VERIFY_OPTIONAL, the main issue is that I was not able to set it with the existing mode selection.

Thanks once again

[lws-team]

Can I suggest you provide a patch on main that won't affect anyone who doesn't want the server_option flag, and works for you then?

[gennadiyvt]

Ok, I'll prepare the patch this week and share it with you.

Thanks for review and ideas

[gennadiyvt]

Just a little bit different question, assuming that the patch is in libwebsockets main original repo, how is it possible to patch espressif afterwards, is there any official procedure to sync that?

Thanks in advance

[lws-team]

Espressif manage that... but it's following our repos as its upstream.

Your patch can't go on our v4.4-stable because it changes the abi (the extra server option won't exist on v4.4 before your patch). If we did that, we can't say, "use v4.4" because then there would be two kinds of v4.4, with or without this symbol. So it should go on main, and later v4.5 will be made from main, espressif can upgrade to v4.5 in their tree.

Once it's in main here, espressif can also cherry-pick it on their tree earlier if they want, since it does nothing by default and by being in main is queued for v4.5 it's a reasonably safe bet.

[gennadiyvt]

I've also tried the client side and now got it working with a lot of hardcodes. Looks like ssl_pm_reload_crt() is used by both server and client and client side requires even more analysis now. So most likely the PR to main will be postponed due to this reason, I am doing more testing with client and will return with findings description in couple of days.

[gennadiyvt]

@lws-team a brief question about client. I use options and certificates set as following:

  const struct lws_context_creation_info ctx_creation_info = 
  {
      .port                    = CONTEXT_PORT_NO_LISTEN,
      .protocols               = protocols,
      .gid                     = (gid_t)-1,
      .uid                     = (uid_t)-1,
      .fd_limit_per_thread     = 6,
      .options                 = LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT | LWS_SERVER_OPTION_H2_JUST_FIX_WINDOW_UPDATE_OVERFLOW,
      .client_ssl_cert_mem     = cert_mem,
      .client_ssl_cert_mem_len = cert_mem_size,
      .client_ssl_key_mem      = key_mem,
      .client_ssl_key_mem_len  = key_mem_size,
}

And printed the mode set within the ssl_pm_reload_crt () — it is MBEDTLS_SSL_VERIFY_NONE (meaning no flags in ssl->verify_mode set as well). But I need the same MBEDTLS_SSL_VERIFY_OPTIONAL to make client send its certificate to server.

Is there any existing option to configure the lws_context_creation_info so ssl->verify_mode become non-zero for client or should I try to look for patch at some different place? Maybe that is the issue with the epressif/libwebsockets only but hope you can provide me a hints what to be checked there.

Thanks in advance

[lws-team]

The server needs to have the options bit LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT to kick off the client sending peer certs.

[gennadiyvt]

Sorry probably I made some gaps in the explanation, we have both server and client in our framework and the last question was about the client side, meaning wsi created like:

wsi = lws_client_connect_via_info(lws_connect_info);

I would create a separate issue for this but seems like that is all around the ssl_pm_reload_crt() so decided to ask right here, also guess I'll create a single patch PR afterwards (both client sending & server storing certs).

It appeared that client sends the certificate only if I hardcode mode = MBEDTLS_SSL_VERIFY_OPTIONAL within `ssl_pm_reload_crt() in my local copy