tor-relays June 2014

tor-relays@lists.torproject.org

89 participants
50 discussions

Bridge clients don't *really* update dynamic bridge IPs from fingerprints?
by Rick Huebner 28 Jun '14

28 Jun '14

I run a bridge from a "semi-static" home internet account, where the address is dynamically assigned but only changes when either the ISP or my hardware router goes down and forces a reconnect, which only happens maybe once every several months. I've read in a few places that Tor bridges with dynamic IP addresses are just as useful as those with static addresses, even if their address changes pretty often, because the bridge user's client will use the bridge's fingerprint to look up its current address and port from the bridge authority if it fails to connect. How certain are we that this is actually happening? It's not the behavior I'm seeing here. My IP address has changed maybe 3 times in the last year, once for an ISP outage after a storm, and for a couple of hardware router firmware updates on my end. In each case, my bridge's traffic plummeted back to essentially nil, with a long slow regrowth over several weeks (or months!) as the new address slowly propagated around to a new set of users. I like to monitor the "Who has used my bridge?" status from Vidalia, and I get a real heartwarming glow when I see places like Syria and Iran showing up regularly. I've had a nice steady clientele keeping my bridge pretty busy for the past few months, and then yesterday I needed to do a firmware update, and *pfft* all my clients are gone again and I'm back to square one. Sigh. What's worse, I then picture that hypothetical Syrian civil rights dissident who's come to rely on my bridge always being there, suddenly being stranded without a connection and needing to scramble to find another one. Unnecessarily, as I was back up in minutes, just with a new address. It's pretty clear that the mechanism for clients to refresh their bridge's addresses is there, but I'm doubting that it's actually working right. I can think of two main failure modes: either the fingerprint isn't being distributed (or entered), leaving the user with just the current IP address and port with no way to query the bridge authority for an update. Or it's being entered, but not actually used by the client. For the first, BridgeDB does distribute the fingerprints, but I note that the docs/bridges.html.en page mentions that it's optional, but then doesn't say anything about what it's good for or why you should include it, so I wonder if many users just don't bother, especially if they need to query BridgeDB from a different PC than they run their own copy of TBB on and can't easily copy & paste the whole thing. Also, it seems the email responder channel doesn't even give out the fingerprints at all, leaving all those users automatically without updates. I don't know the distribution split between BridgeDB site queries and email queries, so it's hard to guess the impact of that lack, but it seems like something that could be easily fixed regardless. Probably more critical though, is the second option. Why would the fingerprint not be used if it was entered? Maybe some key option got disabled somehow? If I'm reading the torrc manual right, there's an option called UpdateBridgesFromAuthority that controls exactly this behavior... and it defaults to off. And to see how it ends up being set in the actual TBB, I installed that and checked its torrc, and it's not in there either, so apparently it stays disabled. "Well, there's your problem..." So am I missing something, or has this feature somehow fallen through the cracks and ended up accidentally disabled for the vast majority of all bridge users? It seems like this must be having a pretty serious impact on overall bridge usage, as I was under the impression that a big percentage of bridges are run off of dynamic address accounts, and many of those will be changing addresses more often than mine, maybe as frequently as daily in the worst cases. And every time they do, they lose their entire clientele and have to restart the long, slow ramp up to a new user base again from scratch. This kind of forced, pointless churn can't possibly be good for the network. How many bridge operators are we losing every year because they never see significant traffic due to changing IP addresses too often? And if they ask about it, they're just told, "Sure, dynamic IP is fine, just be patient and they will come." And what's the impact on the bridge users of having their bridge connections going bad so much more often than they should? I think simply getting a bridge address might be a risk exposure for many of these people, and making them do it more often could be dangerous for them. Or maybe I'm just totally misreading this, and my own experiences of losing all my bridge clients on each change aren't typical, but are due to some other unknown singular issue. How about you other bridge providers, how many of you are on dynamic IP addresses, and have you noticed a similar huge drop in traffic after a change, or does your traffic seem to snap back pretty quickly as it should?

3 3

