- tor-relays - lists.torproject.org

'critical' security update: Tor 0.2.2.39
by tagnaq 23 Sep '12

23 Sep '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It is quite sad that one has to find out about 'critical' security updates [0] via an unrelated thread on tor-talk [1] or the blog [2] instead of getting an announcement on tor-announce [3] - where relay operators are probably expecting such information. Are tor versions 0.2.3.x and 0.2.4.x affected too? [0] https://gitweb.torproject.org/tor.git/blob/release-0.2.2:/ReleaseNotes https://trac.torproject.org/projects/tor/ticket/6811 [1] https://lists.torproject.org/pipermail/tor-talk/2012-September/025525.html [2] https://blog.torproject.org/blog/new-bundles-security-release [3] https://lists.torproject.org/pipermail/tor-announce/ -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlBUV7cACgkQyM26BSNOM7ZeyAEArFSwM5Z0fhtXV6q7pdK9CqXV coEuuHUFrm6gjzkQ+p8A/2z2e+x4sYuJzKhlvFKnwCURw93FSqWEt5MCFRpkd6rV =FkRi -----END PGP SIGNATURE-----

2 3

bridge usage-panel behavior
by eliaz 22 Sep '12

22 Sep '12

Over the last week or so my bridge usage has been zero, whereas previously it would show clients for at least a few and usually many countries. The only exception is China, which comes up well within an hour of enabling the bridge. Usually the usage display stops at 1-8, but sometimes it shows continuing Chinese use. The bandwidth graph sometimes shows high, but not extraordinary, traffic. Usually it's quiet, and there's been no filling-up of the bandwidth. At a machine running through a different ISP, I logged on as a client looking to use my bridge address. As expected, when I got home I saw that the bridge usage registered USA 1-8 as well as the usual China 1-x. From this experiment I gather at least that my setup is working fine. So I'm wondering if the Chinese client(s) is/are inhibiting other contacts, and if so, if this apparent locking onto China is a network glitch or intentional interference. As the first step I thought I'd ask here: Has anyone else noticed an apparent locking of China (or some other country) in your usage panel? - Thanks, eli

1 0

Re: [tor-relays] Bridge relay: conversing with the message log
by eliaz 22 Sep '12

22 Sep '12

Stephen - I can't thank you enough for the clarification. I's a great help to my understanding of how Tor interacts with ISPs. - eli On 9/20/2012 3:24 PM, Stephen Mollett wrote: > Hi Eli, > > On Thursday, 20 September 2012, 13:25, eliaz <eliaz(a)tormail.org> wrote: > >> ... >> Sep 20 07:33:43.872 [Info] resolve_my_address(): Guessed local hostname >> '<NAME>' resolves to a private IP address (<ISP address>). >> Trying something else. >> Sep 20 07:33:43.872 [Info] resolve_my_address(): Interface IP address >> '<LAN address>' is a private address too. Ignoring. >> ... > >> In particular, what does it mean that the <LAN address> is being >> identified as private? > > > "Private address" in the context of an IP address usually refers to an address in one of the reserved ranges which are set aside for use on private networks and which can't be routed to over the internet. These ranges are 192.168.*.* (the commonest one, used by most home routers when issuing addresses to clients), 10.*.*.* (fairly common, especially in corporate networks) and 172.16.*.*-172.31.*.* (not seen very often). 100.64.*.*-100.127.*.* is also reserved for ISPs to use, primarily to help ease the transition from the old-style 32-bit IPv4 addressing system (addresses that look like 173.194.69.99 which is one of the addresses for www.google.com) to 128-bit IPv6 addresses (which look like 2a00:1450:4008:c01::68 - also www.google.com) > > > It's not surprising that your LAN address is a private one (most likely in 192.168.0.* or 192.168.1.* depending on what router you have); your ISP may also be using private addresses, at least for its residential customers. If your ISP does allocate you a private address, your reachability from the public internet is largely dependent on how their NAT and firewalling system works. Publishing the private address won't work, though, as it could be used by many different ISPs (or even multiple times by the same ISP!) > > > Hope this sheds a little light on the log entries. > > Stephen > > > -- gpg: 0x3E346824

1 0

Bridge relay: conversing with the message log
by eliaz 22 Sep '12

22 Sep '12

