#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs