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

Quic crypto reassembly 7556 v5 #12617

Closed

Conversation

catenacyber
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7556

Describe changes:

  • quic: handle fragment reassembly

SV_BRANCH=OISF/suricata-verify#2302

#12615 with better handling of counting the set bytes in order to be sure that the crypto fragments make a complete tls handshake and clippy fix

Will alow to have decode_frames accept one additional parameter
with past fragment data
cf rfc9000 section 19.3. ACK Frames

Ticket: 7556
Ticket: 7556

To do so, we need to add 2 buffers (one for each direction)
to the QuicState structure, so that on parsing the second packet
with hello/crypto fragment, we still have the data of the first
hello/crypto fragment.

Use a hardcoded limit so that these buffers cannot grow indefinitely
and set an event when reaching the limit
@catenacyber catenacyber requested a review from a team as a code owner February 18, 2025 21:01
@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 24778

@catenacyber
Copy link
Contributor Author

Next in #12622

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants