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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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.

New description:

 In order to eliminate a side channel attack described in
 https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf
 ("DropMark" attack) 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 dmr):

 Replying to [comment:5 mikeperry]:
 > Wrt DropMark, [...]

 Adding parenthetical to tie that term 'DropMark' to the paper (it might
 not otherwise be obvious by context).

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs