- tor-relays - lists.torproject.org

Do bridges care about DNS?
by Steve Snyder 24 Jan '12

24 Jan '12

Do bridges have a need for name resolution, or it it just a matter of passing a packet from one IP address to another (i.e. from user to Tor node)? Thanks.

1 0

Re: [tor-relays] How can I tell if my bridge is working?
by Scott Bennett 22 Jan '12

22 Jan '12

On Sun, 22 Jan 2012 05:58:45 -0500 Roger Dingledine <arma(a)mit.edu> wrote: >On Thu, Jan 19, 2012 at 08:35:30PM -0500, Steve Snyder wrote: >> New operator of a Tor bridge here. How can I tell that it is being used? >> >> With a regular relay I can look up the stats on TorStatus, or I can see >> that there are n current connections. But a bridge won't be published, >> and the lower volume of traffic means that there may not be many active >> connections at any given time. >> >> So how do I know if it is working? I mean beyond the absence of any >> errors logged? > >Answer 1: absence of any errors logged. Then just trust. :) > >Answer 2: Use a Tor controller. Vidalia has a "who has used my bridge >lately?" button you can push to learn by-country statistics. Or try >'arm' if you prefer command-line controllers. > >Answer 3: We publish sanitized bridge descriptors on the metrics site: >https://metrics.torproject.org/data.html#bridgedesc >We're working on usable interfaces to let you look up the descriptor >for your bridge (including the usage statistics that it publishes). Stay >tuned. > Answer 4: this isn't exactly what you want, yet it still provides relevant information. Use the HeartbeatPeriod command in your torrc file to provide usage information on a periodic basis with your choice of period. The message logged gives the uptime in days and hours and a rounded figure for bytes sent and bytes received since initialization, so if your node is *only* used as a bridge, these messages will give you rough idea of your bridge's usage. Note, of course, that some of the traffic will be stuff that your node needs for its operation, e.g., a consensus file. Be advised that each period incurs about 1 s of delay in logging the information, so if you want information every hour exactly, for example, you need to specify a period of 3599 s, not 3600 s. Note, too, that the default period is 21,600 s, or 6 hr. Again, "HearbeatPeriod 21599 seconds" should yield a message logged every six hours exactly. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Tor Status graphs
by Geoff Down 22 Jan '12

22 Jan '12

Hi, the read/write graphs in my relay's TorStatus.blutmagie.de page have been broken for some time (flat-lined) but I assumed that was down to my old software. However, I see that all the relays' pages are the same. Is this data no longer available? I had a quick look in the archives for an answer. GD -- http://www.fastmail.fm - IMAP accessible web-mail

3 2

How can I tell if my bridge is working?
by Steve Snyder 22 Jan '12

22 Jan '12

New operator of a Tor bridge here. How can I tell that it is being used? With a regular relay I can look up the stats on TorStatus, or I can see that there are n current connections. But a bridge won't be published, and the lower volume of traffic means that there may not be many active connections at any given time. So how do I know if it is working? I mean beyond the absence of any errors logged? Thanks.

4 3

Re: [tor-relays] How can I tell if my bridge is working?
by robbie macg 21 Jan '12

21 Jan '12

Hi, I may have misunderstood the question. I think the simplest way to determine if your bridge is up and running correctly is to check the contents of /var/log/tor/log. Alternatively, try using Vidalia to connect to your own bridge. and log an error. These methods often work well for newer users. You may have something more sophisticated in mind or be trying to accomplish some thing else. If hat's the case, I apologize. Cheers, Robbie > Message: 1 > Date: Fri, 20 Jan 2012 09:17:16 -0500 > From: "cmeclax-sazri" <cmeclax-sazri(a)ixazon.dynip.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] How can I tell if my bridge is working? > Message-ID: <201201200917.16804.cmeclax-sazri(a)ixazon.dynip.com> > Content-Type: Text/Plain; charset="iso-8859-1" > > On Thursday, January 19, 2012 20:35:30 Steve Snyder wrote: >> New operator of a Tor bridge here. How can I tell that it is being used? > > Telnet to port 9051 and type ?authenticate "blurdyboop"?. Then type > ?setevents > bw? and it'll tell you how many bytes go in and out. I'm not sure how to > tell > that there are client connections, but it's probably another setevents > command. > > cmeclax > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 12, Issue 19 > ****************************************** >

1 0

Tor Deprecation Notice
by Damian Johnson 20 Jan '12

20 Jan '12

Hi all. As per ticket 4788 [1] we'll soon be removing relays that are out of date and no longer safe to run, which includes anything older than version 0.2.1.30. When I last checked this included 257 relays [2] and I've already notified the 107 of those that had contact information available. If you're running one of those relays then you'll need to upgrade to keep operating. Sorry about the inconvenience and thanks for running a relay! -Damian [1] https://trac.torproject.org/projects/tor/ticket/4788 [2] https://trac.torproject.org/projects/tor/attachment/ticket/4788/old_relays.…

3 2

[warn] Request too large from address '[scrubbed]' to DirPort. Closing.
by Klaus Layer 19 Jan '12

19 Jan '12

Hi, last night the log of one of my nodes showed within 2 minutes about 160 of these messages. Traffic stats show that the incoming bandwidth increased from the average of 300 Mbit/s to more than 400 Mbit/s, where at the same time outgoing traffic dropped. From the peak I see, the requests must have been really big. Does anyone noticed this on other tor servers too? Regards, Klaus

3 2

Re: [tor-relays] logging failure in 0.2.3.10-alpha
by Scott Bennett 19 Jan '12

19 Jan '12

On Thu, 19 Jan 2012 09:39:55 -0800 (PST) CyberRax <cyberrax(a)yahoo.com> wrote: >----- Original Message ----- > >> From: Scott Bennett <bennett(a)cs.niu.edu> >> =A0 =A0 I delayed moving from 0.2.3.7-alpha to 0.2.3.10-alpha until now = >[...] >>=A0=A0=A0=A0 ...no log files were created > >2 thoughts: >a) does the user have access to the logging folder? (_tor rather than root) >b) if you're building through FreeBSD's ports system then the installed /us= >r/local/etc/rc.d/tor gives the log filename from commandline which, >=A0=A0 if I understand correctly, overrides the settings given in torrc (th= >at change was made in 0.2.3.9 or so) *Very* good clue! Thank you very much! Several years ago, I did install a version of tor via the ports tree, but soon switched to building it myself due to delays in new versions being incorporated into the ports and a concern over potentially losing key files, torrc, etc. if I needed to remove it temporarily or during updates. However, I left the infrastructure stuff (e.g., the /usr/local/etc/rc.d/tor script and the /var/db/tor and /var/log/tor directories) in place. The version information line in it still says, # $FreeBSD: ports/security/tor/files/tor.in,v 1.2 2006/08/06 12:26:25 arved Exp $ :-) Anyway, I deleted the --log option from the line that starts/stops tor, and it created both log files this time when I started it. The original script specified /var/log/tor as a log file, so I must have long ago changed it to a directory to hold more than one log file and then forgotten I had done that. /var/log is a directory only writeable by root anyway, and /var/log/tor is a directory only writeable by _tor, so tor would not have been able to create a file called /var/log/tor. Thanks again for the pointer! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

https://metrics.torproject.org/networkstatus.html
by Sebastian Urbach 19 Jan '12

19 Jan '12

Hi, Im receiving the following error since a few days: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /networkstatus.html. Reason: Error reading from remote server Apache Server at metrics.torproject.org Port 443 Url: https://metrics.torproject.org/networkstatus.html Anyone out there to fix it ;-) ? -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

2 1

