[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30172 [Core Tor/Tor]: Always send PADDING_NEGOTIATE if middle supports it
#30172: Always send PADDING_NEGOTIATE if middle supports it
-------------------------------------------------+-------------------------
Reporter: mikeperry | Owner: (none)
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: wtf-pad, tor-relay, tor-cell, | Actual Points:
padding, 041-proposed |
Parent ID: #28634 | Points:
Reviewer: | Sponsor:
| Sponsor2-can
-------------------------------------------------+-------------------------
Description changed by mikeperry:
Old description:
> We should define some kind of NULL machine for whatever hop is most
> common in our padding machine list, and negotiate that machine if no
> other machines apply to the current circuit. This machine shouldn't take
> up a slot or count as negotiated, tho, so we can still negotiate other
> machines if need be..
>
> Similarly, this NULL machine should (maybe) set should_negotiate_end and
> send a PADDING_NEGOTIATE at circuit close.
>
> We need to do this so that there isn't an obvious PADDING_NEGOTIATE cell
> request/response pair with obvious timings that it went to the middle
> node (since the PADDING_NEGOTIATED response will come faster than all
> other responses on the circuit). See also #30092 for similar motivating
> reasoning.
New description:
We should define some kind of NULL machine for whatever hop is most common
in our padding machine list, and negotiate that machine if no other
machines apply to the current circuit. This machine shouldn't take up a
slot or count as negotiated, tho, so we can still negotiate other machines
at later points if the circuit purpose changes, etc.
Similarly, this NULL machine should (maybe) set should_negotiate_end and
send a PADDING_NEGOTIATE at circuit close.
We need to do this so that there isn't an obvious PADDING_NEGOTIATE cell
request/response pair with obvious timings that it went to the middle node
(since the PADDING_NEGOTIATED response will come faster than all other
responses on the circuit). See also #30092 for similar motivating
reasoning.
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30172#comment:2>
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