Summary
As of quinn-proto 0.11, it is possible for a server to accept()
, retry()
, refuse()
, or ignore()
an Incoming
connection. However, calling retry()
on an unvalidated connection exposes the server to a likely panic in the following situations:
- Calling
refuse
or ignore
on the resulting validated connection, if a duplicate initial packet is received
- This issue can go undetected until a server's
refuse()
/ignore()
code path is exercised, such as to stop a denial of service attack.
- Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
- This issue can go undetected if clients are well-behaved.
The former situation was observed in a real application, while the latter is only theoretical.
Details
Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213
Impact
Denial of service for internet-facing server
References
Summary
As of quinn-proto 0.11, it is possible for a server to
accept()
,retry()
,refuse()
, orignore()
anIncoming
connection. However, callingretry()
on an unvalidated connection exposes the server to a likely panic in the following situations:refuse
orignore
on the resulting validated connection, if a duplicate initial packet is receivedrefuse()
/ignore()
code path is exercised, such as to stop a denial of service attack.The former situation was observed in a real application, while the latter is only theoretical.
Details
Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213
Impact
Denial of service for internet-facing server
References