Aioquic server process Handshake packet with an unmatched Destination Connection ID.
QUICTester opened this issue · comments
Hi,
During our tests involving Aioquic (239f99b) implementation, we identified a protocol violation in the server implementation.
Aioquic 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.
Thank you for your time.
Would it be possible to access the tools you used for testing in order to verify a potential fix please?
Hi, we are not able to publish our code at the moment. You can simply hardcode self._peer_cid.cid = self._original_destination_connection_id in connection.py when sending the Client Finished. Or maybe create a callback function to do this in _client_handle_finished() in tls.py?