You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During our tests involving a Quant (511d91c) implementation, we identified a protocol violation on the Quiche server implementation.
Quant server process Handshake packet with an unmatched Destination Connection ID.
You can reproduce this behaviour by:
Sending a Initial packet carrying a Client Hello message.
Sending a Handshake packet carrying a Finished message with the original_destination_connection_id in the packet's Destination Connection ID field.
According to (Section 17.2.4, RFC 9000), the Destination Connection ID field in a Handshake packet contains a connection ID that is chosen by the recipient of the packet. However, the server does not conform to the specification and still process the Handshake packet that does not has the Destination Connection ID matched to the connection ID chosen by itself. Nobaly, the Source and Destination Connection ID fields are the primary means of protection against an off-path attack during the handshake (Section 21.2, RFC 9000).
In our experiment, this behaviour will only happen prior to the handshake completion. Once the connection is established. the server will not process 1-RTT packet from an unmatched Destination Connection ID.
Please let me know if you require any additional information.
The text was updated successfully, but these errors were encountered:
Thanks for the report. It's very likely that you identified a bug. Quant isn't under active maintenance anymore, since it was meant as a proof-of-concept to validate the evolving QUIC spec during its standardization. So it's unlikely I'll fix this.
Also, who are you? Your profile does not have any contact information.
We are doing research on testing QUIC and our work is currently under double-blind reviewing process. We will add our contact information once our work is published.
Hi,
During our tests involving a Quant (511d91c) implementation, we identified a protocol violation on the Quiche server implementation.
Quant server process Handshake packet with an unmatched Destination Connection ID.
You can reproduce this behaviour by:
According to (Section 17.2.4, RFC 9000), the Destination Connection ID field in a Handshake packet contains a connection ID that is chosen by the recipient of the packet. However, the server does not conform to the specification and still process the Handshake packet that does not has the Destination Connection ID matched to the connection ID chosen by itself. Nobaly, the Source and Destination Connection ID fields are the primary means of protection against an off-path attack during the handshake (Section 21.2, RFC 9000).
In our experiment, this behaviour will only happen prior to the handshake completion. Once the connection is established. the server will not process 1-RTT packet from an unmatched Destination Connection ID.
Please let me know if you require any additional information.
The text was updated successfully, but these errors were encountered: