Resend...this time including openssl-users, accidentally omitted from my last reply... On 20/04/2020 16:42, brandon.murphy1996 via openssl-users wrote: > Hi Matt > > Thanks for the reply. > > Yes! the handshake completes even when the PSK does not match between the ones provided in Client and Server. However, if there is a mismatch in the provided identity inside the callbacks, I see the above-mentioned error(the bad extension one). > > Unless I am missing something, if the code was not trying to perform a PSK verification, I would have received a complete handshake even if there was identity value mismatch between find_session_cb and use_session_cb. > > Moreover, I am using SSL_CTX_set_verify() with option SSL_VERIFY_PEER. Also, I am not providing the client Hello with any certificates. So I see no reason for handshake to complete without verification. > > Thanks > Bran Hmm. That's very strange behaviour. OpenSSL's s_server implementation of the find_session_cb is virtually identical to the one you posted (with a few minor differences). Presumably that's what you based the code on. We can test out the effect of mismatched PSKs using that callback as follows. First a matching PSK: $ openssl s_server -psk 012345 -nocert $ openssl s_client -psk 012345 With the above I get a successful connection. With a mismatched PSK, using TLSv1.3: $ openssl s_server -psk 012345 -nocert $ openssl s_client -psk 0123 With that on the server side I get a "binder does not verify" error: 139656179684608:error:141FA0FD:SSL routines:tls_psk_do_binder:binder does not verify:ssl/statem/extensions.c:1616: And on the client I get an illegal parameter alert: 140393338672384:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:ssl/record/rec_layer_s3.c:1543:SSL alert number 47 With a mismatched PSK, using TLSv1.2: $ openssl s_server -psk 012345 -nocert -no_tls1_3 $ openssl s_client -psk 0123 On the server I get decryption failed or bad record mac: 140522123650304:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:ssl/record/ssl3_record.c:676: And on the client I get a bad record mac alert: 140668428645632:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:ssl/record/rec_layer_s3.c:1543:SSL alert number 20 You might want to experiment with pointing the client you are using at s_server, and also with s_client pointing at your server, and try out those options to see if you can isolate the problem. Matt > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, April 20, 2020 5:35 PM, Matt Caswell <matt@xxxxxxxxxxx> wrote: > >> On 20/04/2020 12:59, brandon.murphy1996 via openssl-users wrote: >> >>> From what I noticed, the handshake completes successfully, regardless >>> of the value of "psk_key" (as long as PSK length is even). However, >>> if the identity value is mismatched between psk_find_session_cb and >>> use_session_cb, the handshake fails with the message: >> >> It's not clear from your question what you expected to happen. The >> length of the PSK key doesn't actually matter from a TLS perspective >> (obviously in practice it is best if the length is consistent with the >> ciphersuite key length). >> >> Or did you mean that that the value doesn't matter - even if it is >> mismatched with the client's value? That would be unexpected (and >> probably indicates you are not actually using the PSK at all and doing a >> full handshake). >> >> Matt > >
