tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

New contact info for guard node Austrina
by Samuel Whited 26 May '12

26 May '12

Dear relay operators / users: I operate the guard node Austrina (fp: CA54 C9F2 AA56 FE26 D7A1 6F26 93F6 5385 E85E 2D75) and have recently updated my public key. Any sensitive communications should now use public key 0xEC2C9934 (fp: F259 8DED 56ED E408 FD41 484B FB39 BCF7 EC2C 9934) available from pgp.mit.edu. Please update your keystores, and verify that the new key is cross-signed with the old one (0x0DBB515F). Verification can also be performed via DNS — `dig +short sam._pka.samwhited.com TXT` should give the same fingerprint as above and provide an alternate download location. Contact info on the node should update shortly. Thanks, Sam -- Sam Whited pub 4096R/EC2C9934 SamWhited.com sam(a)samwhited.com 404.492.6008

1 0

tuning MaxAdvertisedBandwidth for CPU
by micah anderson 26 May '12

26 May '12

i've got an exit node that is doing a fair bit of bandwidth, but I think it is CPU bound at this point because I am getting these: Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option i'm wondering what I should set the MaxAdvertisedBandwidth to if I am averaging this type of traffic: http://torstatus.blutmagie.de/router_detail.php?FP=131b60b9afe6aea60042132d… it seems from the graphs, there are some clear plateaus at around 5100000, but I figured that folks here might have some suggestions that are better than just setting MaxAdvertisedBandwidth just to that number thanks! micah --

3 3

too many abuse reports
by mick 23 May '12

23 May '12

Hi I have today, reluctantly, switched my node torofotheworld.aibohphobia.org from an exit node to relay only. My ISP has stayed faithful over several abuse reports in the past, but this week following two more in quick sucession (from brazilian government services by the look of it) they have asked that I shut down the exit policy. Rather than lose the node entirely, I have agreed. Some bozo has been using sqlmap to scan servers through tor. Mick --------------------------------------------------------------------- blog: baldric.net fingerprint: E8D2 8882 F7AE DEB7 B2AA 9407 B9EA 82CC 1092 7423 ---------------------------------------------------------------------

10 19

Configuring a Tor relay to *not* accept torrent traffic
by Red Rover 20 May '12

20 May '12

Hi there, :-) I am running a Tor relay on a VPS. How do I configure it to NOT accept torrent traffic? I have just received an abuse report from my hosting company. All the best, Redrover

3 4

reg : closing circuits and corresponding TLS connections when application terminates
by Sambuddho Chakravarty 19 May '12

19 May '12

Hi all I am playing around with an experimental setup of a private Tor network and I am using the control protocol to setup custom circuits. Before establishing the custom circuits on the Tor client , I set the following options: __DisablePredictedCircuits:1 MaxOnionsPending : 1 newcircuitperiod : 999999999 maxcircuitdirtiness : 999999999 CircuitStreamTimeout : 999999999 CircuitIdleTimeout : 999999999 Thereafter, I turn off existing circuits on the client and establish my own circuit using nodes in my private Tor network. Then the client communicates to a server via this circuit. When the client-server communication ends, the circuit closes by itself. Thereafter, in sometime the corresponding OP-OR connections also close. Is there a way to keep the circuit and/or OP-OR connections alive long after the client-server communication has terminated ? Secondly, I don't see all TLS connections corresponding to the requested circuit in all the relays. Eg. I am using thee hosts -- A, B and C for the private network where, A runs two directory authorities and an OR, while B and C run only ORs. The Tor client of my setup establishes circuit through A, B and C using the above configuration parameters. 'getinfo' reports that the requested circuit has been established but I only see TLS connection betwen A and C..is there a reason why this is the case. Also, in my network, C has no exit policies, while A and B have 'reject *:*' exit policies (just to make sure that all TCP connections exit via C). Thanks Sambuddho

1 0

If you're using OpenSSL 1.0.1, upgrade to 1.0.1c
by Nick Mathewson 10 May '12

10 May '12

Hi, all! If you are using any version of openssl 1.0.1, 1.0.1a, or 1.0.1b, you should know that it's affected by a recent security advisory: https://www.openssl.org/news/secadv_20120510.txt If I am reading the diffs for this bug right, it looks like it would attacker to crash a server remotely. To avoid that, I'd recommend that all Tor nodes running any version of OpenSSL 1.0.1 should upgrade to 1.0.1c. Non-1.0.1 version of OpenSSL have this bug in their DTLS implementations, but Tor doesn't use DTLS. We'll try to get new packages out soon. yrs, -- Nick

1 0

Verizon Abuse Notice from Limited relay
by Michael Millspaugh 10 May '12

10 May '12

Hey all - I've been running a relay here for about 2-3 years now, with limited problems, especially since I switched to the more restrictive reduced exit policy (only allowing a few ports). However, I just received this today, which is new and alarming. I've replied with the boilerplate, but I'm worried as I've never heard from verizon since I went reduced, and they are the fastest and most reliable ISP (fiber to the home) in my part of the states. Here's the message, truncated: On 05-09-2011, your account was reported to have been used in an attempt to gain unauthorized access to another system, or to transmit malicious traffic to another Internet user. It is possible your system may have been infected by a virus or a botnet that is causing this action. Report and/or Logs: Timestamp: 2012-05-09 11:28:55 (GMT) Alert: COSED [CSG-GOP-009] SCAN Sqlmap SQL Injection Scan Source: 96.242.209.159 (49608) Destination: 200.189.113.50 (80) Content: LL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL--%20%20AND%20%27tysA%27%3D%27tysA& codigo=09590039044&orgcom=116100&serie=E000874295&tipo= DEFESA%20PREVIA&result=INDEFERIDO&motivo=015&auto=116100-E000874295 HTTP/1.1 Accept-Encoding: identity Accept-Language: en-us,en;q=0.5 Connection: close Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: sqlmap/1.0-dev (r4997) (http://www.sqlmap.org) Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 Host: celepar7.pr.gov.br Pragma: no-cache Cache-Control: no-cache,no-store -- TERMS OF USE. By reading this e-mail, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, terms-of-use, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