logging failure in 0.2.3.10-alpha
by Scott Bennett 19 Jan '12

19 Jan '12

I delayed moving from 0.2.3.7-alpha to 0.2.3.10-alpha until now because the latter failed to build from source under FreeBSD 7.4-STABLE. Oddly enough, now that I've upgraded to 8.2-STABLE, it appears to build just fine. So I ran a tor --verify-config on my existing torrc file, which was confirmed to be okay by 0.2.3.10-alpha. Next, I fired it up, and...no log files were created, :-( so I had no idea whether it was working, had encountered any difficulties during initialization, etc. It should have created two log files in /var/log/tor/, one for "notice" and above, and one for "info" and above. I tried a SIGHUP to get it to reread torrc, which made no observable change, as expected. After pondering the situation for a few minutes, I decided to shut it down. If tor can't communicate to its operator, then it can't be safely run. If anyone can feed me a clue about what to try in hopes of fixing this, I'd greatly appreciate it. If there are no helpful ideas forthcoming by this evening, I'll likely go back to 0.2.3.7-alpha in order to have a working node. Thanks much. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Metrics / Router Details
by Sebastian Urbach 14 Jan '12

14 Jan '12

Hi, Im receiving the following error message when i try to view my router details on metrics: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /routerdetail.html. Reason: Error reading from remote server Url for this message is: https://metrics.torproject.org/routerdetail.html?fingerprint=0aff5440ae93f2… -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

2 1

Authorities: what is up?
by Klaus Layer 13 Jan '12

13 Jan '12

Hi, just because I am curious: can someone from the tor authority operators please explain what is going on the last days with tor authorities. This morning (europe) ides is not available. Thanks, Klaus

4 9

Re: [tor-relays] Authorities: what is up?
by Sebastian Hahn 13 Jan '12

13 Jan '12

On Jan 13, 2012, at 1:27 PM, Nils Vogels wrote: > Hey Sebastian, Roger, > On 13/01/2012, Sebastian Hahn <mail(a)sebastianhahn.net> wrote: >> >> Ah, I see. ides not having a current consensus is different from ides >> being down. Ides still is running the stable Tor version and needs to be >> upgraded to 0.2.3.x to be allowed to vote along with the other dirauths, >> so it doesn't immediately know about the new consensus. I don't know >> when ides will be upgraded, but I hope the answer is soon. > > Let me know if there is a need for stable authorities with speedy > admins. I'm sure the Dutch hacker community (which I am very much > involved with) can lend a hand and/or a high-bw host. Hi Nils, I'm pasting some stuff here from the "consensus update request" thread, also on tor-relays: On Jan 8, 2012, at 5:45 PM, Roger Dingledine wrote: > On Sun, Jan 08, 2012 at 03:35:16PM +0100, Sebastian Hahn wrote: >> The problem is that in the current situation, it gets worse with more >> authorities, not better. Our voting mechanism needs an overhaul :/ > > Indeed. > > The other problem is that we simply have too many clients out there. > And we've taught them all to be eager to keep updated, so they're harder > to partition. But it's really a volume thing at this point. We need a more > scalable way of keeping clients informed about network topology. In our > copious free time, while also doing everything else that needs doing. :/ > > Anyway, crisis averted, this time. > > --Roger Hope that helps make it clearer why adding a new authority in the short term doesn't actually help us currently. Thanks Sebastian

1 0

tor died with "invalid opcode", should I be worried?
by Marinos Yannikos 13 Jan '12

13 Jan '12

Using Tor 0.2.2.35 (git-4f42b0a93422f70e), OpenSSL 0.9.8o: Jan 12 21:17:25 XXXXXXX kernel: [ 4257.857564] tor[1909] trap invalid opcode ip:7fa7dd61f8f7 sp:7fa7daf80400 error:0 in libcrypto.so.0.9.8[7fa7dd574000+175000] I don't have a core dump unfortunately. This box has had some stability issues lately (still unknown if hardware or DoS attacks are to blame), but I'm a bit worried about a possible exploit attempt. Has anyone else observed such Tor crashes recently? OpenSSL 0.9.8o has a few vulnerabilities according to http://www.openssl.org/news/ but this is Debian Stable *sigh* ... Regards, Marinos

2 1

Anyone else getting these? - Fwd: Tor Survey
by Tor Relays at brwyatt.net 12 Jan '12

12 Jan '12

I just got this sent to me, not sure if it is legit or not. I'm going to assume the worst for now, thought I'd send it out here for discussion and as a heads up for anyone who hasn't yet gotten one of these. I'm hesitant to run anything from someone wanting to do a "study" on Tor Relays. Message forwarded below. -------- Original Message -------- Subject: Tor Survey Date: Wed, 11 Jan 2012 11:47:35 +0100 (CET) From: Marco Valerio Barbera <barbera(a)dsi.uniroma1.it> To: tor(a)brwyatt.net Dear Tor Relay Administrator, my name is Marco Valerio Barbera, I am a PhD student in Computer Science at La Sapienza University of Rome and I am currently doing a research study on the security of the Tor Network in collaboration with Angelos Keromytis, head of the Network Security Lab at Columbia University. You are receiving this message because your e-mail address is associated to the Tor Relay(s) with nickname(s) and address(es): brwyatt1 96.226.232.75 It has recently been discovered a new DoS attack that could allow an adversary to stop one or more Tor Relays from participating and providing service to the Tor Network. This kind of attack poses a potential threat to the hundreds of thousands of users around the globe that use Tor every day. For instance, an adversary may be able to shut down a substantial part of the Tor Network, forcing users to surf the web in a traceable way. In an even worse scenario, an adversary may attract a big part of the data flowing through the Tor Network to one or more malicious Tor Relays that could, thus, cooperate in deanonymizing Tor traffic without being noticed by the users. The aim of our study is that of evaluating the amount of resources an adversary would need to perform such an attack and what would be the actual damage that the Tor Network would suffer. At the same time, we are working on a patch to be applied to the Tor software that could mitigate this issue. The reason you are receiving this message is that, to improve our study, we require some extra information about the Relay(s) you are running that, unfortunately, is not publicly available. We would therefore like to ask a very little, but precious, help from your side in collecting this information and sharing it with us. Note that the information we need is *not* related in any way with the traffic that you are relaying in this moment or have relayed in the past, thus it cannot be directly used to affect the privacy of the Tor users. What we are interested in is related to the hardware characteristics (e.g., number of physical CPUs, amount of memory) and with some of the configuration parameters of your Tor Relay (e.g., number of processors the Tor Relay can use, bandwidth limit). In the case you agree to help us, collecting this information won't steal much of your precious time. In order to make it easier for you to get it, you will find on the website linked at the end of this message a small shell script that you can run on the Tor Relay(s) themselves or, if possible, on another machine with the *same* hardware specs. The script doesn't need any special (i.e., root) permission to run, it won't download anything from the network, nor it will install any software on your machine. We also commented it so as to make it easier for you to understand it in case you wanted to check what is the exact sequence of operations it will perform and information it will collect. Any data saved by the shell script will be available in a human readable text format stored in an output directory you will specify. We encourage you to use the public key you will find on the bottom of this message to encrypt the data collected by the script before sending it to us. You ca n get the same public key on the website linked at the end of this message. We would like to assure you that we will take extraordinary care in protecting in the best way we can the privacy of any information you will decide to share with us. We want also to assure you that, in the event it will be published, any data you will provide us will be carefully anonymized and given only in terms of aggregated statistics. Together with the script, you will find a README file containing detailed instructions on how to use it and how to encrypt the results before sending them to us. We thank you for your kind attention. Best regards, Marco Valerio Barbera You can find the script and the public key in any of these locations: https://sites.google.com/site/marcobarbera/tor-survey http://www.dsi.uniroma1.it/~barbera/tor-survey.html -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (Darwin) mQENBE8Fo8gBCADEwO0RNlXfTovI+LLGH8qGyRcDHycFc12URCZdol46sTPnNcrE 2w+KuIK841+QJt40tYBtE9/BT8CerQEGrEteiTIAClpltJcE+6Z04+bbS6EmDzb7 WzpxF0Tv9UrGhGCBncGvFnFbxaJQBu+5KrhJJTrW++778WTqMHoXvEw2LA9QHQB5 qaAgZbvi+2JHrXEB0Cp/OTtGXLz8uej/liifYNh8bYCYIpU8fe+7Q+1ktyPk75g3 1/bTgfywujIVxXoZyo2usSdEZ7KmrISA4E8TlCQwidK8dFEPNwREfcyVNfgrxXyS TpMj/41KWOfymBuR+x0gfpP7eUlzUoObFkaPABEBAAG0L01hcmNvIFZhbGVyaW8g QmFyYmVyYSA8YmFyYmVyYUBkc2kudW5pcm9tYTEuaXQ+iQE4BBMBAgAiBQJPBaPI AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAUhbbzQCoISDOaCACCtPjq o041Z6urq8SVrlK/I659C1fbRUPVi+DJSEP3yZWIDxgwxDGopgabB/NFMwULiKOv 9WNHWydxrxsFYA/+lwbr9YxbV8ShME/pzhR6K+kbT7AGSmBOefgVfCJywh7JcGb4 kp59KKmX7EnHYEkir3HK3wX34ScPbttge1bTQfQF4bKvGcUbqStIn/rL5mGNfbeR IFUidMF6aa1CcPIvkqD2Gs7rv9hAXFVG7/3TjrrzIAsFdXhU6UIM45jwdUnsbLiD Jz96Qz4HLa9wNU7nuSDAqzz+t15O/Fffg55pcUB1MpFIAhVqLffGfAoGrihAylPU aZIqc9ZJk2nr96KLuQENBE8Fo8gBCADs+hN+b/fir4mlxr9EqycYYvieuwiGWttt ocpWuhk/MxCzCRUA2/0GWdqtgFnmygWAh6HBv0XOZS04n83XGkKMEtoSfR4KXc8m xhtYkeSxH0FUuLE6/R9kHYcE7Eg4Jt0RO+aiCSoY4VDK7n4SpqWKoSVNYXKoYr2L zoXQ/PGJ/7RH9RAzKZDdQ5sgKLbpXiwib8mkWYbtPhNIbW4mF5QNSG+705L0yGh4 2keiPQFRAvc8hnkcKx6OVpmxdYEVTJT1t+ViYptDhtYc8axAB2z2ZBVyeeam3AZ0 3aJcG7PbQB/dmDPAKwULEsPoNWXEDKwZP6LbGo0tTAcklAB+RBOvABEBAAGJAR8E GAECAAkFAk8Fo8gCGwwACgkQFIW280AqCEg6UQgAwqd2TMzE01KWiafP7uIyk92l hgVEahFPulJyeWCpbqzA+4fYtC1rT+kuoDbyHbzbkQZJEHIjGcDlPHpb1zbB7iQy 6HyKhxRQXVcGCgWbsycYbLM+lwXbOn6LFqq6I+wBaMvOpPFNipxenJfjIlXdZyjA DSxI7SNvm+AMSfmVC0SJuTmxZGLdu8NxUohsqf6tpfspM341yQQZ2kUPGcwx/Y4d wvei2cbtTf2jSpU+y6Bara9c7JPjPq8pNsakrFneF/4l2T3cLVI5B95SXY5XTaTI G1VNfyebQCPUS0kKvpbHGxFl+B2STFjMMRbCpiqH3jFhBOcIrBulXhqTz5oLcg== =OsQy -----END PGP PUBLIC KEY BLOCK----- --- NOTICE This is an autonomous study, not supported neither directly nor indirectly by the Tor Project Inc. The Tor Project Inc. is not responsible for any content of this message.

3 2

Out of the mailing list
by Bruno Kitzis 10 Jan '12

10 Jan '12

Hello, I don't want to receive the TOR-mail anymore. Thank you. Best regards.

2 1

Re: [tor-relays] tor-relays Digest, Vol 12, Issue 9
by Jeffrey Ye 10 Jan '12

10 Jan '12