running Tor relay live with AddressSanitizer
by starlight.2013q4＠binnacle.cx 28 Jun '14

28 Jun '14

Has anyone tried running a live relay with an image built using GCC 4.8 and -fsanitize=address? AddressSanitizer documentation says it should be no worse than about x4 on CPU and typically about x2, so it looks reasonable to try. I'm seeing peak CPU of about 7-8% of a 2.2GHz AMD core. I'd probably create a static build, with 'libevent' and 'tor' compiled using -fsanitize=address -O1 -fno-omit-frame-pointer -g per the Google documentation and 'libz' compiled normally since 'zlib' is stable and mature. Any thoughts or experience? Thanks

3 6

bitcoin adopt a node idea
by jason＠icetor.is 27 Jun '14

27 Jun '14

This seems pretty damn similiar to something we should be offering for Tor relays, possibly even exits and bridges (if they only run for a month at a time). Possibly co-ordinated through the EFF? http://www.coindesk.com/adopt-node-project-aims-bolster-bitcoin-network-sec… -Jason

6 8

Is my tor exit relay set up correctly?
by Sander Bongers 26 Jun '14

26 Jun '14

Hi, A few weeks ago I setup a tor exit relay, using this documentation: https://www.torproject.org/docs/tor-relay-debian.html.en I have somewhat experience, so I kinda knew what I was doing, and I got the message "Self-testing indicates your ORPort is reachable from the outside. Excellent." in the log file. But my server doesn't seem to appear in any tor relay lists such as https://globe.torproject.org, even after a few weeks. What could I have done wrong?

4 5

Re: [tor-relays] [tor-relay] Spam
by tor＠t-3.net 26 Jun '14

26 Jun '14

The spam to my own Tor relay operator email address (same one as in this list) isn't meaningful in volume. I haven't seen any amounts that a delete key couldn't easily handle. In my experience, you should be careful with spam filtering, as you could end up dumping abuse complaints that you wanted to see and maybe respond to, or have legitimate relay list email not come through. I ended up having to whitelist some stuff for this list to work right because of automatic spam behavior of this mail service. It's not like the sight of spam email in your tor relay box is toxic to your workstation. It's usually obvious from the subject what it is, and that it can be safely and immediately deleted.

2 1

Need help to get TorDNSEL compiled
by BlueStar88 26 Jun '14

26 Jun '14

