search

openssl / project

Tracking of project related issues
2 stars 1 forks source link

QUIC: After the handshake is confirmed (see Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. #897

Open nhorman opened 1 month ago

nhorman commented 1 month ago

This is a missing MUST item from the spreadsheet here: https://docs.google.com/spreadsheets/d/1is0eRNrmNwzqcCTmTPYJwC3fswpYpqmY87-5CylraLc/edit?gid=1067533579#gid=1067533579

Need to determine if this is still missing, and if it is, correct it

Investigate and if work required create another issue with description what needs to be done

Sashan commented 1 week ago

we believe it is implemented. not sure if there is an existing test for this. The test we are looking for is the endpoint closes the connection right after SSL handshake completes. No data were sent over the connection.

nhorman commented 4 days ago

We have implicit checks for this, in that: 1) ch_on_handshake_complete asserts that tx_enc_level == QUIC_ENC_LEVEL_1RTT 2) ossl_quic_enc_level_to_pkt_type() ensures that the packet type is 1RTT if the enc level is 1RTT 3) our CI runs several test cycles with debug enabled, so we should get a crash if the quic tests ever encode a connection close request as something other than a 1RTT packet.

What we don't have is a negative test - i.e. confirming that sending a connection close in a non 1RTT packet generates an error. We could do that by writing a test to mangle the packet type, but the RFC doesn't define a behavior if that occurs, so I'm not sure what any such test should expect.