I run a bridge relay on vista x64 through my ISP's router-modem firewall. I need some help in understanding a few lines in the message log. Replacing the name of machine on my LAN by <NAME> and the IP addresses by <LAN address> and <ISP address> (= the bridge's address), the lines are: Sep 20 07:33:43.872 [Info] resolve_my_address(): Guessed local hostname '<NAME>' resolves to a private IP address (<ISP address>). Trying something else. Sep 20 07:33:43.872 [Info] resolve_my_address(): Interface IP address '<LAN address>' is a private address too. Ignoring. Sep 20 07:33:43.872 [Info] resolve_my_address(): Address '<NAME>' resolves to private IP address '<LAN address>'. Tor servers that use the default DirServers must have public IP addresses. Sep 20 07:33:43.872 [Info] router_pick_published_address(): Could not determine our address locally. Checking if directory headers provide any hints. Sep 20 07:33:43.872 [Info] router_pick_published_address(): Success: chose address '<ISP address>'. I don't know if these lines are telling me something about the bridge. In particular, what does it mean that the <LAN address> is being identified as private? This doesn't change regardless of the setting on my local LAN firewall to "public", "private", "domain" or "all". Does Tor mean by "private" simply the LAN address, and by "public" the ISP address? Despite these info lines Tor finally claims success. Does this mean that I can ignore the previous info lines? Or are they telling me that I have to do something? As far as I can tell my bridge is working fine. Thanks, eli

3 2

Min. Bandwidth for Bridge Relay?
by freeflow＠mail.md 20 Sep '12

20 Sep '12

Hi! I have around 50-60 KB/s of bandwidth that I'd like to use for running a bridge relay. Is this a sufficient amount of bandwidth? I ask because it doesn't seem like very much compared to the amounts that others donate to the tor network. Tor documentation suggests as little as 20 KB/s can be used to run a tor relay but this seems to be a very low badwidth rate. >From looking at the tor status web page via blutmagie.de it would seem that there some low bandwidth relays but are these really useful or too slow to be useful to the tor network? If someone can confirm that 50-60 KB/s for bridge relay is useful then I would go ahead & run my bridge relay. Best regards,

6 6

Re: [tor-relays] bwadv vs bwhist + implications
by torhoste＠tor.host-ed.me 20 Sep '12

20 Sep '12

> hello there! > very interesting information you shared here, thank you. > while i dont have any further information to rely on, > i would still like to share a few simple thoughts. > You're welcome. > lets assume for a second that there are no errors in the code and that Tor > is not using a significantly less than optimal network topology. > > i would argue against adjusting the traffic limit as you suggested, for > the > following reasons: > -pending more data, this ratio might arbitrarily change at any point in > time, > causing either under utilization of the network. which is what you have > set > out to prevent. > or over utilization which will cause troubles to the relay admins, > like throttling by providers. > I clearly see where you're coming from. While I *certainly* do not propose a large-scale adjustment in relay configurations (that isn't my incentive actually), I still seriously think about doing the adjustments - certainly with some offset to the observed figures to address potential over-utilization - for our very own relays. We're looking forward to receive some sponsored VPS(s) that we would like to dedicate/contribute to the Tor network and I'm somehow concerned, i.e. think it's unfortunate, that - expectedly - 1/3 of our monthly traffic limit(s) wouldn't be used after all. That said, please have a brief look at https://metrics.torproject.org/bandwidth.png?start=2010-09-19&dpi=72&end=20… - i.e. a two-year bwadv vs bwhist sample of the whole Tor network. It actually shows a rather significant trend of the "1/3 bwadv vs bwhist discrepancy" I observed previously. > -its important to have more capacity then needed, this allows better > stability and is helpful with dealing with sudden increases in Tor use, a > somewhat common event, > Same here. I wouldn't want to argue against your assumptions as they - from a general/common-sense perspective - make perfect sense. Still, looking at the two-year sample graph, I cannot really see such a network behavior, i.e. sub-samples where the gap between bwadv vs bwhist would be significantly lower at times. > of course, this is not to take away anything from your observation and > initiative. > who knows, you might have found a serious problem with the network. > I don't think there's a serious problem with the network. I just would like to ask the list for the actual reasoning of the, from my perspective rather *large*, discrepancy. You named three (actually two) things: 1. under-/over-utilization: the trend seems to be pretty constant and with some offset calculated in, I would look forward to avoid over-utilization (just for our own initiative certainly) and thus potential throttling by providers for our very own contribution to the network. 2. adjustments to peak traffic: While I totally understand the argument, I just can't see that happening (at least) within the last two years looking at the sample graph. thanks a lot for your feedback! Please don't get me wrong counter-arguing. I'm just considering opportunities for our own initiative and clearly see the general validity of your argumentation. Also I wouldn't want to exclude the possibility that I'm missing something important here and would like to ask everyone concerned to tell me where my (potential) misconception actually is ;-) Cheers, Thomas > thanks >

1 0

bwadv vs bwhist + implications
by torhoste＠tor.host-ed.me 19 Sep '12

19 Sep '12

Hi, we're currently looking forward to expand our contribution to the Tor network and as a mathematically fascinated person, I'm pretty much into statistical data from https://metrics.torproject.org/network.html at the moment and implication on Accounting/Bandwidthrate configuration opportunities for our Tor relays to utilize them at maximum efficiency, i.e. I'd like to start a discussion with other relay operators. That said, I noticed that the BW advertised into the network (bwadv) vs the BW actually put through the network (bwhist) is at a 1.544945508 ratio throughout the whole Tor network. I.e. a relay configured to provide 500 GiB of traffic/mo would put through (respectively actually is putting through right now) "just" 323.63601 GiB traffic/mo on average. Now, my questions (respectively thoughts for discussion) would be: 1. What would you assume to be the reason for it? I mean this is a calculated average through 3117 relays and thus I'd say rather meaningful, i.e. the largest possible "sample" (i.e. it isn't just a few relays behaving like so). Also, looking at one of our own two test relays that is *definitely* running 24/7 - vks24949, it pretty much shows the same figures. Vnstat estimates 342.23 GiB traffic/mo for September 12 and the relay actually is configured to provide 500 GiB traffic/mo with daily accounting set up (1.461005756 ratio vs 1.544945508 ratio calculated from *.csv provided at https://metrics.torproject.org/network.html for the whole Tor network). 2. As a result of all that, I currently come to the conclusion that it could be a good practice to actually configure 1.544945508 times the traffic for both the daily accountingmax + the actual relaybandwidthrate in KiB/s to *really* utilize the BW provided by sponsors (in our very case) to the full potential. I'm looking forward to your input on this. Thanks in advance, Thomas

1 0

Need advice on IPv6 bridge config
by Steve Snyder 19 Sep '12

19 Sep '12

I'm getting my feet wet with IPv6 bridges, so far without success. I set up a test bridge (0.2.3.22-rc) on one network and plugged the address:port into Vidalia (TBB x86_64-2.2.39-1) on another. The bridge config looks like this in part (local IPv4 address hidden): Address aa.bb.cc.dd OutboundBindAddress aa.bb.cc.dd ORPort [2a00:1d70:ed15:37:235:53:64:0]:443 At run time the final Tor log entries are: [notice] Tor has successfully opened a circuit. Looks like client functionality is working. [notice] Bootstrapped 100%: Done. In Vidalia the message log entries are: [Notice] Learned fingerprint 24432B99CA2533BC95ABF66C7AFE835F96DD2B2D for bridge 2a00:1d70:ed15:37:235:53:64:0:443 [Notice] no known bridge descriptors running yet; stalling That last line is repeated periodically forever. So I have enough connectivity to correctly determine the fingerprint, bit not enough to get bridge descriptors. What am I doing wrong? Thanks.

2 7

Goodbye list
by Dude 18 Sep '12

18 Sep '12

thanks

1 0

Bad exit
by grarpamp 17 Sep '12

17 Sep '12

Exit (one of these two I think, no guarantees): 109C56AC68DB55D16E79F832E19313E6C3E47363 67FD1D03F922975269F94EC7E4FD38C6D0E5E900 - torservers? It's not occurring now via them, but whatever exit it was generated these... Error: mail.google.com uses an invalid security certificate. The certificate is only valid for the following names: *.mywebdav.de , mywebdav.de (Error code: ssl_error_bad_cert_domain) Erroneous public key presented: aa 94 04 12 c4 32 2b c9 62 48 00 88 16 6f cd 8a 21 22 fe 6d 9d 51 63 6f 85 62 db 9c b5 3f e6 bf 1d 45 ca 51 57 3d 5f 83 97 73 b6 dd 99 86 d8 27 e5 07 71 94 cf d5 a4 92 a6 25 f8 06 fd 50 6c ad 70 2c 71 ca 66 38 1d 35 93 f1 c3 ff 52 6a 90 3d 54 fd 6f 69 34 9f 59 29 aa 05 59 91 95 33 53 8b e6 b6 cf 65 dc 02 1a 31 57 d8 f4 11 70 f5 68 46 13 af c1 dc f0 b0 ce 43 b3 13 61 8a 18 00 84 32 2b 9a 9c aa 49 f3 fc b6 a1 d2 a9 d9 bd b4 53 a0 60 46 e7 e9 22 9d 23 08 5c 91 32 89 e7 85 4e ec 18 b7 d0 b3 6b 74 fa b4 f3 08 11 1f 1b e1 55 e9 7b 90 f4 64 93 08 a2 58 70 e0 c6 41 f9 f9 d0 9c b1 3d e9 b6 ae b3 73 ac 11 d3 f6 91 9e 79 f2 b4 d7 7d 96 8a 83 30 b1 bf 40 6f 18 24 42 43 b7 b1 65 7e 3d 1f d2 47 e9 fb 2e 10 21 7c ce 20 a8 c3 35 f3 d8 91 d1 a6 a1 87 52 4b de 39 1e ec b9 4d

4 3