[tor-bugs] #25573 [Core Tor/Tor]: Track half-closed stream IDs

[Tor Bug Tracker & Wiki]

#25573: Track half-closed stream IDs
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  guard-discovery-stats 035-roadmap-   |  Actual Points:
  proposed needs-proposal                        |
Parent ID:  #25574                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorV-can
-------------------------------------------------+-------------------------

Old description:

> In order to eliminate a side channel attack described in
> https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf we
> need a way to determine if a stream id is invalid.
>
> Many clients (particularly Firefox) will hang up on streams that still
> have data in flight. In this case, Tor clients send RELAY_COMMAND_END
> when they are done with a stream, and immediately remove that stream ID
> from their valid stream mapping. The remaining application data continues
> to arrive, but is silently dropped by the Tor client. The result is that
> this ignored stream data currently can't be distinguished from injected
> dummy traffic with completely random stream IDs, and this fact can be
> used to mount side channel attacks.
>
> A similar situation exists for spurious RELAY_ENDs.
>
> This isn't a full fix, because malicious relays can withhold the ack, but
> having it in place would simplify a lot of the code for dealing with
> unexpected packets.

New description:

 In order to eliminate a side channel attack described in
 https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf we
 need a way to determine if a stream id is invalid.

 Many clients (particularly Firefox) will hang up on streams that still
 have data in flight. In this case, Tor clients send RELAY_COMMAND_END when
 they are done with a stream, and immediately remove that stream ID from
 their valid stream mapping. The remaining application data continues to
 arrive, but is silently dropped by the Tor client. The result is that this
 ignored stream data currently can't be distinguished from injected dummy
 traffic with completely random stream IDs, and this fact can be used to
 mount side channel attacks.

 A similar situation exists for spurious RELAY_ENDs.

--

Comment (by mikeperry):

 Wrt DropMark, we can still count very early invalid cells as dropped in
 the vanguards addon (and eventually in tor-core), and react to those. This
 behavior won't prevent that, since there will be no streams at that point.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25573#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online