search

quicwg / reliable-stream-reset

Other
7 stars 5 forks source link

Possible attack #72

Open martinduke opened 4 days ago

martinduke commented 4 days ago

I've heard some talk about a possible API where one sets a reliable_size, and then Reset() calls result in a RESET_STREAM_AT instead.

If that's all there is, there's a potential security problem, because the ability to send a later RESET_STREAM (reliable_size = 0) is important.

Say a proxy is connecting on behalf of multiple clients, each with one stream. The server sets RESET_STREAM_AT for one stream with some undelivered data. The client for that stream, an attacker, never acknowledges data, causing the proxy to not allow the delivery of reliable_size. The correct thing for the server to do is eventually reduce reliable_size to zero -- the only other alternative is to kill the connection, which would affect all the other clients.

This is not really a gap in the spec, but it's an important implementation detail that probably ought to go in security considerations.

marten-seemann commented 4 days ago

I'm not sure I understand the scenario. Why is the upstream connection affected by a client not acknowledging data on the downstream connection?

RESET_STREAM_AT only covers data that has already been transmitted to the client (at least) once, and if the client refused to acknowledge these frames, they will stay within the QUIC stack's retransmission buffer. Why would they have any effect on the proxy's connection to the upstream server?

martinduke commented 4 days ago

S -> P -> C1 -> C2

Let's say S sends a RESET_STREAM_AT that corresponds to C1, but C1 (an attacker) refuses to acknowledge reliable_size. The server eventually wants to clean up this state.

if it doesn't have an API that allows setting reliable_size back to zero, the only way it clear the state is by killing the connection. This would also kill the stream to C2.

A less weird example would be tearing down a WebTransport Session -- the session state embedded in reliable size no longer matters.

LPardue commented 4 days ago

I think this falls into a general bracket of resource consumption and timeouts. For instance, is the described case that different from a proxy that sends STREAM + FIN and a client refuses to acknowledge it?

If reset at is just a riff of a th9ng we already have to handle, I'd rather defer to that. If we overlooked adding it before, or we decided not to bother, that's what I care about.