Hello Christian,
To clarify, the third-party (the adversary) cannot observe that the QUIC
recipient dropped incoming packets. The adversary is observing the wire in
front of the client (e.g., the entry node). The Tor protocol, or application
protocols tunneled through Tor have deterministic periods of silence (e.g.,
when no incoming packets are expected), and if some packets are observed
during
an expected period of silence, the malicious entry node can conclude
that there
is a malicious exit relay at the other side feeding those packets. If
there is
no signal, the entry node can force a rotation of the circuit to
eventually get
another chance to collide with a malicious exit. The problem is that
protocol
robustness inside QUIC allows a malicious exit relay to send a signal that
won't break the HTTP/3 connection, nor the Tor circuit (from the Tor's PoV,
they look as legit data cells) independently from the presence of an
adversary
in front of the client. If a malicious guard does not observe a signal,
it is
then able to force a circuit rotation, again and again until a malicious
exit
is eventually selected and a signal is observed. If there is no
malicious guard
relay, the exit signal does not break the client, which helps avoiding
detection.
Maybe a drawing helps: there are the following cases, where E_a or G_a
would be
malicious nodes. Let's also assume that the Tor network can handle UDP
on exits
and tunnel QUIC packets. To clarify, the same guard relay is always used
by a
given client.
1) Only a malicious exit
Client-----G-----M-----E_a-----Destination
E_a knows about expected periods of silence either inside the Tor
protocol, or
inside the Application protocol, where the wire is expected to be
silent. E_a
can inject bogus QUIC packets into the network at those timings, and nothing
happens. Bogus QUIC packets could be replays, a QUIC header and payload
filled
with /dev/random, an incorrect packet type, and so on. Many types of bogus
QUIC packets would result in silently dropping in the client's QUIC stack,
without breaking the connection and the Tor circuit. However, with the
QUIC on
stream proposal, injecting a bogus packet should break the connection
(assuming the proposal is not tolerant to unexpected messages similarly to
TLS1.3).
2) Only a malicious guard
Client-----G_a-----M-----E-----Destination
G_a knows about an expected period of silence because the Tor protocol is
deterministic, or because it knows what App is running on the client,
and the
App's protocol is deterministic as well. Essentially, without being able to
decrypt the packets, G_a can count outgoing/incoming packet to guess
when the
expected period of silence starts. If no signal is observed, G_a may destroy
the circuit and force a new circuit.
3) malicious guard and exit
Client-----G_a-----M-----E_a-----Destination
In that scenario, the adversary can abuse QUIC's robustness to derive a
perfect
traffic confirmation technique, as discussed above.
My current guess is that we cannot have a QUIC connection over a whole
circuit,
or over a set of MASQUE proxies that resists such an adversary without
impractical changes
in the QUIC protocol. Some research would be needed to know what
combination of
layers and protocols (and extensions; e.g., datagrams) would be safe to
use. I *think* QUIC
on stream would be, as long as it behaves like the TLS1.3 record layer.
Florentin
Le 19/03/25 à 20:57, Christian Huitema a écrit :
On 3/19/2025 5:29 AM, Florentin Rochet wrote:
I am thinking, for example, to the behavior
common to all QUIC stacks to silently drop undecryptable packets
(e.g., because
keys are not available yet, or because AEAD decryption fails). This
behavior
may have strong negative effects to low-latency anonymous
communications such
as Tor that could carry HTTP/3 frames in between a Tor client and a
destination
server, and tunneled through Tor. It would be possible for malicious
exit
relays to build a perfect signalling mechanism (in terms of
FP=0/FN=0) that can
support a malicious entry node to silently drive a user's circuit to a
compromised exit node before any attempt of a connection to a
destination is
even made, and then link source to destination.
A method to build such a signal is to inject a few packets at the
exit relay
towards the client when the channel is expected to be silent. This is
generally
simple to achieve. In the case of an HTTP/3 connection, these packets
would
then be dropped by the client's QUIC stack, but such a signal would be
observable on the wire by the entry node.
Could you please elaborate, and describe the mechanisms by which the
third parties can observe that the QUIC recipient dropped incoming
packets? I would propose that we treat this issue as a bug in either
QUIC or the application on top of QUIC, and that we work to eliminate
that bug. But the first step would be to understand what the issue
actually is.
-- Christian
