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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
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


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, April 20, 2020 5:35 PM, Matt Caswell <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2
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 <[hidden email]> 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
>
>