Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support DTLS1.3 downgrade when server supports CID #7841

Merged
merged 1 commit into from
Aug 9, 2024

Conversation

mrdeep1
Copy link
Contributor

@mrdeep1 mrdeep1 commented Aug 6, 2024

Description

With --enable-dtlscid, a client sending a Client Hello to a DLTS1.2 server that supports CID, the server provides the appropriate CID and assumes that CID has been negotiated.

However, in the case of MbedTLS, it then rejects packets that do not match its expected CID from the client - as wolfSSL no longer sends the CID as it is not DTLS1.2.

https://datatracker.ietf.org/doc/html/rfc9147#section-4

If a Connection ID is negotiated, then it MUST be contained in all datagrams.

This fix drops the CID if a Hello Verify Request is received, so the second Client Hello does not include the CID.

https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1

When responding to a HelloVerifyRequest, the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello.

Dropping the CID extension does not violate this.

Testing

Tested against a MbedTLS server with CID support, and enabled CID for the wolfSSL client.

Checklist

  • added tests
  • updated/added doxygen
  • updated appropriate READMEs
  • Updated manual and documentation

With --enable-dtlscid, a client sending a Client Hello to a DLTS1.2
server that supports CID, the server provides the appropriate CID and
assumes that CID has been negotiated.

However, in the case of MbedTLS, it then rejects packets that do not
match its expected CID from the client - as wolfSSL no longer sends
the CID as it is not DTLS1.2.

https://datatracker.ietf.org/doc/html/rfc9147#section-4

If a Connection ID is negotiated, then it MUST be contained in all datagrams.

This fix drops the CID if a Hello Verify Request is received, so the
second Client Hello does not include the CID.

https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1

When responding to a HelloVerifyRequest, the client MUST use the same
parameter values (version, random, session_id, cipher_suites,
compression_method) as it did in the original ClientHello.

Dropping the CID extension does not violate this.
@wolfSSL-Bot
Copy link

Can one of the admins verify this patch?

@dgarske
Copy link
Contributor

dgarske commented Aug 6, 2024

Thank you @mrdeep1 . We will review. Okay to test. Contributor agreement on file.

@dgarske dgarske assigned wolfSSL-Bot and douzzer and unassigned wolfSSL-Bot Aug 6, 2024
@dgarske dgarske requested a review from douzzer August 6, 2024 17:20
@douzzer douzzer merged commit 84b91d0 into wolfSSL:master Aug 9, 2024
122 checks passed
@mrdeep1 mrdeep1 deleted the dtls_downgrade_cid branch August 10, 2024 12:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants