Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process.
The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis.
See bug 16585, particularly comment 5 and onward:
https://trac.torproject.org/projects/tor/ticket/16585#comment:5
Perhaps read comment 10 first.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 16.08.2015 at 17:36, starlight.2015q3@binnacle.cx wrote:
Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process.
The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis.
See bug 16585, particularly comment 5 and onward:
https://trac.torproject.org/projects/tor/ticket/16585#comment:5
Perhaps read comment 10 first.
It would be nice to have both installed as services by the deb-package or two different deb-packages for tor-client and tor-relay.
Apart from the fact that they run the same binary they are quite different to configure and setup.
Maybe that would help to make it easier to run relays and hidden services on the same machine.
Hi,
Shipping tor-client and tor-relay as separate packages is the worst thing we could do, since it's the same thing with just one config line more or less. It will mess things up terribly.
We don't know that just yet, we are getting to fast from one thing to another - wait until proper review over that ticket and we'll see what needs to be done / if something needs to be done.
On 8/16/2015 8:50 PM, Ana Lucia Cortez wrote:
On 16.08.2015 at 17:36, starlight.2015q3@binnacle.cx wrote:
Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process.
The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis.
See bug 16585, particularly comment 5 and onward:
https://trac.torproject.org/projects/tor/ticket/16585#comment:5
Perhaps read comment 10 first.
It would be nice to have both installed as services by the deb-package or two different deb-packages for tor-client and tor-relay.
Apart from the fact that they run the same binary they are quite different to configure and setup.
Maybe that would help to make it easier to run relays and hidden services on the same machine.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I think separate packages are good idea --is about making it easier for regular users to configure Tor with less pain.
'openssh' provides a good example, as it come with three component packages:
openssh (core files) openssh-client openssh-server
so one would have
tor-core tor-client tor-server
where the client and server packages would configure separate run-time directories, 'torrc's and boot-system start/stop scripts for the respective instances. The 'tor' binary would appear in the tor-core component.
I am confident of the analysis regarding how easy it is to isolate client circuit establishment cells from other relay traffic. Is rather obvious--just look at the debug trace 'channel_write_packed_cell' lines associated with circuit establishment and how they stand-out temporally from the relay channel_write_packed_cell() lines. Unfortunately the log-to-file feature does not include fractional seconds, but it's glaring even with whole-second resolution.
At 23:47 8/16/2015 +0300, you wrote:
Hi,
Shipping tor-client and tor-relay as separate packages is the worst thing we could do, since it's the same thing with just one config line more or less. It will mess things up terribly.
We don't know that just yet, we are getting to fast from one thing to another - wait until proper review over that ticket and we'll see what needs to be done / if something needs to be done.
On 8/16/2015 8:50 PM, Ana Lucia Cortez wrote:
On 16.08.2015 at 17:36, starlight.2015q3@binnacle.cx wrote:
Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process.
The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis.
See bug 16585, particularly comment 5 and onward:
https://trac.torproject.org/projects/tor/ticket/16585#comment:5
Perhaps read comment 10 first.
It would be nice to have both installed as services by the
deb-package
or two different deb-packages for tor-client and tor-relay.
Apart from the fact that they run the same binary they are quite different to configure and setup.
Maybe that would help to make it easier to run relays and hidden services on the same machine.
tor-relays mailing list tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sun, Aug 16, 2015 at 05:14:42PM -0400, starlight.2015q3@binnacle.cx wrote:
Unfortunately the log-to-file feature does not include fractional seconds, but it's glaring even with whole-second resolution.
Haven't looked at the rest of this thread, but:
LogTimeGranularity 1
--Roger
At 17:32 8/16/2015 -0400, you wrote:
LogTimeGranularity 1
Thank you! I'm putting this in the debug activation script:
TORCTRL=x.x.x.x nc ${TORCTRL:?} 9151 <<EOF AUTHENTICATE "password" SETCONF LogTimeGranularity=1 SETCONF Log="debug file logfile$(date '+%M%S')" QUIT EOF
Running a relay and hidden service should also should be considered, as deanonymizing an HS by correlation to another relay seems more dangerous than unmasking a client+relay.
As far as I know, tor only does anything about the former if accounting is also enabled, which will give the following warning in its log:
Using accounting with a hidden service and an ORPort is risky: your hidden service(s) and your public address will all turn off at the same time, which may alert observers that they are being run by the same party.
Perhaps tor should detect any potentially conflicting setups, print an error and refuse to run? (Maybe have an override option?) It seems like something to at least give warnings on.
On having separate packages, that could be a bit of a convenience, but would probably be more of a thing to ask various distro package maintainers.
starlight.2015q3@binnacle.cx:
I think separate packages are good idea --is about making it easier for regular users to configure Tor with less pain.
'openssh' provides a good example, as it come with three component packages:
openssh (core files) openssh-client openssh-server
so one would have
tor-core tor-client tor-server
where the client and server packages would configure separate run-time directories, 'torrc's and boot-system start/stop scripts for the respective instances. The 'tor' binary would appear in the tor-core component.
I am confident of the analysis regarding how easy it is to isolate client circuit establishment cells from other relay traffic. Is rather obvious--just look at the debug trace 'channel_write_packed_cell' lines associated with circuit establishment and how they stand-out temporally from the relay channel_write_packed_cell() lines. Unfortunately the log-to-file feature does not include fractional seconds, but it's glaring even with whole-second resolution.
At 23:47 8/16/2015 +0300, you wrote:
Hi,
Shipping tor-client and tor-relay as separate packages is the worst thing we could do, since it's the same thing with just one config line more or less. It will mess things up terribly.
We don't know that just yet, we are getting to fast from one thing to another - wait until proper review over that ticket and we'll see what needs to be done / if something needs to be done.
On 8/16/2015 8:50 PM, Ana Lucia Cortez wrote:
On 16.08.2015 at 17:36, starlight.2015q3@binnacle.cx wrote:
Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process.
The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis.
See bug 16585, particularly comment 5 and onward:
https://trac.torproject.org/projects/tor/ticket/16585#comment:5
Perhaps read comment 10 first.
It would be nice to have both installed as services by the
deb-package
or two different deb-packages for tor-client and tor-relay.
Apart from the fact that they run the same binary they are quite different to configure and setup.
Maybe that would help to make it easier to run relays and hidden services on the same machine.
I run a relay for about 6 weeks now, on and off a bit because of power outages. I see extremely erratic traffic usage. From 5kb/sec to 250 kb/sec.
I am not aware that I made any changes to cause this. On the low end I see only incoming traffic, those seem to be only maintenance signals!?!
I run a relay for about 6 weeks now, on and off a bit because of power outages. I see extremely erratic traffic usage. From 5kb/sec to 250 kb/sec.
Hello,
If your relay is flapping, you can’t have a high consensus, and so only little number of Tor clients will use it. You need to have stable and long running relay to gain more consensus and bandwidth usage.
And it take more than 68 days for a stable relay to reach full capacity. See https://blog.torproject.org/blog/lifecycle-of-a-new-relay
Regards,
tor-relays@lists.torproject.org
-
Aeris -
Ana Lucia Cortez -
ncl＠cock.li -
Roger Dingledine -
s7r -
starlight.2015q3＠binnacle.cx -
Uwe