[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)
#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-------------------------------------------------+-------------------------
Reporter: asn | Owner: (none)
Type: defect | Status:
| needs_review
Priority: Very High | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: wtf-pad, tor-relay, tor-cell, | Actual Points:
padding, 041-proposed, network-team- |
roadmap-2019-Q1Q2 |
Parent ID: | Points: 8
Reviewer: mikeperry | Sponsor:
| Sponsor2
-------------------------------------------------+-------------------------
Comment (by mikeperry):
Ok, so close! I fixed some things up and made a new pull request:
https://github.com/torproject/tor/pull/1029
Here's what I did:
* Rebased a few times due to conflicts
* Fixed the RTT log message (this message was due to our decision to
switch to counting padding negotiation as non-padding earlier in this
ticket)
* Improved comments in the machines about the packet traces
* After the RTT fix, I used chutney hs-v3 test to check packet patterns
with https://github.com/asn-d6/padanalyzer to make sure I didn't break
anything
* Demoted some logs and ensured correct log domains.
* Remove the log messages that https://github.com/asn-d6/padanalyzer needs
(they should be info/debug level rather than warn, but demoting them would
break padanalyzer anyway, so...)
I am convinced that this branch functionally does what we want now.
However, I think it would be useful to do the following:
* It bothers me that the client and middle-relay states are in the same
function for each machine. I would rather have each machine be in its own
function, even if they are mostly (or even exactly) the same machine (not
sure if this is heretical wrt code duplication, but I think code
readability should trump that)
* We *maybe* should find some way to write a unit or chutney test to
ensure that future changes to circuit setup don't change out packet
patterns (if these machines actually do survive a research cycle, then
they risk being broken by things like my RTT fix)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28634#comment:30>
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