Closed FrantisekKrenzelok closed 1 year ago
@Franko5040 is it possible this issue is solved with PR https://github.com/wolfSSL/wolfssl/pull/5716 ? @rizlik can you review this bug report?
Hi @Franko5040 Thanks for the report. When the HelloRetryRequest is used to perform a return-routability check (as in this case) the KeyShare is not mandatory. Moreover, if the client already provided a good KeyShare the server MUST NOT send a KeyShare extension asking for the same key share in the HelloRetryRequest. Otherwise the (2) in : In https://www.rfc-editor.org/rfc/rfc8446#section-4.2.8:
Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that (1) the selected_group field corresponds to a group
which was provided in the "supported_groups" extension in the
original ClientHello and (2) the selected_group field does not
correspond to a group which was provided in the "key_share" extension
in the original ClientHello.
will be violated. Of course, if the client doesn't provide a good key share in the first ClientHello, the KeyShare extension needs to be present in the HelloRetryRequest (together with the cookie).
Does it make sense to you? Marco
I see, Thanks for the explanation and you time!
Contact Details
fkrenzel@redhat.com
Version
v5.5.3-stable
Description
The client sends key_share extension but the server doesn't reply with it. As you can see in the log bellow, the server receives the extension from the first client hello, yet it is not send back possibly not even handled. It is only later during Server Hello that the extension is replied back to client.
-
denotes the missing extentionreference:
Reproduction steps
./configure --enable-dtls --enable-dtls13 --enable-tls13 make ./examples/client/client -u -v 4 127.0.0.1 ./examples/server/server -u -v 4
Relevant log output