Support TLS pre-shared keys

[markasoftware]

This can be useful when wanting to encrypt a connection without setting up a CA. I think it should be as simple as adding --enable-psk to the configure options and then adding wrappers for the related functions https://www.wolfssl.com/using-pre-shared-keys-psk-with-wolfssl-2/

[xv-thomas-leong]

Thanks for the suggestion. We’d welcome a PR if you’d like to draft one 😄

[markasoftware]

WolfSSL (following OpenSSL's lead) does not have some simple wolfSSL_CTX_set_psx(SSL *, char *), instead you're expected to provide a callback function that writes the psk into a mutable buffer. Rationale is that (especially the server) may not always want to use the same key for a given WOLFSSL* (the client can provide an "identity hint", like a username, that the server uses to choose a different PSK).

Do you or other maintainers have any opinion about the cleanest way to integrate this into the high-level wolfssl-rs api? I see two options:

1. The Rust OpenSSL bindings let the user specify a callback https://docs.rs/openssl/latest/openssl/ssl/struct.SslContextBuilder.html#method.set_psk_client_callback , basically acting as a very thin wrapper around the underlying SSL_CTX_set_psk_{client,server}_callback functions. We could do the same and add a with_psk_callback or similar method to ContextBuilder
2. Of course, the most common case is that both client and server are using a constant PSK that is the same for the lifetime of the WOLFSSL*. In this case, we have another option: Use wolfSSL_CTX_set_ex_data to store the a pointer to the PSK buffer in the WOLFSSL object , then have a global predefined callback function that uses wolfSSL_CTX_get_ex_data to get the PSK back out of the WOLFSSL context object. Then we can expose a simpler high-level API with_psk on the ContextBuilder, which sets the ex data and then sets our predefined callback.

If you're ok with option 2 I'd like to implement it! (possibly in addition to the first option, which could be implemented as with_psk_callback for example)

[xv-thomas-leong]

Thank you for exploring the options. I believe option 1 is more preferable, as it aligns with the goals of wolfssl-rs - which is to offer idiomatic abstractions for the WolfSSL C library. By exposing the C library's interfaces, we enable developers to utilize its capabilities directly.

Would this arrangement work in your use case?

[markasoftware]

Yeah, I can refactor my PR to be more generic and closer to the C interface while still having an option to use the simpler fixed PSK

[markasoftware]

I've updated my PR to allow arbitrary callbacks including setting the PSK identity