- tor-relays - lists.torproject.org

comparing tor patch levels on different OSes
by Nusenu 30 Mar '15

30 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I wanted to know whether a particular OS tends to be more likely running outdated* tor releases than another. In case others are interested as well, here is the answer. OSX, OpenBSD and Windows are more likely running outdated tor releases than FreeBSD or Linux. Probably not really surprising.. A more detailed answer: (ordered from bad to better) | OS | outdated_fraction | outdated relays | outdated_cw_fraction | +--------+-------------------+-----------------+----------------------+ | Darwin | 24.6154 | 16 | 0.03 | | NetBSD | 22.2222 | 2 | 0.00 | | OpenBSD| 21.8750 | 14 | 0.05 | | Windows| 17.2189 | 291 | 0.01 | | FreeBSD| 9.1743 | 20 | 0.15 | | Linux | 8.8392 | 597 | 4.29 | (based on onionoo data from 2015-03-27) If you are missing an OS (like SunOS) in the list, than this means that it does not run any outdated release at all (outdated_fraction=0%). *) actually it is about whether the relay uses a recommended version as defined by dir auths https://consensus-health.torproject.org/#recommendedversions I "added" tor 0.2.7.x to the list to avoid flagging bleeding edge relays as outdated. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVGKLtAAoJEFv7XvVCELh00SwQAJ9KR0DsZ/SaeAJTjbHg2rkU yD7vuyxnJuenoQKkm2IYRTUwKbqPMgLcHqVWGp6y84qMQQMlqLcUnpu11D/6KgGY N6TtpK7qmfploA64/34whQjFUf5mh8++9LjsdyrY3DkCv/6izz01t9KCwev0S40r Ik/2o3bE/v6Yhwrs1jL1kzm+ekTHHj21y6HOQVt9Bbe0Myfqo6jaqcd6Ilt2PDAX FoM5MqWNtrOLbWs5wYesZv6OTAvFGKx5GG0/6sNu/t5R9Z6yk/kkQNWVg87EGyaQ PNIwhXI7lnou4tuYgekqBM9TAY94im6EC789Q3uLj2q/nGzWNcjPpHU+1XCVtSeH dFnAZ/LeKVWMkUr2k08xNegsiN32QizPYW+2EMLpPml9cubTvP+4Y/YVx6Z1RNA+ eg1y6kd5l3ht97WOTTEXe6Wvl1AjHHpW5wGrd36+wpy40Ac9IlJqx2Qei4XrmWDN is9PUDqWCiMRQJCs9WVOKh0dgrdKve2/ipJB4i3O8viN/yzh9VXmzaJXqYa7Dkct CTW90uzVOQ/zM8usGkVJEgef9ICjxKqsPWQnhK68reHPbxZasOVTJ9EsCQZhPBeI MoslvWS/VvgFQ/Wvgj2zjS4LXieNbZMoPnX/SLC5dHyjs6WjGeOFgNslQJwcBNGe Q29d8/zH8q4tKBU5RpI5 =bbrP -----END PGP SIGNATURE-----

1 0

Installing obfs4 on Raspberry Pi bridge
by jchase 29 Mar '15

29 Mar '15

Hello, I run a bridge on a Raspberry Pi running Debian Wheezy and tor 0.2.4.26 . I have obfs3 installed and would like to upgrade to obfs4. So far this has not been possible. If I understand it correctly, my best bet is to update to tor 0.2.6.x and then install obfs4. Let me know if I'm wrong. And if I'm right, what is the easiest way to do that? Thanks, J. Chase

3 2

Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
by Teófilo Couto 29 Mar '15

29 Mar '15

Interesting and useful tips s7r! Thanks for sharing. Props to all! undertuga -------- Original Message -------- Subject: Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge Time (GMT): Mar 28 2015 22:20:09 From: s7r(a)sky-ip.org To: tor-relays(a)lists.torproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, obfs4 will not run on 0.2.4.x , you need at least 0.2.5.x or 0.2.6.x First, upgrade your Tor. You can use torproject.org repositories. If you are running wheezy: 1. Add the repository: # echo "deb http://deb.torproject.org/torproject.org wheezy main" >> /etc/apt/sources.list 2. Add the signing key: # gpg --keyserver keys.gnupg.net --recv 886DDD89; gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add â 3. Install keyring: # apt-get update && apt-get -y install deb.torproject.org-keyring Now upgrade your Tor, an apt-get -y install tor would upgrade to 0.2.5.1 1. You can install obfs4proxy from deb.torproject.org too: # echo "deb http://deb.torproject.org/torproject.org obfs4proxy main" >> /etc/apt/sources.list # apt-get update && apt-get -y install obfs4proxy Now, modify your torrc to enable the obfs4 transport. Make sure you also add ExtORPort auto in torrc so it will report some useful statistics. obfs4proxy also supports obfs3, and some users still use that, so if you can be an obfs3 and obfs4 bridge at the same time (requires just one more open port) it would be great. Sample torrc entry for enabling obfs4 and obfs3: ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:port ServerTransportListenAddr obfs4 [::]:port To make the bridge even better, you can bind obfs3 and obfs4 to lower ports (< 1024), if you have them free, such as obfs3 on 80 and obfs4 on 443 (for example). This will help users behind really restrictive firewalls who only allow connections on few ports. You can easily do this with libcap2-bin package: # apt-get -y install libcap2-bin # setcap 'cap_net_bind_service=+ep' /usr/bin/obfs4proxy To make this persistent after a reboot, edit the /etc/rc.local file and add this line before 'exit 0': setcap 'cap_net_bind_service=+ep' /usr/bin/obfs4proxy Hope this helps. If you don't want to use deb.torproject.org, everything required is also included in raspbian main repo: http://archive.raspbian.org/raspbian/pool/main/t/tor/ http://archive.raspbian.org/raspbian/pool/main/o/obfs4proxy/ http://archive.raspbian.org/raspbian/pool/main/libc/libcap2/ If you want to use raspbian repo, simply ignore the lines where you add deb.torproject.org to your sources.list file and just upgrade, install the required packages and modify your torrc file. Thanks for running a bridge. On 3/28/2015 11:47 PM, jchase wrote: > Hello, I run a bridge on a Raspberry Pi running Debian Wheezy and > tor 0.2.4.26 . I have obfs3 installed and would like to upgrade to > obfs4. So far this has not been possible. If I understand it > correctly, my best bet is to update to tor 0.2.6.x and then > install obfs4. Let me know if I'm wrong. And if I'm right, what is > the easiest way to do that? Thanks, J. Chase > _______________________________________________ tor-relays mailing > list tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVFyjiAAoJEIN/pSyBJlsRd+MH/36/4abGF4/h/4YZuf1TG2sf 0jJLaGt8Tg3c7038+7TbVwj884hvnA/gYaJTr8sPH8+2yuIqyxBfBu5IYNCaTCgT 7beR6KY4tJv1IgoReHUsn/4PLZ6K9vsnFTu08oQwjjolGcdx4BlAbHcsm0pZaGWA yAZlG1GKHGdn77bRHGi9F1ZKthRbMEQmXNV7abZPAbqjVFrTngOo68lDhIv46orP YPAhXx1v08cXZjfS0jcuwwaqhJPfxfP3nJSCNcJPG47ng81/eLWr5JgU3neyPhiN frZa2LCngPEeNlY5bjmaPrm/McmOM2Onrx9rXDEpezrCtAyQeGett2W1u/k+HI8= =VpQT -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Globe works fine
by eliaz 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > On 3/28/2015 6:41:50 AM, JT Allison (tor(a)arlen.io) wrote: >> That's a mirror. The actual globe site at >> https://globe.torproject.org > works just fine. > > You should contact the owner of that mirror, perhaps whois the > domain and email them. Thanks! Did it. - eliaz -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVFt3hAAoJEDqas5IE3vgrfGEH/3swR1YRr0v1SKTrQpHF4Z5U 97001YSgUkNUQmq58Wu9rLhmund8he1r04HaZ6gYGFsC8SxPsRu16ZY5WL+5k0m4 C625Y5PTG3x/vQC5eSPaOFfNspTxEh5VLDbmNdZJz3p6QezK20KEgG116g0q9qKr vRWUih40L2Frs9Dfb2feLWEZ24Qa+bt7cf7Vu1/ay+66m671HfaXEfZVW0FAlOuV EVDVOPYQqZ70wwItBkQ20nIwFf7W2bUruZFep1AcBNNvRmaJubVEN3Z7qhp73Qzq bEy57gxeFh+nehcdEb4A7Ej7eg4DhrNfzp8GXjvNe0nscCEAxwwhkwM0vL2vCmA= =ffZ3 -----END PGP SIGNATURE-----

2 1

Globe offline
by eliaz 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Account suspended? Atlas isn't running so hot either. rats... - eliaz -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVFl2RAAoJEDqas5IE3vgrpEkIAJhliXOS7VqXN36WkgEceHa+ h61MIFmulErgzlEcLJ71cJlgS9kEpPYlqVdNiOl6xEybjzwgOBfUP8Rg7wtVk7uc CgPr746XE2ld0B3Q4Hs+ZNRDPbrqXoOTCOxAf+1wqE1wQ0wmU3L0+5nhr9qtaTII f6BQKWj3gwoKk+mkc+2xSZKAgmSZm83hY/IEvmEsrdOgfEUiDbdsHVnm/ZmYkR8q FY5QRYbyV3RxNQHsgEXIrIB2CimC0y7ZdgGPN40dbsWT9ZJAjj0b7hhEkCaAnEUp 9SMD1DxA5Qa/I4hNkKTWAkreRoDUGWGC3MoUJ7AYTHMfULPHLmCi+gDxrzzIHgA= =cZB/ -----END PGP SIGNATURE-----

3 4

Monitoring my bridge I
by eliaz 27 Mar '15

27 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Since March 24 globe has been showing no bandwidth usage for my bridge. At the same time I'm measuring non-zero bandwidth locally. These local measurements run about Received ~ 10 x Sent bits. The bridge is connected to live circuits as per atlas. I've had erratic traffic since the powers that be have decreed that bridges be locked into a small number of entry nodes for long periods. when Received ~ Sent & I see traffic, interspersed with periods where Received >> Sent & no traffic. I don't *think* globe is an error, since I'm not reading any client traffic, only pokes from entry nodes. Here is my configuration, which worked fine previously: BridgeRelay 1 ## fteproxy configuration ClientTransportPlugin fte exec TorBrowser\Tor\PluggableTransports \fteproxy --managed # obfsproxy configuration ClientTransportPlugin obfs2,obfs3,scramblesuit exec TorBrowser\Tor \PluggableTransports\obfsproxy managed ## It doesn't seem to matter whether I enable the above portable transports or not. ContactInfo xxx at xxx gpg xxx DataDirectory C:\xxx\tor\TBB installed\Tor Browser\Browser\TorBrowser\Data\Tor DirPort 0 DirReqStatistics 0 ExitPolicy reject *:* GeoIPFile C:\xxx\tor\TBB installed\Tor Browser\Browser\TorBrowser\Data\Tor\geoip GeoIPv6File C:\xxx\tor\TBB installed\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6 Nickname xxx ORPort 443 RelayBandwidthBurst 196608 RelayBandwidthRate 98304 NumCPUs 2 SafeLogging 0 Maybe someone can see if the problem lies in this torrc, Or somewhere else. Or is this behavior just par for the course? Thanks - eliaz -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVFZ+bAAoJEDqas5IE3vgrYuAH/2+xr8RRHnI7lds5BFvRHC5A S8J6thDyEBGMV40YiEL1l7KHidPVcrEN/a1JjC+x000X1nooESkObkpnjdGrGVTJ Ofx73v36azB0lIIHaSjiSBQx4LqNwk6h7tfVYOAZXD3Ryc9Es1GAiPpnENRUmkMk G+CeLXCwCAt2RLhC3T/olb9tM0VfuQ2LhEk9Fykx2hTlg4gO8YUJa3WA2bkJQ730 0B9Cbp5C7lfU9pYqNGjtbAVyZX5SSo4PWXGrbmV3yfX+Sz/9e75CZHZAF9B03Qai oLSz8XpkP3KfhR9JZ0xKqjPZ1xqj5oQdj2pnXw0nzN++f6crj92XnyO/+vFbTPs= =hdI4 -----END PGP SIGNATURE-----

1 0

Hardware specs for Tor Relay
by yl 26 Mar '15