> From: tor-relays-request(a)lists.torproject.org > Subject: tor-relays Digest, Vol 12, Issue 9 > To: tor-relays(a)lists.torproject.org > Date: Tue, 10 Jan 2012 12:00:02 +0000 > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: consensus update request (grarpamp) > 2. Re: not specified families (Aurel W.) > 3. Re: not specified families (Tor Relays at brwyatt.net) > 4. Re: not specified families (Damian Johnson) > 5. New authority (Sebastian Urbach) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 9 Jan 2012 17:45:51 -0500 > From: grarpamp <grarpamp(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] consensus update request > Message-ID: > <CAD2Ti2-Ti1qv4Pb22JsKmpZXMTWPhSPwGyyLtkewYo5Z-U-rJA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Maybe this is why my client is taking so long to load > at the moment. At first I thought it was my update to > ossl 100f, but after checking 100e again, it's not. Tor > currently sits in the netstatus consensus and missing > dir auth phases for indefinite tens of minutes before > coming online. > > valid-until 2012-01-09 20:00:00 > Mon Jan 9 22:..:.. UTC 2012 > > Is this something that's distributable as a piecemeal > flood into the net as each router is validated. Some > sort of client held table so the scale work and > partitioning is done there with their cpu/disk. > > > ------------------------------ > > Message: 2 > Date: Tue, 10 Jan 2012 00:28:16 +0100 > From: "Aurel W." <aurel.w(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] not specified families > Message-ID: > <CAAG-S2FCxKctVtpPj08Gpkyt5b6hvqO+T2EzauBfUMk=iZv59A(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > Malicious relays trying to de-anonimize people are not going to use > > MyFamily for obvious reasons, and also they will not choose an obvious > > nick sequence like MetallicaFan1, MetallicaFan2,etc > > So it seems to me this option has only theoretical benefit, but in > > practice it's naive. > True, but in theory you also have to consider that nodes could get > compromised and then it is very likely that a whole family is affected > (may be too paranoid for some). > > I also wonder if it gets harder to identify a real threat, of a > malicious attacker operating many nodes, if there are so many other > cases of not-specified families. > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > because no one with a malicious attempt would name nodes like that. > But they are an indication, that there might be a bunch of other > nodes, without any such strong sings, but which are also operated by > one single individual. Because obviously, it's a very common mistake > in configuration. > > There might be feasible techniques to find suspicious groups of > relays, but with all this non specified families, this would be rather > pointless. > > aurel > > aurel > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: > > On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: > >> Shouldn't this be treated more seriously? There are literally over 100 > >> high bandwidth relays, which should specify a family but which don't. > >> If you monitor a client, it is very frequently that circuits are built > >> where two relays are clearly controlled by the same person. > >> > >> As a first try I mailed to two contact email addresses, but I haven't > >> got any response. > > > > In the end its the same. Relay operators who are willing to place > > MyFamily in their torrc file are not the ones that are going to try to > > identify you. > > Malicious relays trying to de-anonimize people are not going to use > > MyFamily for obvious reasons, and also they will not choose an obvious > > nick sequence like MetallicaFan1, MetallicaFan2,etc > > So it seems to me this option has only theoretical benefit, but in > > practice it's naive. > > Or maybe I'm missing something > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > Message: 3 > Date: Tue, 10 Jan 2012 01:21:20 +0000 > From: "Tor Relays at brwyatt.net" <tor(a)brwyatt.net> > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] not specified families > Message-ID: <802693728989435(a)jngomktg.net> > Content-Type: text/plain; charset=UTF-8 > > Wouldn't it be possible to code the Tor clients to not build circuits > using relays in the same /24 or with "similar" names? While that wouldn't > fix ALL possible attack scenarios, that could certainly help, and help > against accidental (or malicious) misconfigured nodes. > > On Tue, 10 Jan 2012 00:28:16 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: > >> Malicious relays trying to de-anonimize people are not going to use > >> MyFamily for obvious reasons, and also they will not choose an obvious > >> nick sequence like MetallicaFan1, MetallicaFan2,etc > >> So it seems to me this option has only theoretical benefit, but in > >> practice it's naive. > > True, but in theory you also have to consider that nodes could get > > compromised and then it is very likely that a whole family is affected > > (may be too paranoid for some). > > > > I also wonder if it gets harder to identify a real threat, of a > > malicious attacker operating many nodes, if there are so many other > > cases of not-specified families. > > > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > > because no one with a malicious attempt would name nodes like that. > > But they are an indication, that there might be a bunch of other > > nodes, without any such strong sings, but which are also operated by > > one single individual. Because obviously, it's a very common mistake > > in configuration. > > > > There might be feasible techniques to find suspicious groups of > > relays, but with all this non specified families, this would be rather > > pointless. > > > > aurel > > > > aurel > > > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: > >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: > >>> Shouldn't this be treated more seriously? There are literally over 100 > >>> high bandwidth relays, which should specify a family but which don't. > >>> If you monitor a client, it is very frequently that circuits are built > >>> where two relays are clearly controlled by the same person. > >>> > >>> As a first try I mailed to two contact email addresses, but I haven't > >>> got any response. > >> > >> In the end its the same. Relay operators who are willing to place > >> MyFamily in their torrc file are not the ones that are going to try to > >> identify you. > >> Malicious relays trying to de-anonimize people are not going to use > >> MyFamily for obvious reasons, and also they will not choose an obvious > >> nick sequence like MetallicaFan1, MetallicaFan2,etc > >> So it seems to me this option has only theoretical benefit, but in > >> practice it's naive. > >> Or maybe I'm missing something > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > ------------------------------ > > Message: 4 > Date: Mon, 9 Jan 2012 18:00:59 -0800 > From: Damian Johnson <atagar1(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] not specified families > Message-ID: > <CAJdkzEOp711+5EOscFguTbS3DUDdVi3tEaPOOD3UbUGXtKhihw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > Wouldn't it be possible to code the Tor clients to not build circuits > > using relays in the same /24 or with "similar" names? > > Tor already avoids using multiple relays in a given /16 subnet. > https://gitweb.torproject.org/torspec.git/blob/HEAD:/path-spec.txt#l184 > > > ------------------------------ > > Message: 5 > Date: Tue, 10 Jan 2012 05:04:42 +0100 > From: Sebastian Urbach <sebastian(a)urbach.org> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] New authority > Message-ID: <20120110040444.AC7731006006A(a)ccc-hanau.de> > Content-Type: text/plain; charset="iso-8859-15" > > Hi, > > freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 > > May someone add the data to the add_default_trusted_dirservers() > function in config.c, using the syntax "v3ident=<fingerprint>". > > Thanks. > > Btw. i respond pretty fast to server / network issues ;-) > > -- > Mit freundlichen Gr??en / Yours sincerely > > Sebastian Urbach > > -------------------------------------------------------- > Religion is something left over from the infancy of > our intelligence, it will fade away as we adopt > reason and science as our guidelines. > -------------------------------------------------------- > > Bertrand Arthur William Russell (1872-1970), > British philosopher, logician, mathematician, > historian, and social critic. >

1 0

Authority sigs needed
by Sebastian Urbach 10 Jan '12

10 Jan '12

Hi all, Could all authority admins on this list please consider signing my new installed authority system. Just got 1 sig and i need at least 4 more to help with the service. Fingerprint. freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 Thanks in advance. -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

2 1

New authority
by Sebastian Urbach 10 Jan '12

10 Jan '12

Hi, freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 May someone add the data to the add_default_trusted_dirservers() function in config.c, using the syntax "v3ident=<fingerprint>". Thanks. Btw. i respond pretty fast to server / network issues ;-) -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

1 0

Re: [tor-relays] not specified families
by Tor Relays at brwyatt.net 10 Jan '12

10 Jan '12

Wouldn't it be possible to code the Tor clients to not build circuits using relays in the same /24 or with "similar" names? While that wouldn't fix ALL possible attack scenarios, that could certainly help, and help against accidental (or malicious) misconfigured nodes. On Tue, 10 Jan 2012 00:28:16 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: >> Malicious relays trying to de-anonimize people are not going to use >> MyFamily for obvious reasons, and also they will not choose an obvious >> nick sequence like MetallicaFan1, MetallicaFan2,etc >> So it seems to me this option has only theoretical benefit, but in >> practice it's naive. > True, but in theory you also have to consider that nodes could get > compromised and then it is very likely that a whole family is affected > (may be too paranoid for some). > > I also wonder if it gets harder to identify a real threat, of a > malicious attacker operating many nodes, if there are so many other > cases of not-specified families. > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > because no one with a malicious attempt would name nodes like that. > But they are an indication, that there might be a bunch of other > nodes, without any such strong sings, but which are also operated by > one single individual. Because obviously, it's a very common mistake > in configuration. > > There might be feasible techniques to find suspicious groups of > relays, but with all this non specified families, this would be rather > pointless. > > aurel > > aurel > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: >>> Shouldn't this be treated more seriously? There are literally over 100 >>> high bandwidth relays, which should specify a family but which don't. >>> If you monitor a client, it is very frequently that circuits are built >>> where two relays are clearly controlled by the same person. >>> >>> As a first try I mailed to two contact email addresses, but I haven't >>> got any response. >> >> In the end its the same. Relay operators who are willing to place >> MyFamily in their torrc file are not the ones that are going to try to >> identify you. >> Malicious relays trying to de-anonimize people are not going to use >> MyFamily for obvious reasons, and also they will not choose an obvious >> nick sequence like MetallicaFan1, MetallicaFan2,etc >> So it seems to me this option has only theoretical benefit, but in >> practice it's naive. >> Or maybe I'm missing something >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] not specified families
by Tor Relays at brwyatt.net 10 Jan '12

10 Jan '12

Probably just misconfigured. If there are emails attached to the nodes you could try mailing them directly about it. brwyatt On Fri, 6 Jan 2012 01:29:42 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: > Hi, > > when I browse through the list of relays I find many router names, > which correlate in some way, but which don't specify a family in their > descriptors. > > Just to name a few: > * 2* c5VycfOP > * 3* c516a > * Caldron, Caldron2, Caldron3 > * BlgTOR2, BlgTOR > * DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey > * DONATIONxTORx0 - DONATIONxTORx7 > and so on,... > > is there a reason, why there is such a high number of relays, which > fail to specify a family, since this seams rather striking? > > aurel > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 7

Re: [tor-relays] consensus update request
by Scott Bennett 09 Jan '12

09 Jan '12

