net: sockets: tls: Check whether peer was verified after handshake (with TLS_PEER_VERIFY_OPTIONAL)

[lucasdietrich]

For TLS connections, it would be interesting to know whether the peer was verified when the socket option TLS_PEER_VERIFY_OPTIONAL is enabled.

It seems to be quite feasible, getting the result of mbedtls_ssl_get_verify_result(tls->ssl) after handshake would do the trick. However I have no idea of an API to present this result to the application.

Suggestions are welcome.

MbedTLS documentation:
https://github.com/Mbed-TLS/mbedtls/blob/4cf77e99ab43105b863061c85796b8dbffd93ab1/include/mbedtls/ssl.h#L1925-L1928
https://github.com/Mbed-TLS/mbedtls/blob/4cf77e99ab43105b863061c85796b8dbffd93ab1/include/mbedtls/ssl.h#L4399-L4411

[lucasdietrich]

Apart from that, I also thought of allowing the application to register a custom TLS verification function, as is done in OpenSSL with the SSL_CTX_set_verify function (https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_verify.html).

This issue is quite different from my original post, but having more control over the TLS stack from the application could be a good thing, especially during the TLS handshake.

I haven't given it much thought, but I'm opening up the discussion, as I'm very interested.

[lucasdietrich]

I'm still not sure whether this feature deserves to be added to main tree.

However just to share my work, I drafted something that fulfil my needs for now: lucasdietrich@273ff70

To make it simple I decided to directly register application callback using mbedtls_ssl_conf_verify().
This methods allows to retrieve information about the certificates chain from the application.
Unfortunately this exposes the mbedtls internal structure mbedtls_x509_crt to the application.

Callback is configured like this from the application:

#include <zephyr/net/socket.h>
#include <zephyr/net/tls_verify_cb.h>

int configure_verify_cb(void)
{
        struct tls_verify_cb verify_cb;
        verify_cb.callback  = tls_verify_callback;
        verify_cb.user_data = NULL;
        return zsock_setsockopt(
	        sock, SOL_TLS, TLS_PEER_VERIFY_CB, &verify_cb, sizeof(verify_cb));
}

Application verify callback looks like this:

#include <mbedtls/x509_crt.h>
#include <mbedtls/oid.h>

static int tls_verify_callback(void *user_data,
			       struct mbedtls_x509_crt *crt,
			       int depth,
			       uint32_t *flags)
{
	if (depth != 0) return 0;

	bool accept = false;
        /* Filter connections by common name */
	for (name = &crt->subject; name != NULL; name = name->next) {
		if (MBEDTLS_OID_CMP(MBEDTLS_OID_AT_CN, &name->oid) == 0) {
			accept = validate_common_name(name->val.p, name->val.len);
		}
	}

	return accept ? 0 : -1; /* -1 error is forwarded to zsock_accept() */
}

[MY201314MY]

this callback is really necessary especially when we handle cert chain.

[rlubos]

I think we could add two new options, one to get the result of the last handshake on the socket, and second to install certificate verify callback:

• TLS_PEER_VERIFY_RESULT
• TLS_PEER_VERIFY_CALLBACK

However, as you say, exposing some mebd TLS details to the application in this case seems unavoidable to me, even for the first option, the verify results are so detailed, abstracting them seem impractical:
https://github.com/zephyrproject-rtos/mbedtls/blob/5f889934359deccf421554c7045a8381ef75298f/include/mbedtls/x509.h#L91

Perhaps we could at least make the option format transparent (I. e. register void * function pointer instead of dedicated mbed TLS one) so that in case we ever have some different TLS backend for the sockets, the options could still be reused. It'd be application responsibility to provide a valid callback type.

[rlubos]

I've opened the PR: #90068