26 Mar '15

Hello, I clicked myself a cheap vserver 20 days ago and it runs Tor since then. I mainly did this to play a bit with the relay, try around and so. I took over another relay a while ago, an exit, I don't want to try around on that. It runs well, I got about 4,4 TB data up AND down since then, I have it running with 20-40Mb/s on a 100Mb/s connection (according to the hoster 100Mb/s), it runs as a non exit. CPU load it pretty high all the time according to arm it's about 80-100%, but with htop I can see that only one core of the CPU is busy, the others are not. I figured that the CPU is so busy because the vserver doesn't have AES-NI, which I confirmed by some command I run (forgot the command). So I thought I might wanna move that relay to another server, maybe at the same hoster to get higher data transfer. What hardware specs do you have and is my assumption correct with the AES-NI being one part of the bottleneck? Thanks yl

2 1

Re: [tor-relays] Hardware specs for Tor Relay
by Sebastian Urbach 26 Mar '15

26 Mar '15

On March 26, 2015 8:59:45 PM yl <tor(a)yl.ms> wrote: Hi, > Hello, > I clicked myself a cheap vserver 20 days ago and it runs Tor since then. > I mainly did this to play a bit with the relay, try around and so. I > took over another relay a while ago, an exit, I don't want to try around > on that. > > It runs well, I got about 4,4 TB data up AND down since then, I have it > running with 20-40Mb/s on a 100Mb/s connection (according to the hoster > 100Mb/s), it runs as a non exit. CPU load it pretty high all the time > according to arm it's about 80-100%, but with htop I can see that only > one core of the CPU is busy, the others are not. > > I figured that the CPU is so busy because the vserver doesn't have > AES-NI, which I confirmed by some command I run (forgot the command). Did you ask them if you can get it ? I had a VPS a while ago and they said "we disabled that for compatibility reasons" but if you want it we will turn it on. And they did it for free :-) > > So I thought I might wanna move that relay to another server, maybe at > the same hoster to get higher data transfer. > > What hardware specs do you have and is my assumption correct with the > AES-NI being one part of the bottleneck? It is the no. 1 bottleneck from my experience. I still hope that we are going to see the crypto-multithreading feature at some point in the future. -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

1 0

missing tor-0.2.5.11 package for armhf wheezy
by jensm1 26 Mar '15

26 Mar '15

Hi there, I'm running a relay on my NAS at home and just realised that it's still running on 0.2.5.10. So I went and checked the deb.torproject.org repository for wheezy and found that the tor package hasn't been updated for the armhf-architecture (for the other archs it's fine). Funny enough, the tor-geoipdb package has been updated to 0.2.5.11 which broke it for me, since it depends on tor 0.2.5.11. I hope that's the right place for this, otherwise please point me to where it belongs, thanks!

1 0

Undiagnosable Crashes in Relays
by skyhighatrist 25 Mar '15

25 Mar '15

Hello List, I am wondering if anyone has had their relay randomly crash in the past week or so. Three of mine (I run 6, nonexits) have fallen over. One of them ~5 days ago, one of them ~4 days ago, and one of them earlier today . The logs indicate everything was operating normally, and the only reason I noticed they had crashed was when I was checking what bandwidth globe.torproject was measuring for them it said some were down. The affected relays are as follows: AC9803701F9EE18194D40B38E47CE4C68CF2F567 73067CD4ADD8A294BDA913DF45B63190A52B5F9F D76252B1A6E9F01FC6772CFFB651056A2B54F92B I have no idea why they all fell over, the last thing in the logs was the usual "current status" output with some traffic measuring, seemingly immediately afterwards, the process killed itself for no reason. All of the affected relays are on DigitalOcean droplets. I intend to launch more on EC2 in the near future, however, would like to know if anyone else has experienced relay instability issues over the past few days incase its something nasty like a denial of service attempt or something. Nothing on the boxes indicates any kind of compromise, just the usual bruteforce activity from the usual actors. I have decided to start writing a "Shitty Monitoring System" to copy logs down to my local box every hour or so and HUP tor at the same time as a kind of countermeasure incase its simply a resource use issue or something, however, would love to know if anyone else has been having similar issues lately. Regards, .d

5 8