Hi there, today I've read about the outage at "check.torproject.org". Since my torcheck-service "torcheck.xenobite.eu" needs the underlying TorDNSEL feature I'm trying to get this to work on my host. Like this I won't need to query the TorDNSEL-part of "check.torproject.org" anymore. I'm not into programming and do not know anything about haskell, c++ and such. So be patient with me on such matters. ;-) I've DL'ed the code from the internet website mirror [2]. I've prepp'ed all the dependencies using lucid binary packages: ghc6 6.12.1-12 libghc6-mtl-dev 1.1.0.2-10 libghc6-network-dev 2.2.1.7-1 libghc6-time-dev 1.1.2.4-2 libghc6-hunit-dev 1.2.2.1-2 libssl-dev 0.9.8k-7ubuntu8.15 libghc6-stm-prof 2.1.1.2-5 libghc6-binary-prof 0.5.0.2-1 First error I got on compile attempt was: src/TorDNSEL/Main.hs:81:21: parse error on input `#' That was quite easy thought: import GHC.Prim (Addr#) I deleted the '#' hopefully making it correct this way. Next error is some numbers too high for me now: src/TorDNSEL/DeepSeq.hs:20:7: Could not find module `Data.ByteString': It is a member of the hidden package `bytestring-0.9.1.5'. Perhaps you need to add `bytestring' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. The libghc6-bytestring-dev-0.9.1.5-125af ist installed by it's main package ghc6 6.12.1-12. Any ideas? Or are there some binary packages for TorDNSEL around, to make this more easy for me? :-P Thanks, BlueStar88 [1] https://blog.torproject.org/blog/tor-check-outage-03-and-04-july-2013 [2] https://www.torproject.org/tordnsel/dist/tordnsel-0.0.6.tar.gz

3 7

My exit's traffic isn't rising, is this normal?
by Jesse Victors 24 Jun '14

24 Jun '14

Hello everyone, I run https://globe.torproject.org/#/relay/1946F5E4748B069D3B989B5AF50C7DDD3AC618… and from the graphs it's clear that the traffic has roughly leveled off, rather than continue to climb. I generated a new key after Heartbleed, so it's been up for nearly three months. The bandwidth cap is set at about 100 MB/sec, (gigabit connection) which it's not even close to reaching. There's plenty of CPU available, and by all rights its got enough resources. At this rate, I've no idea how it is supposed to grow and help Tor more. For comparison, when I look at https://globe.torproject.org/#/relay/D3BDECB920E0B7543AD2BA7BF573F7B0F37F7B…, one of the Top 10 relays, I see the traffic growing much at a much higher rate, and https://globe.torproject.org/#/relay/F3B57BB429B4CA82A844B713E42666DF4BF7B8… is another example. What are they doing that I'm not? Another of my exits, https://globe.torproject.org/#/relay/2FC06226AE152FBAB7620BB107CDEF0E70876A…, is on a downward trend, yet has the same configuration as my first one. What can I do to reverse it? Thanks, Jesse V. 0xC20BEC80

1 0

KVM based virtual machine showing 4 MB/s in atlas, others showing 8-9MB/s ?
by s7r＠sky-ip.org 23 Jun '14

23 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The same virtualization technique at different providers gives me different advertised bandwidth for relays in atlas: one provider 8-9MB/s other 3-4 MB/s The relays are all exit, having the same RAM and CPU configuration, as well as 100mbit port and unmetered traffic, they use the same Tor version, none of them are capped in any way via torrc or other means, same operating system and same virtualization technique. Why could be this difference in advertised bandwidth? Suggestions? - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 PGP Pubkey: http://www.sky-ip.org/s7r@sky-ip.org.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJTqIMAAAoJEIN/pSyBJlsRTg0IAKGweB8grMmx18rB33/xBrBC 6UAbpnUxj3tDlD+7J9SwK1jkPSvxpKEkKuwblFifJ2J1o4xoUKCvQQWLVfwP4qRI 0R6cn/Zx9pShzZ6MRRIOmuxaZjiavddqeM0/qcnwhsvGVH/6sTw80000VrLV2TMH vExzu7ofEjV1205CZ1CBAj0sOW2s+3nld7iulvttWbBoeHs2+CbRpEfQu1QPoZYu NtJ6f0vBBkenCWD/yv9Xaiwo/Ywej6jH97LIdksr9msRcDmJnbmY3VSmrlnm8n7z YFJSCFlOi3LJIB0y8QmZuowHAQcGe0Q1LmGCWU4uGgB4OHU7QRgC/jM7qffp+eQ= =+FWS -----END PGP SIGNATURE-----

1 0

Shutting down middle relays (off-topic)
by Tora Tora Tora 23 Jun '14

23 Jun '14

Regretfully, I have to shutdown my two middle relays (not too big, you won't even notice it :-D), since I am unable to resolve issues with the latest OpenSSL bug. I was able to find upgraded packages for Centos and Fedora that are supposed to address CVE-2014-0224 vulnerability (the change log claims so). However, the Tripwire )SSL_CCS_InjectTest and Qualys onlien tests both disagree. If someone can suggest a resolution that works, I might be able to keep them running, otherwise I see no point in running vulnerable relays until I figure things out. Thanks ...

7 15

CLI tool like Atlast
by Kali Tor 23 Jun '14

23 Jun '14

Hi all, Is there a CLI client/tool that does what https://atlas.torproject.org/ does? Basically provide an output based on a node's fingerprint? e.g. https://atlas.torproject.org/#details/7EDE11A41D1C7DF4F9103ABAA4F0A31E42CB0… Thanks, KaliTor

5 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays June 2014