Thanks, Sebastian, for the very quick reply. On Sun, 8 Jan 2012 15:12:25 +0100 Sebastian Hahn <mail(a)sebastianhahn.net> wrote: >On Jan 8, 2012, at 3:09 PM, Scott Bennett wrote: > >> The last consensus document expired about 15 hours ago. I understand >> that the authority operators and tor developers are probably occupied with >> fixing whatever is the trouble, but if someone in that group of individuals >> can spare a moment to fill us in on what is happening, I, for one, would >> greatly appreciate it. >> FWIW, I think a page on the torproject.org web site for very brief >> status updates on extraordinary situations like this one would be a good >> and helpful addition. >> Thanks much, and best of luck getting things working right again. > >People are indeed working to restore service. Currently it looks like Glad to know that. >two authorities are completely offline, and a couple others are too >overloaded to function properly wrt voting. Hmm. Will this situation, then, result in a renewed effort to find a few more people to run authorities? > >In the meantime you might like >https://metrics.torproject.org/consensus-health.html which monitors the >consensus. Thanks for that, too. It's not what I had in mind, but it is interesting, nonetheless. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

5 4

Internal server error while fetching from dizum
by Klaus Layer 09 Jan '12

09 Jan '12

Hi, my relays are getting 500 error while fetching data from authority dizum. Can someone explain what is happening with this tor authority? Regards, Klaus 14:25:51 [WARN] Received http status code 500 ("Internal Server Error") from server '194.109.206.212:80' while fetching "/tor/server/d/C539CB98343680892C46D0A70770E6D0A4A39564+E5A7994519731C2C3349AAA4C2A38CED2CE74457+E8507D31268490E9E4E8A2110E371F1537156C75+E8BCD670FFB8ADF73195BDB9362ACDDB28F704A5+E94B92087B4614CB7F1C9CC1191C383- 7D890C60E+EA71B375FC45F026C854C903887D981CF19B7326+EA9DE146A13B316D2F3D5C2ACF491C068B93FF9D+EB896E11C16C0531D83560D3CBBEF97AF2FFF4D5+ECEBAAF01CA177EEB68A8A6838E4A16- BD54749F6+ED5A60237FDCA188DF30DC380536754DFBF01404.z". I'll try again soon.

2 3

consensus update request
by Scott Bennett 08 Jan '12

08 Jan '12

The last consensus document expired about 15 hours ago. I understand that the authority operators and tor developers are probably occupied with fixing whatever is the trouble, but if someone in that group of individuals can spare a moment to fill us in on what is happening, I, for one, would greatly appreciate it. FWIW, I think a page on the torproject.org web site for very brief status updates on extraordinary situations like this one would be a good and helpful addition. Thanks much, and best of luck getting things working right again. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Relay vs. bridge: difference in traffic?
by Steve Snyder 06 Jan '12

06 Jan '12

Can someone tell how being a bridge compares to being a regular exit node in terms of traffic? I can see how there would less traffic as a bridge since the node isn't advertised. On the other hand, there are many fewer bridges than regulat nodes so maybe the traffic on a given bridge is greater? Thanks.

2 1

not specified families
by Aurel W. 06 Jan '12

06 Jan '12

Hi, when I browse through the list of relays I find many router names, which correlate in some way, but which don't specify a family in their descriptors. Just to name a few: * 2* c5VycfOP * 3* c516a * Caldron, Caldron2, Caldron3 * BlgTOR2, BlgTOR * DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey * DONATIONxTORx0 - DONATIONxTORx7 and so on,... is there a reason, why there is such a high number of relays, which fail to specify a family, since this seams rather striking? aurel

2 1

relaytorkiri
by Nick Walke 03 Jan '12

03 Jan '12

I'm showing that tor is currently using 12 - 14 Mbps on my relay, however, the status page for my relay ( http://torstatus.blutmagie.de/router_detail.php?FP=192bdf2831c1b007a08dc3c1… ) does not reflect this speed. Is there a reason for this? Nick

4 7

Received botnet/drone abuse complaint
by Steve Snyder 03 Jan '12

03 Jan '12

I received a botnet/drone complaint from shadowserver.org today (delayed due to holidays) regarding my exit node: timestamp ip port type infection cc cc_port 12/29/2011 19:52 173.208.132.210 48586 32097 US MISSOURI KANSAS CITY tcp mebroot ukixxuug.com|MAOS/0EC20201 14DF137A55320641 84.163.151.128 80 3320 DE 1 If I'm reading this correctly, they identify "mebroot" as the source of the problem. As this is a Windows MBR trojan it obviously doesn't apply to my Linux system. I scanned my system anyway and found no unexpected processes running. My DirPort is set to 80, which may explain that value in the complaint. Any thoughts on what to do to avoid further complaints? Shadowserver addresses the topic of Tor exits here: http://www.shadowserver.org/wiki/pmwiki.php/Involve/TORNodesAndReporting Thanks.

2 1

planned downtime
by cmeclax-sazri 02 Jan '12

02 Jan '12

