Reputation: 2469
I'm working on a client/server software and trying to figure out how to setup a TLS 1.3 PSK connection using openssl. Apparently, there are different callbacks as compared to TLS 1.2 (and lower) but openssl documentation is dreadful and I can't really understand the full flow.
Can someone provide sample code on how to return info in these callbacks?
int SSL_psk_use_session_cb_func(SSL *ssl, const EVP_MD *md,const unsigned char **id,size_t *idlen,SSL_SESSION **sess);
int (*SSL_psk_find_session_cb_func)(SSL *ssl,const unsigned char *identity,size_t identity_len,SSL_SESSION **sess);
Upvotes: 3
Views: 9963
Reputation: 13424
I hope you meant externally established PSK (out-of-band PSK key and ID) with TLSv1.3. For that you can directly use old callbacks psk_client_callback
and psk_server_callback
. With these callback, by default AES_128_GCM_WITH_SHA256
ciphersuite gets used.
TLSv1.3 PSK client, server example in this repo
Here the ClientHello
msg sends pre_shared_key
extension with the PSK_ID. And the ServerHello
responds with pre_shared_key
extension with chosen PSK_ID index as 0.
If you need to use different ciphersuites then you need to use psk_use_session_cb
and psk_find_session_cb
.
Upvotes: 3
Reputation: 9392
Can someone provide sample code on how to return info in these callbacks?
You can take a look at how s_client does it here:
And here is how s_server does it:
My understanding was that in TLS1.3 the Identity Hint is NULL, then why do these TLS1.3 specific callbacks have identity fields in them?
Identity Hint and Identity are two different things. In TLSv1.2 a server could provide a hint to the client to allow the client to select the correct identity for that server. In TLSv1.3 PSKs work completely differently. The client sends the identity to the server in the very first message so there is no opportunity for a hint to be received. In practice hints aren't usually that useful anyway.
In the context of PSK you can think of an identity as a bit like a username (that's actually a bit of an over-simplification - but enough for our purposes here)
Read somewhere that TLS 1.3 has a different set of ciphersuites, what are the names of ones for PSK AES256 and PSK CHACHA20
In TLSv1.2 you needed to use special PSK ciphersuites. In TLSv1.3 that is no longer the case. Ciphersuites work quite differently and there is no concept of having special PSK ciphersuites. You just use the normal ciphersuites. The main thing to be wary of is that in TLSv1.3 a PSK is always associated with a hash (e.g. SHA256). Whatever ciphersuite you use must be compatible with that hash, e.g. for SHA256 you might use TLS_CHACHA20_POLY1305_SHA256 or TLS_AES_128_GCM_SHA256.
In my case, the server will only accept one connection i.e. P2P datalink. Do I still have to make one side act as a server i.e. use find_session_cb instead of use_session_cb?
In TLS the client is defined as the peer that initiates the communication and the server is the peer that receives incoming connections. Therefore there is always a client and a server role. So, yes, one side must use find_session_cb
and the other side must use use_session_cb
.
Upvotes: 8