anonym:
> Patrick Schleizer:
>> anonym:
>> About the packaging. If you like the genmkfile way to package things, I
>> could also do the packaging. Only disadvantage would be an extra
>> dependency on genmkfile.
>>
>> https://github.com/Whonix/control-port-filter-python
>> https://github.com/Whonix/genmkfile
>>
>> That would be trivial on my side since Tails control filter seems very
>> similar to control-port-filter-python. (control-port-filter-python
>> packaged with genmkfile is a lintian --pedantic warning free and to my
>> knowledge, fully complaint Debian source and binary package.) Otherwise,
>> I'd just wait for you.
>
> Sure! I bet you'll beat me to it, so I don't want to be the blocker, but
> perhaps I'll take over the packaging in the future, depending on how
> things go (would this make sense to include in Debian?). However, first
> we need, in order:
Not sure if upload to Debian would benefit any of our projects or if
anyone besides our two projects would be interested in that package. Due
to release cycles, I guess we'd end up not using that package in
Tails/Whonix anyhow. I must admit, that this chance to get genmkfile
into Debian as a byproduct is more appealing than the filter itself.
If any other of Whonix's packages seems useful to be uploaded to Debian
or otherwise useful for Tails, I'd be happy to polish them if there are
any requests to return the favor and to improve the cooperation.
> 1. A name that doesn't including 'tor'. What about 'grater' or
> 'onion-grater'? My inspiration is something like [0]. :) Otherwise
> there's 'onion-filter' I guess.
What about control-port-filter-python? :)
I was rethinking this. The packaging may not be that important on the
Whonix side. Since the tails filter is small, clean, nice and simple and
"quite similar" to currently used control-port-filter-python... I could
just copy over the tails filter to control-port-filter-python
usr/sbin/cpfpd. (Along with some minor things such as debian/control
migrating dependencies list and systemd unit file differences.)
> 2. A dedicated Git repo (trivial once we have a name).
https://github.com/Whonix/control-port-filter-python ? :)
The separate upstream tails filter repository would just help me to stay
on top of changes rather than following changes in the huge Tails main
repository. It's not very important either. If you'd ever find a
security critical issue, please notify me. Otherwise for newer features,
I'll probably learn about them early enough.
>> I added 'Flags=DiscardPK', which works and I thought that is useful at
>> least in case of Whonix. The workstation does not need to learn the
>> hidden service key since onionshare does not use it anyhow. Not sure
>> this (and the following) makes also sense in Tails?
>>
>> Some lines in Tor's response contain the following:
>> (azazazazazazaz10 is the HS)
>>
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=0
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=1
>> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN gliberrish gliberrish
>> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN gliberrish
>>
>> Could you please show how to rewrite them to:
>>
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=0
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=1
>> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN dedacted dedacted
>> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN dedacted
>>
>> I am not sure stem would complain about this, but I guess not
>
> onionshare uses stem's `create_ephemeral_hidden_service()` convenience
> method with `await_publication=True`, and it tracks the state of the
> hidden services publication via HS_DESC events, so you have to be
> careful here (e.g. only allowing the UPLOADED won't work, probably).
>
> So, to me it looks like you need the following (untested) config,
> although you might want to study the spec to see which events are to be
> expected:
>
> HS_DESC:
> - pattern: '650 HS_DESC CREATED (\S+) (\S+) (\S+) \S+ (.+)'
> replacement: '650 HS_DESC CREATED {} {} {} redacted {}'
> - pattern: '650 HS_DESC UPLOAD (\S+) (\S+) .*'
> replacement: '650 HS_DESC UPLOAD {} {} redacted redacted'
> - pattern: '650 HS_DESC UPLOADED (\S+) (\S+) .+'
> replacement: '650 HS_DESC UPLOADED {} {} redacted'
> - pattern: '.*'
> replacement: ''
That unfortunately does not work.
user@host:~/tcpfp$ ./tor-controlport-filter --listen-address 0.0.0.0 --debug
Tor control port filter started, listening on 0.0.0.0:9051
10.137.11.80:51904 (filter: whonix) connected: loaded filter: whonix
Final rules:
commands:
ADD_ONION:
- {pattern: 'NEW:BEST Port=80,(176[0-5][0-9])', replacement: 'NEW:BEST
Port=80,{client-address}:{}
Flags=DiscardPK'}
DEL_ONION:
- {pattern: .+}
GETCONF:
- {pattern: (__owningcontrollerprocess)}
GETINFO:
- {pattern: circuit-established}
- {pattern: status/circuit-established}
- pattern: net/listeners/socks
response:
- {pattern: 250-net/listeners/socks=".*", replacement:
'250-net/listeners/socks="127.0.0.1:9150"'}
- {pattern: version}
- {pattern: onions/current}
SIGNAL:
- {pattern: NEWNYM}
events:
CONF_CHANGED: {suppress: true}
HS_DESC:
- {pattern: 650 HS_DESC CREATED (\S+) (\S+) (\S+) \S+ (.+),
replacement: '650 HS_DESC
CREATED {} {} {} redacted {}'}
- {pattern: 650 HS_DESC UPLOAD (\S+) (\S+) .*, replacement: '650
HS_DESC UPLOAD
{} {} redacted redacted'}
- {pattern: 650 HS_DESC UPLOADED (\S+) (\S+) .+, replacement: '650
HS_DESC UPLOADED
{} {} redacted'}
- {pattern: .*, replacement: ''}
SIGNAL: {suppress: true}
restrict-stream-events: false
10.137.11.80:51904 (filter: whonix): -> PROTOCOLINFO 1
10.137.11.80:51904 (filter: whonix): <- 250-PROTOCOLINFO 1
10.137.11.80:51904 (filter: whonix): <- 250-AUTH METHODS=NULL
10.137.11.80:51904 (filter: whonix): <- 250-VERSION Tor="0.2.8.9
(git-cabd4ef300c6b3d6)"
10.137.11.80:51904 (filter: whonix): <- 250 OK
10.137.11.80:51904 (filter: whonix): -> AUTHENTICATE
10.137.11.80:51904 (filter: whonix): <- 250 OK
10.137.11.80:51904 (filter: whonix): -> SETEVENTS SIGNAL CONF_CHANGED
10.137.11.80:51904 (filter: whonix): suppressed subscription to event
'SIGNAL'
10.137.11.80:51904 (filter: whonix): suppressed subscription to event
'CONF_CHANGED'
10.137.11.80:51904 (filter: whonix): <- 250 OK
10.137.11.80:51904 (filter: whonix): -> GETCONF __owningcontrollerprocess
10.137.11.80:51904 (filter: whonix): <- 250 __OwningControllerProcess
10.137.11.80:51904 (filter: whonix): -> GETINFO version
10.137.11.80:51904 (filter: whonix): <- (multi-line)
250-version=0.2.8.9 (git-cabd4ef300c6b3d6)
250 OK
10.137.11.80:51904 (filter: whonix): -> SETEVENTS HS_DESC SIGNAL
CONF_CHANGED
10.137.11.80:51904 (filter: whonix) disconnected: client quit
----------------------------------------
Exception happened during processing of request from ('10.137.11.80', 51904)
Traceback (most recent call last):
File "/usr/lib/python3.4/socketserver.py", line 613, in
process_request_thread
self.finish_request(request, client_address)
File "/usr/lib/python3.4/socketserver.py", line 344, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python3.4/socketserver.py", line 669, in __init__
self.handle()
File "./tor-controlport-filter", line 574, in handle
restrict_stream_events
File "./tor-controlport-filter", line 456, in handle_controlport_session
update_event_subscriptions(events)
File "./tor-controlport-filter", line 393, in update_event_subscriptions
if not rule.get('suppress', False) or \
AttributeError: 'list' object has no attribute 'get'
----------------------------------------
> However, I saw something in the stem code that might indicate it
> actually uses the value you want to redact, but I might be mistaken.
I would not be too surprised if padding needs to be added. I.e. fake
values need to have compatible string lengths. Perhaps stem checks if
the string lengths make sense or stores these values for further use. I
however don't think it "really" needs them for onionshare functionality
so fake values may work. Will check once the config is working.
Cheers,
Patrick