3 2

bridge usage summary in vidalia bridge bundle
by eliaz 10 May '12

10 May '12

When I installed Vidalia/Tor from vidalia-bridge-bundle-0.2.2.35-0.2.17, the Bridge Usage Summary the program never appeared. This turned out to be because by default the installed program points to geiop at AppData\Roaming\tor\ . This is incorrect, the file is in AppData\Local\Tor\ . Writing GeoIPFile C:\...\...\AppData\Local\Tor\geoip into torrc fixes this and now the Bridge Usage Summary appears. I don't know if this is just a glitch of my machine (Vista x 64) or if the code needs to be corrected, but I thought I'd report it. By default the bridge bundle places files in three separate folders in AppData\Local\ and Appdata\Roaming\ . Collecting these in one place would make it a bit easier for the user to reconfigure if necessary. - eliaz ---- gpg: 0xE498E90D

1 0

sustained bandwidth drop through noisetor
by Andy Isaacson 04 May '12

04 May '12

noisetor-01 was pushing 300-400 Mbps of traffic from 2012-02-15 through 2012-04-13. Since mid-April we've seen traffic decrease significantly; over the last week, our daily peak has been 260 Mbps (versus 450 Mbps in March) and our daily trough has been 100 Mbps (versus 300 Mbps in March). The traffic levels dropped off in a smooth fashion over a 10 day period, April 15-25 if I read the graphs correctly. There's no sign that anything is amiss on the node; CPU and memory usage are consistently lower, today, than they were in March -- as expected, given the lower utilization. The logs are silent. I've been postprocessing torstatus's Tor_query_EXPORT.csv regularly, and it appears that the overall exit throughput of the network has gone up slightly over the last few months; some new significant nodes came online during 2012Q1 and may have affected the traffic distribution. However, while noisetor has seen a significant drop, other families of exit nodes have seen their bandwidth go up or stay steady. Has there been a change in the routing algorithm, or any other network changes that might explain this drop? Thanks, -andy

3 3

Re: [tor-relays] [tor-dev] Can we stop sanitizing nicknames in bridge descriptors?
by Karsten Loesing 03 May '12

03 May '12

[Cc'ing tor-relays, because this discussion might be relevant for relay/bridge operators, too. Please keep the discussion on tor-dev. See https://lists.torproject.org/pipermail/tor-dev/2012-May/003489.html for the whole thread.] Hi Sebastian, On 5/2/12 9:35 PM, Sebastian G. <bastik.tor> wrote: > [...] > > Do similar names actually mean that bridges are located where the relay > is? (Apparently you've got the data to see these correlations) A fine question. How do we define "similar" and "located where the relay is?" I can see how a relay "bastik1" and a bridge "bastik2" have similar nicknames, but would we also teach a program that "bastikrelay" and "bastikbridge" are similar? And are two IP address in the same, say, /30 located nearby, or is the same /28 or even /24 okay, too? So, while we have the data to see these correlations, I think that whatever similarity algorithm we come up with, somebody else might come up with something smarter. If we do the analysis you suggest and learn that it's safe to include nicknames, that doesn't say very much. Only because we have the data to confirm how well our attack would works doesn't automatically mean we're in a good position to design the attack. If you want to run this analysis with the 2008 tarball (assuming there won't be general objections within the next two weeks), I'm happy to take your list of likely bridge IP addresses and tell you how accurate your algorithm is. > "We don't need it, so better remove it." I really like that. I think we're really conservative with giving out bridge data, and that's good. At the same time there's a value in giving out information about bridges, so that "remove everything" is not a good answer. For example, I think if we give bridge operators better feedback how their bridge is doing, we'll suddenly have a lot more bridges. Making it easy for bridge operators to use Atlas would be a good step into that direction. The same applies to funders who realize from our statistics how successful the Tor Cloud project is and who then want to fund it more to make it more usable, support more cloud providers, etc. >> And are we giving away anything else with the nicknames? > > Maybe it's location ;) > > As I read "hints on the location" for the first time; I though it would > mean that "TowerBridge" or "BridgeofLondon" would be bad since it could > hint to London. Well, in that case you'd learn that there's a (Tor) bridge in London. But that wouldn't help you very much, would it? > Could it make sense to ask the same question on the tor-relay list? Here > you (the Tor people) have more data again and know who subscribed to > both lists. I for myself assume that relay and bridge operators, which > could object, because it's their naming scheme that could reveal > something, are more likely to be subscribed to tor-relays. Good idea. I added tor-relays to the Cc to let relay/bridge operators know. Let's keep this discussion on tor-dev though. >> And if nobody >> screams, I'll provide the remaining tarballs containing original >> nicknames another two weeks later. > > Probably two weeks later, since unpacking, processing and re-packing > takes some time :) I know the sanitized ones are large when they are > unpacked. Windows needs some time to delete the extracted files. Right. :) I'll probably start sanitizing all bridge descriptors at once in two weeks, starting with the 2008 ones, and provide only the 2008 tarball then. It's going to keep my CPU and disks busy for a while. Thanks for your input! Best, Karsten

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays