On 10/30/20 5:55 PM, anonym wrote:
proc...@riseup.net:
On 10/29/20 3:18 PM, anonym wrote:
proc...@riseup.net:
On a related note, with restrict-stream-events set to true, I was
still able to access all stream events when testing with netcat in the
workstation VM. Initially it worked as intended and didn't pass this
info, but during subsequent trials it would read everything Tor was
doing.
Woah, so it would probably work inside Tails?! I am very much interested
in reproducing and investigating this in that case. Please help me out
with any info/instructions you have about this!
OK so assuming you have restrict-stream-events toggled to false and
circuit-status whitelisted in the active profile, you would connect to
Tor with netcat like so (depending on the controlport no. you use). Have
Tor Browser open concurrently and browse to some page.
Then:
nc 127.0.0.1 9051
GETINFO circuit-status
It will initially give a 250 OK,but repeated, it'll show you everything
including the browser's circuit paths.
There's also a onion-grater debug mode that shows how it interacts with
incoming commands documented here you might find useful:
https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy#onion-grater_enable_debug_mode
Follow up: what is the best approach to capturing this section of the
pattern
$relayid~$relayid,$relayid~$relayid,$relayid~$relayid
?
Just using (\S+) once or
do I have to do \$(\S+)~\$(\S+),\$(\S+)~\$(\S+),\$(\S+)~\$(\S+)
?
I'd say, use the most accepting rule that doesn't break the
functionality you want to keep since it is the more fail-safe approach,
so if the first one works, it's better IMHO.
* Is it even possible to sanitize responses as large and varied as
stream-events output without having something leak thru or is it
best to keep it blocked for peace of mind?
Theoretically, I think yes, but any black-list approach is pretty
much futile to get perfect unless you put unreasonable resources on
maintaining it. So at best you it can be considered in a
defense-in-depth approach, but not as a single defense, IMHO.
I think another problem is circuit info is multi-line and don't all
start with 250+circuit-status=
I'm guessing this prevents any use of a wildcard as an easy catch-all
for the whole replies?
First, let's note that the rewrite rules operate on a per-line basis,
which indeed puts some limitations of what is possible.
My understanding is that you want to rewrite the multiline response of
e.g. `GETINFO circuit-status` from something like:
250+circuit-status=
16 BUILT …
18 EXTENDED …
…
.
250 OK
to an "empty" response:
250+circuit-status=
.
250 OK
Is this correct?
If so, yes, I think there is a problem. I believe the best we can do at
the moment is to have a rule like:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '[0-9]+ (BUILT|EXTENDED|…) .*'
replacement: ''
i.e. that matches all the other lines of the response and replaces them
with the empty sting... but that would result in a response with a bunch
of empty lines in it:
250+circuit-status=
<empty line>
<empty line>
… one <empty line> for each circ
uit …
.
250 OK
which is think is invalid according to the control-spec. But it's worth
testing, I guess! :)
Alright. I guess it can be left empty or at least stripped down enough
to appease the circuit dialog so it appears. Will need to experiment
around to know.
But the better solution would be to extend onion-grater with something
like the `suppress` option that exists for events, e.g.:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '[0-9]+ (BUILT|EXTENDED|…) .*'
suppress: true
which would mean that any response line matching the pattern is
completely dropped. I'm not completely sure, but it shouldn't be that
hard to implement.
Is this what you would like, or am I way off? If the latter, please try
to explain in more detail what it is you want to achieve, preferably
with concrete examples of the Tor output you get and exactly how you
want it transformed.
Indeed it is. Thanks for your help.
Cheers!
_______________________________________________
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
