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

[Bug]: Retention of Unused Encryption Keys #345

Open
QUICTester opened this issue Oct 19, 2023 · 1 comment
Open

[Bug]: Retention of Unused Encryption Keys #345

QUICTester opened this issue Oct 19, 2023 · 1 comment
Assignees

Comments

@QUICTester
Copy link

QUICTester commented Oct 19, 2023

What happened?

I am a member of a group investigating automated testing of QUIC protocol implementations. During our tests involving a XQUIC implementation with the commit version 00f6228, we identified 1 fault:

The unused encryption keys, such as the Initial key, should be discarded once QUIC has moved to the Handshake encryption level (https://www.rfc-editor.org/rfc/rfc9001#name-discarding-unused-keys), same as the Handshake key after moving to the 1-RTT encryption level. An attacker can obtain the Initial key by capturing the Initial packets sent between the client and server during the connection establishment. If the server/client still accepts and processes Initial packets after they moved to the Handshake encryption level (after the server processes the first Handshake packet from the client), an attacker can disrupt the connection by sending a CONNECTION_CLOSE frame in an Initial packet to the server/client, causing a connection close that is not initiated by either the client or the server (DoS attack).

We believe this is a security vulnerability (according to the threat model in RFC9000) and we have sent our report to [email protected] and [email protected] 3 months ago (7 July 2023). However, we still haven't get any reply yet. We have also reported on 19 October 2023 and 2 February 2024. However, there is no progress in addressing this vulnerability.

Thank you for your time.

Steps To Reproduce

For Initial key:

  1. Send an Initial packet carrying a CRYPTO frame with Client Hello message
  2. When the server replies with Server Hello, Encrypted Extension, Certificate, Certificate Verify and Finished, send ACK to these messages.
  3. Send an Initial packet carrying a CONNECTION_CLOSE frame (this should close the connection, but according to RFC 9001, the Initial key needs to be discarded once the server receives a Handshake packet carrying an ACK frame in step 2).

This also applies to Handshake keys:

  1. Send an Initial packet carrying a CRYPTO frame with Client Hello message
  2. When the server replies with Server Hello, Encrypted Extension, Certificate, Certificate Verify and Finished, send ACK to these messages.
  3. Send a Handshake packet carrying a CRYPTO frame with Finshed message. The server will reply with HANDSHAKE_DONE frame.
  4. Send a Handshake packet carrying a CONNECTION_CLOSE frame (this should close the connection, but according to RFC 9001, the Handshake key needs to be discarded once the server sent the HANDSHAKE_DONE frame in step 3).

Relevant log output

No response

@QUICTester QUICTester changed the title [Bug]: [Bug]: Retention of Unused Encryption Keys Oct 19, 2023
@yangfurong yangfurong assigned yangfurong and Kulsk and unassigned yangfurong Oct 20, 2023
@QUICTester
Copy link
Author

QUICTester commented Feb 2, 2024

Hi @yangfurong @Kulsk ,

How is the progress on resolving this vulnerability?

We reported this bug via the MITRE CVE program today (although we know that Alibaba is a CNA partner). We believe this is a vulnerability that should be addressed (as described in RFC 9001 https://www.rfc-editor.org/rfc/rfc9001#name-discarding-unused-keys) and prioritized. If you need help in reproducing the vulnerability, please let us know. At a minimum, we would like an acknowledgment of our findings.

Thank you.

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

No branches or pull requests

3 participants