TLS 1.3 PSK succeeds even if the pre-shared key is wrong

[Matt Caswell]

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 at openssl.org> 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
> 
>