search

ptrd / kwik

A QUIC client, client library and server implementation in Java. Supports HTTP3 with "Flupke" add-on.
GNU General Public License v3.0
390 stars 57 forks source link

Retention of unused encryption keys. #31

Closed QUICTester closed 1 year ago

QUICTester commented 1 year ago

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.

ptrd commented 1 year ago

Fixed (by https://github.com/ptrd/kwik/commit/040b0d1327bfb0a8e35c23c2bd612a4a39b721d4)

QUICTester commented 8 months ago

Additional details after this issue has been addressed.

Found in commit 745fd4e2d8d104b9cf1e8342d150ff8967c65892 Fixed in commit 040b0d1327bfb0a8e35c23c2bd612a4a39b721d4

Vulnerability details: Retention of unused Initial encryption keys in https://github.com/ptrd/kwik (commit 745fd4e2) implementation allows attackers to disrupt a connection (DoS) by sending a CONNECTION_CLOSE frame that is encrypted using the Initial key computed via network traffic sniffing. This is because the Initial key is not authenticated as explained in https://www.rfc-editor.org/rfc/rfc9001.html#name-discarding-initial-keys.

Exploitation steps: 1) Attackers must be able to sniff the network traffic. 2) Capture the first QUIC packets sent by a QUIC client. 3) Compute the Initial encryption key as described in https://www.rfc-editor.org/rfc/rfc9001.html#name-keys 4) Send a CONNECTION_CLOSE frame to the server in an initial packet encrypted using the computed initial encryption key. 5) Because the server does not discard the Initial keys, it will decrypt and process the Initial packet sent in (4) even after the QUIC handshake is completed.