Re: [tor-relays] do not run Tor client and OR relay together!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16.08.2015 at 17:36, starlight.201...@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. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJV0M1QXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1ODMzNjFDQzQ3RjU4RjJGRTVEMzFERUM3 NDk4QUQzNjFFNDA3NzFFAAoJEHSYrTYeQHceyoIP/jM+tWDXOzLDMPrKcT5OfHjT 5l3bX+TyDGw3/L/C3EQupZyU57uKh9TNX9rrfUQUZ7jk28LdCPs+m6sajI7Fauuk E8AGT2mRWj+a5H6fffWvCVzUr3/XMuFpYP30bbZ30a+sGGl2anqnyDnTFJGOl4Hl 6hbcKezNI7iqPf6ju1QbEtwh1p6gSNncKrWw/vqC21ATWUM+y74EMZIkTmJruSpe cC5b/A2URDPQM4c+vS2vPl+LSBdiGw5nFWeixiS/yv2X/6sAiqGzBcTzW3Sh1w6x ZRF6ycLL2X59uA4QrgpYxWH871UA3eFRTw+TdPanbsgFpHmPyG1U8LceCwfxjMhn qsBA9/WVp/Av+SV6ElhZkC5c9Nulj2tJDA+tnIotB6mB/ge4FoBlHj2GHGzq2pRX yf5EgXZbk4oBhGUKLQyaLQ+NJ5iqnnaLdcPL4HnE/HvsJtGBDpa2PlLEu7fvuSsV OeFtzPf0FbLdvyHEXfyYU15U4Tbg/NNBpsXLfm7sXJqLaY14HMsSEE0R7jZFkdhX j61SiGUq2GHffXVnw7n8lGyn9OYh3FUqzlwYLaL2vhi/6rNCp1OL2uklJvYEC5o1 cNuOHiXcBcMFMaw3JLAyr88mODAf31TL9ecsxK63R9kqlU7b+gHT2oh/rBl3mTP6 w1YEvnYl+U/DsXuUsgBq =78AI -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Guidelines for lifetime of a bridge?
Hi. Is there a guideline for how long a bridge should exist on a particular IP address? For example, does it make sense to keep a bridge on one IP address forever? Or is it better to move a bridge to a new IP address periodically, perhaps every 120 days? I ask because I saw traffic to my bridge ramp-up fairly steadily, and then quickly drop-off to a low number of clients per day. Thanks! hope you are all well t -- Tim Sammut ~ @t1msammut ~ t...@teamsammut.com Ford-Mozilla Fellow at Amnesty International ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] do not run Tor client and OR relay together!
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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guidelines for lifetime of a bridge?
Tom van der Woerdt transcribed 7.7K bytes: I'd say about a year is ideal. Maybe longer. It takes a long time for your bridge's IP address to be handed out to users. Once they finally have one, the addresses should remain valid, instead of immediately expiring. Of course once it looks like your bridge's IP address has been exposed, drop the bridge and move it. Tom Hi, Tom's advice above is pretty solid. Please, do not do as starlight suggested, since (as Tom already mentioned) it takes a while for BridgeDB to distribute your Bridge to enough users. Since you've seen the traffic drop off, you might want to consider changing IP addresses. Also, if you aren't already, you might want to consider running the obfs4 Pluggable Transport if you can, since it is direct probing resistant and DPI-resistant. Thanks for running a Bridge! -- ♥Ⓐ isis agora lovecruft _ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] urras? [was: tor network loses ~50 relays/day due to bw auth problem]
On 5/31/15, Jannis Wiese m...@janniswiese.com wrote: ... At the moment I just see urras missing from the consensus... i would like to report a missing Tor-DA to the authorities. ;) best regards, ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] urras? [was: tor network loses ~50 relays/day due to bw auth problem]
Hi Coderman. Yup, Jake is aware of this and has been working on it for a while. :P https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/005986.html Cheers! -Damian On Sun, Aug 16, 2015 at 5:06 PM, coderman coder...@gmail.com wrote: On 5/31/15, Jannis Wiese m...@janniswiese.com wrote: ... At the moment I just see urras missing from the consensus... i would like to report a missing Tor-DA to the authorities. ;) best regards, ___ 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
[tor-relays] very erratic tor usage
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!?! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] very erratic tor usage
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, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] do not run Tor client and OR relay together!
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.201...@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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] do not run Tor client and OR relay together!
On Sun, Aug 16, 2015 at 05:14:42PM -0400, starlight.201...@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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] do not run Tor client and OR relay together!
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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guidelines for lifetime of a bridge?
Five, ten days? I ran a bridge at a provider where IP addresses are easy to release and replace with new ones. Seems to take the censors in China, Iran, Pakistan, etc less than a week to find and block new bridge IPs. I gave up in frustration. Meek is a better solution but is not something an individual can readily put into operation. China has cracked down on all GFW bypasses rather successfully, including VPN providers who have a strong financial incentive to succeed. Iran is nearly as good. I find running a relay more satisfying and would add relays instead of bridges now. At 19:24 8/16/2015 +0100, you wrote: Hi. Is there a guideline for how long a bridge should exist on a particular IP address? For example, does it make sense to keep a bridge on one IP address forever? Or is it better to move a bridge to a new IP address periodically, perhaps every 120 days? I ask because I saw traffic to my bridge ramp-up fairly steadily, and then quickly drop-off to a low number of clients per day. Thanks! hope you are all well t ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guidelines for lifetime of a bridge?
I'd say about a year is ideal. Maybe longer. It takes a long time for your bridge's IP address to be handed out to users. Once they finally have one, the addresses should remain valid, instead of immediately expiring. Of course once it looks like your bridge's IP address has been exposed, drop the bridge and move it. Tom starlight.201...@binnacle.cx schreef op 16/08/15 om 20:49: Five, ten days? I ran a bridge at a provider where IP addresses are easy to release and replace with new ones. Seems to take the censors in China, Iran, Pakistan, etc less than a week to find and block new bridge IPs. I gave up in frustration. Meek is a better solution but is not something an individual can readily put into operation. China has cracked down on all GFW bypasses rather successfully, including VPN providers who have a strong financial incentive to succeed. Iran is nearly as good. I find running a relay more satisfying and would add relays instead of bridges now. At 19:24 8/16/2015 +0100, you wrote: Hi. Is there a guideline for how long a bridge should exist on a particular IP address? For example, does it make sense to keep a bridge on one IP address forever? Or is it better to move a bridge to a new IP address periodically, perhaps every 120 days? I ask because I saw traffic to my bridge ramp-up fairly steadily, and then quickly drop-off to a low number of clients per day. Thanks! hope you are all well t ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays smime.p7s Description: S/MIME-cryptografische ondertekening ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] do not run Tor client and OR relay together!
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.201...@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
