Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:02:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7028Implement Adaptive Padding or some variant and measure overhead vs accuracy2022-03-22T13:02:42ZMike PerryImplement Adaptive Padding or some variant and measure overhead vs accuracyAs a defense against Website Traffic Fingerprinting, we should implement a tunable cover traffic defense that we could set from the consensus with a value dependent upon available Guard bandwidth relative to Exit capacity.
My favorite f...As a defense against Website Traffic Fingerprinting, we should implement a tunable cover traffic defense that we could set from the consensus with a value dependent upon available Guard bandwidth relative to Exit capacity.
My favorite from the research literature is http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf, because it appears to be tunable in this fashion.
The "BUFLO" variant proposed by this paper is better specified, but it's not clear it actually performs better for a given overhead quantity: http://www.cs.sunysb.edu/~xcai/fp.pdf
This is likely a research task. People who attempt it should also read http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf (Slides: http://www.cse.psu.edu/~tjaeger/cse543-f06/presents/Kiran_baserate.pdf)Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28693Add an option to disable circuit padding2021-02-05T13:00:06ZteorAdd an option to disable circuit paddingWe need an option like ConnectionPadding to disable circuit padding.
Do we also need ReducedCircuitPadding for mobile?We need an option like ConnectionPadding to disable circuit padding.
Do we also need ReducedCircuitPadding for mobile?Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32040HS intro padding machine reactivates after receiving INTRODUCE_ACK2020-06-16T11:27:52ZGeorge KadianakisHS intro padding machine reactivates after receiving INTRODUCE_ACKWhile reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down...While reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down. Then when INTRODUCE_ACK arrives, it reactivates (probably because INTRODUCE_ACK is part of the accepted purposes and the machine is shutdown/freed at that time) and sends again padding, then again shuts down...
This does not work as intended and causes extra cells to fly in with a pattern that probably does not help them blend in.
Here are some Tor logs (with padanalysis incoming/outgoing cells logs):
```
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:57.000 [warn] outgoing-cell: EXTEND 0
Oct 11 13:25:58.000 [warn] incoming-cell: EXTENDED 0 148
Oct 11 13:25:58.000 [warn] outgoing-cell: INTRODUCE1 4
Oct 11 13:25:58.000 [warn] outgoing-cell: PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (7)
Oct 11 13:25:58.000 [warn] incoming-cell: INTRODUCE_ACK 4 0
Oct 11 13:25:58.000 [info] rend_client_introduction_acked(): Received ack. Telling rend circ...
Oct 11 13:25:58.000 [info] circpad_setup_machine_on_circ(): Registering machine client_ip_circ to origin circ 5 (8)
Oct 11 13:25:58.000 [info] circpad_node_supports_padding(): Checking padding: supported
Oct 11 13:25:58.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 5 (8), command 2
Oct 11 13:25:58.000 [warn] outgoing-cell: 8 PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [info] circpad_machine_spec_transition(): Circuit 5 circpad machine 0 transitioning from 0 to 1
Oct 11 13:25:58.000 [info] circpad_marked_circuit_for_padding(): Circuit 5 is not marked for close because of a pending padding machine in index 0.
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (15)
...
Oct 11 13:36:11.000 [info] circuit_mark_for_close_(): Circuit 4130340667 (id: 5) marked for close at src/core/or/circuituse.c:1509 (orig reason: 9, new reason: 0)
```
I'm not sure what the fix should be here. It might be that we need to remove INTRODUCE_ACK from the list of accepted purposes, but if we do that then if INTRODUCE_ACK arrives earlier we will stop padding after. Hmm.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/28694When CircuitPadding is implemented in Tor, set it to 0 in sbws2020-06-13T16:14:58ZteorWhen CircuitPadding is implemented in Tor, set it to 0 in sbwsIn #28693, we will implement a tor option for circuit padding.
When that option is implemented, we should set it to 0 in sbws.In #28693, we will implement a tor option for circuit padding.
When that option is implemented, we should set it to 0 in sbws.sbws: 1.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29102Serialize padding state machine in consensus2020-06-13T16:03:58ZMike PerrySerialize padding state machine in consensusWe should have the ability to list padding machines in the consensus.
This might not make 041.We should have the ability to list padding machines in the consensus.
This might not make 041.https://gitlab.torproject.org/legacy/trac/-/issues/22212[warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padd...2020-06-13T15:49:38ZRoger Dingledine[warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?Normal Tor client, running `Tor 0.3.1.0-alpha-dev 2e4f3b36bdfd5118`, got this log line:
```
May 10 02:50:11.217 [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did ...Normal Tor client, running `Tor 0.3.1.0-alpha-dev 2e4f3b36bdfd5118`, got this log line:
```
May 10 02:50:11.217 [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump? (on Tor 0.3.1.0-alpha-dev 2e4f3b36bdfd5118)
```
My tor client had been idle for hours before this point, and the log message coincides with a new request that I made. I'm pretty sure there was no clock jump.
Alas, I have no more detailed logs. I'll try to reproduce with logs.Tor: 0.3.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/31461Fix some typos in the 0.4.1 ReleaseNotes and ChangeLog2020-06-13T15:44:21ZteorFix some typos in the 0.4.1 ReleaseNotes and ChangeLogTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31393Stop declaring support for Padding=1 after 0.4.1-stable is released2020-06-13T15:44:15ZteorStop declaring support for Padding=1 after 0.4.1-stable is releasedOnce 0.4.1-stable is released (and on deb.tpo as the stable version), there will be a lot of relays with Padding=2. So we can stop declaring support for Padding=1.Once 0.4.1-stable is released (and on deb.tpo as the stable version), there will be a lot of relays with Padding=2. So we can stop declaring support for Padding=1.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31392Explain Padding 1 and 2 in tor-spec.txt2020-06-13T15:44:14ZteorExplain Padding 1 and 2 in tor-spec.txtPadding=1 is declared by some versions of tor without Padding support. We will stop declaring support for it I once #31356 is merged into 0.4.1.
Padding=2 is the guaranteed working version once #31356 is merged into 0.4.1 and later.Padding=1 is declared by some versions of tor without Padding support. We will stop declaring support for it I once #31356 is merged into 0.4.1.
Padding=2 is the guaranteed working version once #31356 is merged into 0.4.1 and later.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31387Make 0.4.1 and later clients require Padding=22020-06-13T15:44:13ZteorMake 0.4.1 and later clients require Padding=2As part of #31356, we need to make 0.4.1 and later clients require Padding=2.As part of #31356, we need to make 0.4.1 and later clients require Padding=2.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/313560.4.1 relays should list Padding=22020-06-13T15:44:06ZMike Perry0.4.1 relays should list Padding=2Somehow we accidentally merged the protover for padding support while doing the incremental merge thing, and 0.4.0 relays are advertising padding that they don't support. This is mostly harmless, because the negotiation will not succeed ...Somehow we accidentally merged the protover for padding support while doing the incremental merge thing, and 0.4.0 relays are advertising padding that they don't support. This is mostly harmless, because the negotiation will not succeed and then clients will stop, but it will result in those clients emitting a "Middle node did not accept our padding request" protocol warn/info message.
~~We should just remove this protover field from 0.4.0.x.~~
At the weekly meeting last week, we decided that we can't remove a protover once it's been released.
Instead, we will:
* make 0.4.1 and later relays declare Padding=2 (pre-0.4.1 stable)
* make 0.4.1 and later clients require Padding=2 (padding is not on by default, so we can do this at any time)
Edited to simplify: we don't need to preserve compatibility with alphas.Tor: 0.4.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/28634Design a first useful padding machine (hiding client-side intro/rend circuits)2020-06-13T15:42:12ZGeorge KadianakisDesign a first useful padding machine (hiding client-side intro/rend circuits)#28142 will get merged with no active padding machine. This ticket is about designing a useful padding machine that can act as a decent testbed for the WTF-PAD project.#28142 will get merged with no active padding machine. This ticket is about designing a useful padding machine that can act as a decent testbed for the WTF-PAD project.Tor: 0.4.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/28780circpadding: Add machine flag for not closing circuit if machine is active2020-06-13T15:42:10ZGeorge Kadianakiscircpadding: Add machine flag for not closing circuit if machine is activeSee https://github.com/torproject/tor/pull/461#discussion_r231546320 for more details .
Related to #28634.See https://github.com/torproject/tor/pull/461#discussion_r231546320 for more details .
Related to #28634.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30686Better warnings when minherit/madvise fails2020-06-13T15:41:55ZNick MathewsonBetter warnings when minherit/madvise failsSee #30614 -- our current behavior here is to give a BUG message, which doesn't help the user understand what to do.See #30614 -- our current behavior here is to give a BUG message, which doesn't help the user understand what to do.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30649Every few hours, relays [warn] Received circuit padding stop command for unkn...2020-06-13T15:41:53ZteorEvery few hours, relays [warn] Received circuit padding stop command for unknown machine.toralf says on #tor-relays:
```
I got 5x within last 36 ours with 0.4.1.1-alpha: [warn] Received circuit padding stop command for unknown machine. -shall I ignore that?
```
I'm marking this as 041-must, because we will get lots ...toralf says on #tor-relays:
```
I got 5x within last 36 ours with 0.4.1.1-alpha: [warn] Received circuit padding stop command for unknown machine. -shall I ignore that?
```
I'm marking this as 041-must, because we will get lots of bug reports from relay operators if we release a stable with this warning. At the very least, we must downgrade it to a protocol error.Tor: 0.4.0.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29298Explicitly specify histogram bin endpoints/widths2020-06-13T15:41:38ZMike PerryExplicitly specify histogram bin endpoints/widthsGeorge has convinced me that we should explicitly specify the bin labels of our histograms rather than rely on a formula and lots of special cases for short histogram lengths.
The most straight-forward thing is to let researchers specif...George has convinced me that we should explicitly specify the bin labels of our histograms rather than rely on a formula and lots of special cases for short histogram lengths.
The most straight-forward thing is to let researchers specify a list of bin labels.. It might be more compact to encode if this list is a list of widths, but that may just be an encoding decision for the consensus. We should probably choose simplest possible representation here.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30578The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document,...2020-06-13T15:41:38ZNick MathewsonThe circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document, or ___?Our code in `test_circuitpadding.c` says:
```
/** Disabled unstable test until #29298 is implemented (see #29122) */
// TEST_CIRCUITPADDING(circuitpadding_circuitsetup_machine, TT_FORK),
```
But both #29298 and #29122 are closed no...Our code in `test_circuitpadding.c` says:
```
/** Disabled unstable test until #29298 is implemented (see #29122) */
// TEST_CIRCUITPADDING(circuitpadding_circuitsetup_machine, TT_FORK),
```
But both #29298 and #29122 are closed now.
If this test will work now, let's enable it. If it is no longer useful, let's remove it. If it is disabled for some reason other than the one that's described in the comment, let's adjust the comment.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/29500Broken circuitpadding unittests on appveyor2020-06-13T15:40:08ZGeorge KadianakisBroken circuitpadding unittests on appveyorThis x86 appveyor build failed two unittests: https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
```
circuitpadding/circuitpadding_tokens: [forking]
FAIL ../src/test/test_circuitpadding.c:1125: assert...This x86 appveyor build failed two unittests: https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
```
circuitpadding/circuitpadding_tokens: [forking]
FAIL ../src/test/test_circuitpadding.c:1125: assert(mi->histogram[4] OP_EQ 2): 0 vs 2
[circuitpadding_tokens FAILED]
circuitpadding/circuitpadding_rtt: [forking]
FAIL ../src/test/test_circuitpadding.c:324: assert(relay_side->padding_info[0]->last_received_time_usec OP_NE 0): 0 vs 0
[circuitpadding_rtt FAILED]
```Tor: 0.4.0.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29990Handle zero monotonic time differences in the circuit padding code2020-06-13T15:40:07ZteorHandle zero monotonic time differences in the circuit padding codeI can reliably get the following failure on my macOS VM when its wall clock time is out of sync with the host time.
Failures like this also intermittently happen when the underlying API is low-resolution, or not actually monotonic (for ...I can reliably get the following failure on my macOS VM when its wall clock time is out of sync with the host time.
Failures like this also intermittently happen when the underlying API is low-resolution, or not actually monotonic (for example, Windows).
```
circuitpadding/circuitpadding_circuitsetup_machine: [forking]
FAIL ../src/test/test_circuitpadding.c:1900: assert(client_side->padding_info[0]->padding_scheduled_at_usec OP_NE 0): 0 vs 0
[circuitpadding_circuitsetup_machine FAILED]
```
I've worked around the issue in #29500 by weakening the test conditions.
But we need to fix the circuitpadding code so it handles zero monotonic time differences correctly.Tor: 0.4.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29840WTF-PAD: Log padding counters into the heartbeat2020-06-13T15:39:39ZGeorge KadianakisWTF-PAD: Log padding counters into the heartbeatWe should tie the padding counters in circuitpadding to the heartbeat so that we can see (at least on the relays) how much padding we are sending/receiving.We should tie the padding counters in circuitpadding to the heartbeat so that we can see (at least on the relays) how much padding we are sending/receiving.Tor: unspecified