Sometime this week (I haven't decided when yet) I'll be down for a few hours to upgrade memory. cmeclax

4 3

Abuse complaints about brute forceing via ssh
by Klaus Layer 02 Jan '12

02 Jan '12

Hi, within two days I received abuse complaints from my ISP that someone used my exit node to brute force ssh accounts of two different ISP. Unfortunately I am forced to block port 22 to avoid shutdown. Anyone else who suffered from such attacks these days? Regards, Klaus

7 8

unplanned outage
by cmeclax-sazri 27 Dec '11

27 Dec '11

I have been off line since noon (17 UTC) Friday when a man with a backhoe cut the thicknet cable that connects me to the Internet. The repairmen just came and patched the cable and I am on line again. cmeclax

2 2

Bandwidth Authority PID Feedback Experiment #2 Starting
by Mike Perry 22 Dec '11

22 Dec '11

Over Thanksgiving and into early this week, we ran an experiment to test a feedback mechanism to attempt to allocate usage of the Tor network such that the measured stream capacities through all relays became equal: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… This experiment failed in 3 ways: 1. It drove many relays down to 0 utilization. Scott Bennett noted this in his post to tor-relays, and at least one 10Mbit relay operator also commented on the traffic drop-off of their node in #tor. 2. It only created one PID 'setpoint' for the entire network, even though different types of nodes see different load characteristics, and despite it being impossible to shift load from an Exit node to a Middle node, for example. 3. It kept allocating bandwidth to some relays (especially Middle and non-default-policy Exits) until they hit INT32_MAX in the consensus, and everything finally exploded. We then shut off the feedback by removing the consensus parameters. I've made five major changes to try to address these issues: 1. Don't perform multiple rounds of negative feedback for slow nodes. 2. We now group nodes by their flags into four categories (Guard, Middle, Exit, and Guard+Exit), and compute a different PID setpoint for each class. 2. Circuit failure now counts more. Circuit failure is our CPU overload signal, as nodes that hit CPU overload being dropping onionskins and failing extends. Instead of using the circuit success rate as a multiplier against the pid_error, we now actually compute a circ_error similar to the pid_error, and use it as the pid_error if it is more negative. We also now set FastFirstHopPK 0 to ensure that Guard nodes also get tested for circuit failure. 3. Raised the PID setpoint slightly, which should prevent us from piling quite so much weight onto fast relays. 5. Cap feedback via a consensus parameter. All of these changes are governed by consensus parameters. See: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… for more details. The parameters governing feedback are bwauthnsbw=1 and bwauthti. So long as one or both of these are present and non-zero in the consensus parameter list, the feedback experiment is active. We'll probably be running this next experiment for about a week (or perhaps longer if it doesn't explode and seems to improve performance on https://metrics.torproject.org/performance.html) starting tonight or tomorrow. Please keep an eye on your relays and tell us if anything unexpected happens over the next week or so. Thanks! -- Mike Perry

8 26

arm client locale stats on connection page
by Klaus Layer 20 Dec '11

20 Dec '11

Hi, I am using arm to monitor 3 tor nodes running on the same box. On the connection page I get very different results when pressing "c" to get the client locale stats: Node A - nothing happens Node B - the window with the client locale stats is displayed Node C - a message "Usage stats aren't available yet, press any key..." is displayed Under which conditions are the stats available? Regards, Klaus

2 2

bandwidth authority test
by Softail 12 Dec '11

12 Dec '11

I'm also running a guard relay that for some months was pushing 600kBs pretty steadily. In the last couple weeks it's lower and very variable and today it has basically cratered. Is this a likely results of the bandwidth algorithm testing that's going on or might I have other problems? Thanks, Wayne -- A man in chains knows he should have acted sooner... Julian Assange

1 0

ARM crashes on connection tor
by Klaus Layer 10 Dec '11

10 Dec '11

Hi, I am no longer able to connect with ARM to one of my relays. ARM crashes with the following error: debian-tor@host:/home/user$ arm -i 127.0.0.1:4711 Traceback (most recent call last): File "/usr/share/arm/TorCtl/TorCtl.py", line 710, in _loop isEvent, reply = self._read_reply() File "/usr/share/arm/TorCtl/TorCtl.py", line 885, in _read_reply raise ProtocolError("Badly formatted reply line: unknown type %r"%tp) ProtocolError: Badly formatted reply line: unknown type 'P' Terminated To another instance running on the same machine ARM connects without any problem. Has anyone experienced the same issue or knows how to fix it? Thanks, Klaus

3 3

Logs full of "eventdns: All nameservers have failed"
by Klaus Layer 10 Dec '11

10 Dec '11

Hi, my logs are full of these messages: 05:54:07 [NOTICE] eventdns: Nameserver 127.0.0.1 is back up 05:54:07 [WARN] eventdns: All nameservers have failed At first I thought that the DNS of my ISP sucks, so I changed to Google Public DNS. But the warnings are still there. Google shows some older reports of this warning, where is was supposed to be an error in tor. Are there any news on this? I am wondering if the high bandwidth nodes from torservers and noisebridge also show this kind of messages and how they configured their nodes to get rid of it. For my node they come up every couple of minutes. Between fail and recover is always less than a second. Best regards, Klaus

5 11

Significant relay usage drop down
by Klaus Layer 09 Dec '11

09 Dec '11

Hi, I am running two relays with the fingerprints D223399907113A1F216AAA64997BC1D4CFA8E1AC and 945CBBA599808018749DDC4EBB592168F2858C1B. For the first relay I am observing a significant usage drop down during the last 12 hours. The second runs as usual with a high throughput. I am wondering what the reason for this drop down could be. Are there any changes in the configuration of authorities? Is someone from the core TOR developers doing tests with the load distribution? Best regards, Klaus

3 3

ISP thinks a relay is under attack from other relays
by Daniel Bryg 07 Dec '11

07 Dec '11

Hi, This is mostly just an interesting anecdote but there are also a few questions. Hetzner informed us (see below) about an attack on our relay (not an exit). It looks like it's just normal traffic from other relays so all is good, but the switch sees incoming activity almost 3x higher than what comes in on the server's interface (90Mbit/s, 13k packets/s). If most of packets are dropped, it must affect the performance of Tor connections. Is this because the Tor network is overwhelmed with traffic and are all relays subject to much higher requested traffic than their limits? Thanks, Daniel. Direction IN Threshold Traffic 200 MBit/s Sum 8,828 GByte/300s (241 MBit/s), 9.436.000 packets/300s (31.453 packets/s), 317 flows/300s (1 flows/s) External 109.236.85.157, 0,444 GByte/300s (12 MBit/s), 341.000 packets/300s (1.136 packets/s), 1 flows/300s (0 flows/s) External 93.114.44.37, 0,435 GByte/300s (11 MBit/s), 321.000 packets/300s (1.070 packets/s), 1 flows/300s (0 flows/s) External 46.165.196.73, 0,373 GByte/300s (10 MBit/s), 287.000 packets/300s (956 packets/s), 1 flows/300s (0 flows/s) External 91.208.34.12, 0,260 GByte/300s (7 MBit/s), 217.000 packets/300s (723 packets/s), 1 flows/300s (0 flows/s) External 212.117.161.80, 0,256 GByte/300s (6 MBit/s), 191.000 packets/300s (636 packets/s), 1 flows/300s (0 flows/s) External 212.26.1.109, 0,241 GByte/300s (6 MBit/s), 363.000 packets/300s (1.210 packets/s), 2 flows/300s (0 flows/s) External 174.140.167.122, 0,238 GByte/300s (6 MBit/s), 177.000 packets/300s (590 packets/s), 1 flows/300s (0 flows/s) External 109.163.225.203, 0,182 GByte/300s (4 MBit/s), 142.000 packets/300s (473 packets/s), 1 flows/300s (0 flows/s) External 94.23.164.42, 0,174 GByte/300s (4 MBit/s), 137.000 packets/300s (456 packets/s), 1 flows/300s (0 flows/s) External 137.56.163.64, 0,170 GByte/300s (4 MBit/s), 157.000 packets/300s (523 packets/s), 2 flows/300s (0 flows/s) External 173.254.192.38, 0,166 GByte/300s (4 MBit/s), 143.000 packets/300s (476 packets/s), 1 flows/300s (0 flows/s) External 188.165.26.254, 0,163 GByte/300s (4 MBit/s), 134.000 packets/300s (446 packets/s), 1 flows/300s (0 flows/s) External 217.115.137.222, 0,156 GByte/300s (4 MBit/s), 123.000 packets/300s (410 packets/s), 1 flows/300s (0 flows/s) External 94.23.168.39, 0,149 GByte/300s (4 MBit/s), 133.000 packets/300s (443 packets/s), 1 flows/300s (0 flows/s) External 216.24.174.245, 0,147 GByte/300s (4 MBit/s), 106.000 packets/300s (353 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.163, 0,138 GByte/300s (3 MBit/s), 123.000 packets/300s (410 packets/s), 1 flows/300s (0 flows/s) External 85.214.75.110, 0,137 GByte/300s (3 MBit/s), 117.000 packets/300s (390 packets/s), 1 flows/300s (0 flows/s) External 204.45.133.189, 0,135 GByte/300s (3 MBit/s), 131.000 packets/300s (436 packets/s), 1 flows/300s (0 flows/s) External 94.23.174.3, 0,131 GByte/300s (3 MBit/s), 112.000 packets/300s (373 packets/s), 1 flows/300s (0 flows/s) External 85.31.186.116, 0,130 GByte/300s (3 MBit/s), 104.000 packets/300s (346 packets/s), 1 flows/300s (0 flows/s) External 178.32.52.72, 0,118 GByte/300s (3 MBit/s), 104.000 packets/300s (346 packets/s), 1 flows/300s (0 flows/s) External 46.165.196.182, 0,112 GByte/300s (3 MBit/s), 134.000 packets/300s (446 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.164, 0,106 GByte/300s (2 MBit/s), 89.000 packets/300s (296 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.162, 0,104 GByte/300s (2 MBit/s), 95.000 packets/300s (316 packets/s), 1 flows/300s (0 flows/s) External 146.185.23.179, 0,103 GByte/300s (2 MBit/s), 96.000 packets/300s (320 packets/s), 1 flows/300s (0 flows/s) External 87.98.180.247, 0,101 GByte/300s (2 MBit/s), 95.000 packets/300s (316 packets/s), 1 flows/300s (0 flows/s) External 199.48.147.35, 0,095 GByte/300s (2 MBit/s), 93.000 packets/300s (310 packets/s), 2 flows/300s (0 flows/s) External 62.220.136.253, 0,092 GByte/300s (2 MBit/s), 110.000 packets/300s (366 packets/s), 1 flows/300s (0 flows/s) External 89.248.168.118, 0,092 GByte/300s (2 MBit/s), 79.000 packets/300s (263 packets/s), 1 flows/300s (0 flows/s) External 199.48.147.45, 0,089 GByte/300s (2 MBit/s), 75.000 packets/300s (250 packets/s), 1 flows/300s (0 flows/s) External 188.120.245.249, 0,088 GByte/300s (2 MBit/s), 75.000 packets/300s (250 packets/s), 1 flows/300s (0 flows/s) External 212.95.43.222, 0,087 GByte/300s (2 MBit/s), 72.000 packets/300s (240 packets/s), 1 flows/300s (0 flows/s) External 74.109.126.29, 0,082 GByte/300s (2 MBit/s), 71.000 packets/300s (236 packets/s), 1 flows/300s (0 flows/s) External 91.121.166.158, 0,081 GByte/300s (2 MBit/s), 71.000 packets/300s (236 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.165, 0,079 GByte/300s (2 MBit/s), 80.000 packets/300s (266 packets/s), 1 flows/300s (0 flows/s) External 146.185.23.180, 0,078 GByte/300s (2 MBit/s), 74.000 packets/300s (246 packets/s), 1 flows/300s (0 flows/s) External 91.121.85.130, 0,078 GByte/300s (2 MBit/s), 68.000 packets/300s (226 packets/s), 1 flows/300s (0 flows/s) External 93.182.132.100, 0,075 GByte/300s (2 MBit/s), 65.000 packets/300s (216 packets/s), 2 flows/300s (0 flows/s) External 46.73.164.123, 0,074 GByte/300s (2 MBit/s), 63.000 packets/300s (210 packets/s), 1 flows/300s (0 flows/s) External 194.204.30.253, 0,067 GByte/300s (1 MBit/s), 101.000 packets/300s (336 packets/s), 1 flows/300s (0 flows/s) External 79.172.193.89, 0,065 GByte/300s (1 MBit/s), 58.000 packets/300s (193 packets/s), 1 flows/300s (0 flows/s) External 62.116.251.71, 0,065 GByte/300s (1 MBit/s), 51.000 packets/300s (170 packets/s), 1 flows/300s (0 flows/s) External 77.245.18.28, 0,064 GByte/300s (1 MBit/s), 47.000 packets/300s (156 packets/s), 1 flows/300s (0 flows/s) External 173.254.216.69, 0,064 GByte/300s (1 MBit/s), 60.000 packets/300s (200 packets/s), 1 flows/300s (0 flows/s) External 188.72.225.172, 0,061 GByte/300s (1 MBit/s), 60.000 packets/300s (200 packets/s), 1 flows/300s (0 flows/s) External 93.115.241.2, 0,061 GByte/300s (1 MBit/s), 53.000 packets/300s (176 packets/s), 1 flows/300s (0 flows/s) External 173.254.192.36, 0,059 GByte/300s (1 MBit/s), 50.000 packets/300s (166 packets/s), 1 flows/300s (0 flows/s) External 188.165.24.70, 0,057 GByte/300s (1 MBit/s), 58.000 packets/300s (193 packets/s), 1 flows/300s (0 flows/s) External 85.223.49.156, 0,053 GByte/300s (1 MBit/s), 43.000 packets/300s (143 packets/s), 1 flows/300s (0 flows/s) External 131.130.199.36, 0,052 GByte/300s (1 MBit/s), 45.000 packets/300s (150 packets/s), 1 flows/300s (0 flows/s)

2 1

Re: [tor-relays] new (to me, at any rate) message
by Scott Bennett 05 Dec '11

05 Dec '11

On Sun, 4 Dec 2011 17:47:30 +0100 Sebastian Hahn <mail(a)sebastianhahn.net> wrote: >On Dec 4, 2011, at 12:40 PM, Scott Bennett wrote: > >> About an hour and a half ago, my node issued the following message. >> >> Dec 04 04:03:56.685 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. >> >> What does it mean? And what triggers it? Is it attempting to use a relay >> listed in the directory and consensus, but finding that that relay's status >> has changed since the consensus? > >This is a message frequently seen on relays for a while now, due to a >bug in hidden service usage in 0.2.3.x clients. See >https://trac.torproject.org/projects/tor/ticket/4171 for what we know >about it. Basically, it doesn't indicate a problem with the relay, but >rather the Tor client that uses the relay. Thus, we will soon go ahead Yes, I had gathered that much. >and stop logging this at default log levels, and also fix it on the >client side. > Urrgh... It looks like you and Robert have a good handle on it, so I won't worry about it if I see it again. Thanks much, Sebastian! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

new (to me, at any rate) message
by Scott Bennett 04 Dec '11

04 Dec '11

About an hour and a half ago, my node issued the following message. Dec 04 04:03:56.685 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. What does it mean? And what triggers it? Is it attempting to use a relay listed in the directory and consensus, but finding that that relay's status has changed since the consensus? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

3 2

Re: [tor-relays] new (to me, at any rate) message
by Scott Bennett 04 Dec '11

04 Dec '11

On Sun, 04 Dec 2011 07:02:03 -0500 Justin Aplin <japlin(a)gmail.com> wrote: >On 12/4/2011 6:40 AM, Scott Bennett wrote: >> About an hour and a half ago, my node issued the following message. >> >> Dec 04 04:03:56.685 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. >> >> What does it mean? And what triggers it? Is it attempting to use a relay >> listed in the directory and consensus, but finding that that relay's status >> has changed since the consensus? > >No idea what it means, but I got the same error at nearly the exact same >time on one of my relays. Odd. > Well, maybe that is interesting. I'm on CST, which is GMT-6hrs. Do the times still match? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

Re: [tor-relays] consensus "Bandwidth=" values
by Scott Bennett 02 Dec '11

02 Dec '11

On Thu, 1 Dec 2011 04:55:06 -0500 Roger Dingledine <arma(a)mit.edu> wrote: >On Wed, Nov 30, 2011 at 05:51:13PM -0600, Scott Bennett wrote: >> Something new appears to be happening in the authorities' assignments >> of "Bandwidth=" values in the consensus documents over the past few days. >> Here are some statistics from the recent consensus with the following valid >> times: >[snip] >> The top ten in the above list account for 814 relays or 32.73% of all relays >> in the consensus, yet they will get little or no traffic because of the >> assigned "Bandwidth=" values. My relay's traffic went from around 55% - 60% >> of what I had hoped to contribute down to almost nothing in the course of >> about three days, and the "Bandwidth=" value assigned to it in the consensus >> is 1. For a long time, it had typically been in the high 20s to high 30s >> with occasional excursions from slightly lower to somewhere in the 50s. >> So is this sudden, massive reassignment of loads due to a bug in the >> newest tor version(s)? Or is it an intended change by the developers? > >Mike Perry is trying out more network rebalancing ideas. See > >https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… >https://trac.torproject.org/projects/tor/ticket/1976 >https://trac.torproject.org/projects/tor/ticket/4425 Thanks for those. I'll probably get a chance to take a look at them later today. > >The "bandwidth authority" scripts do active bandwidth measurements, >and adjust the bandwidth weights they vote about based on how a relay >performs compared to its peers. Last week "peers" were characterized >based on the self-advertised bandwidth, that is, the bandwidth in the >relay descriptor. With the new PID design, "peers" are now a function >of the weight in the consensus. Okay, but that bring in again the old problem of flailing values reported due to the feedback. If you're going to include those reported values, then tor needs to be fixed first, so that it never reports a lesser value than it has previously reported since initialization except in "unusual" circumstances, where "unusual" might be defined as something like a current value that were less than half of the value in the last descriptor published. IOW, the value should ordinarily approach the true capacity asymptotically over successive descriptor publications. If this fix isn't made, then randomly occurring slow traffic period for a given relay will result in less traffic being sent to it in the future, which would not reflect the actual capacity of the relay. Another problem is that, as I understood from earlier links you provided, Mike's testers were measuring latency, where latency referred not to end-to-end nor to round-trip packet travel times, but rather to circuit construction times. (BTW, I'm interested in the equations/matrices used to invert the data collected for multi-hop circuits to yield values for each individual node. Is there a page on your web servers that shows them?) Circuit construction, of course, requires different resources from those required simply to pass data along already created circuits, so the latency times and the data rate capacities really are not comparable types of measurements. (What is a typical correlation coefficient between them? I would expect some positive correlation, but not necessarily close to 1.) > >In theory this feedback loop should drive even more traffic toward relays >that can handle it, and even less traffic toward relays that can't, >until we reach an equilibrium. > >In practice, it drives super-fast relays to a weight of infinity, and >all the rest to a weight of zero. > >Mike thought he'd gotten things (more) right this time, but it would >appear that has hasn't: >https://metrics.torproject.org/performance.html#torperf > >Sorry for the disturbance. I think we should probably turn the experiment >off soon. But the little dip you see in the torperf graph before the >spike makes me think there *is* a point here that is better, even if we >haven't found it yet. :) > Are you sure that little dip isn't just an artifact of the T-Day holiday weekend in the U.S.? (Cool graph, BTW.:-) Anyway, thanks much for the explanations, Roger. Glad to know that 2.3.8-alpha isn't at fault. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

Messages "We stalled too much while trying to write..."
by Klaus Layer 02 Dec '11

02 Dec '11

Hi, I am getting many messages of this type on a node with 0.2.3.7-alpha: [NOTICE] We stalled too much while trying to write 192 bytes to address [scrubbed]. If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd 1304, type Directory, state 2, marked at main.c:962). The node is running on quad core i7 with a Gbit network interface. The network connection is working. I never saw this type of messages on my other nodes. Any advice how to get rid of these messages? Regards, Klaus

1 1

consensus "Bandwidth=" values
by Scott Bennett 01 Dec '11

01 Dec '11

Something new appears to be happening in the authorities' assignments of "Bandwidth=" values in the consensus documents over the past few days. Here are some statistics from the recent consensus with the following valid times: valid-after 2011-11-30 22:00:00 fresh-until 2011-11-30 23:00:00 valid-until 2011-12-01 01:00:00 A quick count of "Bandwidth=" values from this consensus shows that just over 20% of all relays have been assigned "Bandwidth=1". The consensus contains 2487 relays in all. The top twenty by count are as follows. Count Bandwidth= % of Total 499 1 20.06 65 2 2.61 37 3 1.48 35 5 1.40 33 7 1.32 31 6 1.24 31 14 1.24 29 4 1.16 29 12 1.16 25 15 1.00 23 11 0.92 22 9 0.88 21 20 0.84 20 8 0.80 18 17 0.72 18 10 0.72 15 32 0.60 14 53 0.56 14 24 0.56 14 18 0.56 The top ten in the above list account for 814 relays or 32.73% of all relays in the consensus, yet they will get little or no traffic because of the assigned "Bandwidth=" values. My relay's traffic went from around 55% - 60% of what I had hoped to contribute down to almost nothing in the course of about three days, and the "Bandwidth=" value assigned to it in the consensus is 1. For a long time, it had typically been in the high 20s to high 30s with occasional excursions from slightly lower to somewhere in the 50s. So is this sudden, massive reassignment of loads due to a bug in the newest tor version(s)? Or is it an intended change by the developers? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Tor bridge relay
by SiR GadaBout 30 Nov '11

30 Nov '11

Hi, I'm a new user of Ubuntu Linux considering setting up a bridge relay on the tor network over my home connection. If you don't mind, I'd like to set out my aims first. I have a laptop currently serving a Privoxy ad-filtering proxy for my home network. The plan is to torify my iPhone whilst retaining the ad-filtering effects of Privoxy. Once I'm comfortable this is working, i'd like to turn the server into a bridge relay. 1) Can I Torify my iPhone in this manner without a jailbreak? 2) Is my use of Privoxy counter-productive? I believe it is no longer bundled with Tor owing to privacy concerns. 3) Is it possible to make my bridge relay operate only between certain hours, so as not to aggravate my ISP? I'd be thinking of making it available for ten hours every day during local off-peak hours. I could consider making it available permanently if this pans out okay, or if the timed service isn't an option. My iPhone is a 3GS running iOS 5.0.1. The laptop is running Ubuntu Server 11.10 64-bit. It has 2GB DDR2 RAM, a 2GHz Core2Duo CPU and a Gigabit Ethernet connection. My broadband is 10Mb down, 1Mb up. Thanks in advance, B.

1 0

In which countries are relays needed, disallowed?
by Steve Snyder 25 Nov '11

25 Nov '11

I tried to set up a Tor relay in the UK today and was told that UK law prohibited anonymous Internet traffic. My tentative UK ISP told me that they must be able to provide identification of users if presented with a court order. Hmmm... The topic of country-specific conditions raises 2 questions in my mind: 1. Does the Tor Project keep a list of Tor-hostile countries? I understand that such a list over time would vary in reliability, but it would be nice to know. 2. Given the ability to set up a Tor relay in any political jurisdiction, which ones would be recommended? I'm thinking of both local political conditions and the distribution of relays from a topological perspective. I'm inclined to want a non-US relay because the highest bandwith relays locations are skewed toward the US, which biases the Tor traffic though that jurisdiction. (Today's Tor Metrics report shows 17.55% of traffic coming from the US.) Is this a reasonable approach? Thanks.

6 6

could not access my own hidden service
by cmeclax-sazri 21 Nov '11

21 Nov '11

I run Torchat and Onioncat. For at least an hour last night, my Torchat showed that I was not online, but someone else was, implying that he could see me online. I have a laptop which also has Tor, but it's just a client. I verified with Onioncat that two hidden services on the same box could not contact each other, but the laptop could contact both of them. The relay is running 0.2.2.34; the laptop is running 0.2.1.30. My Torchat now sees that I'm online, without having restarted Tor. What could cause this? cmeclax

2 1

exit atlgonyovLi
by Geoff Down 11 Nov '11

11 Nov '11

Will the owner of exit atlgonyovLi please turn off OpenDNS site blocking. -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again

2 2

Middleman/guard nodes raided in the Netherlands
by David 10 Nov '11

10 Nov '11

I just wanted to let everyone know that my two Tor nodes have been raided (+all my computer equipment and everything that could store data). I'm not sure what triggered all this unwanted attention, but I suspect that it's the local police department trying to make a score after tor getting some media attention. It doesn't look to be a very 'high-tech' operation because I got a call asking me for the root password to the tor servers that are on unencrypted disks... Let this be a warning to everyone running middlemans in the Netherlands, I found out the hard way. Nicknames of the servers where AIVD and MIVD, no clue what the public key was. But consider them compromised. Best regards, David

8 10

v3 directory
by Sebastian Urbach 08 Nov '11

08 Nov '11

Hi, Does anybody run a v3 directory relay ? I read about a long term key in the documentation. Are there any others things to consider ? I would be happy if somebody would share his config :-) Thanks -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

1 0