Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011 11:30:20 -0500 Andrew Lewman and...@torproject.org wrote: In my opinion, judging a relay based on exit policy is a slippery slope we don't want to go down. We never claim to make using Tor alone safer than using the Internet at large. Whether the creep is at Starbucks sniffing the wifi or running a relay is irrelevant to me. Encouraging people to use encrypted communications, the https everywhere firefox extension, and learn to be more secure online are some of our goals. The Tor Browser Bundle, while still a work in progress, is the best way to protect novice users and get them safer than they are without Tor. I personally run encrypted services on unencrypted ports, like 25, 80, 143, 110, etc. It's just a port number and only convention says port 80 has to be for http only. If people start doing deep packet inspection to enforce 80 is really http or running filters in some misguided attempt to block bad things through Tor, then those are reasons to 'badexit' relays. There are some obvious ways we can detect traffic manipulation through Tor relays. Today, we do detect them and badexit those relays. If we're going to start censoring Tor exits based on impressions, we might as well start blocking Tor relays that are rumoured to be run by national intelligence agencies, criminal organizations, martians, and other people we might not like. In fact, we might as well go back to the original model of every Tor relay operator has met and gained Roger's trust. I want a diverse set of Tor relays. If people don't want to trust relays based on whatever heuristics they want to use, great, use ExcludeNodes in your torrc. Don't punish everyone based on rumors and impressions. Hear, hear! Thank you, Andrew, for putting it so clearly in accord with previously posted policy statements by the tor development team, both on the tor lists and on the tor project's web site. I don't know what triggered Mike's dictatorial moment, but I hope he comes to his senses quickly (if he hasn't already; I confess I'm hundreds of messages behind in my email at present). Your remark about the Roger trusts 'em model does still seem to apply to the assignment of Authority flags. Given the current directory protocol(s) and distribution structure, I'm fine with that arrangement for the time being for Authority flagging, but not for BadExit flagging for the reasons you posted, as well as a few posted by others, including myself. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011 11:09:51 +0100 Olaf Selke olaf.se...@blutmagie.de wrote: On 31.01.2011 10:52, morphium wrote: As I stated above, it's not a good idea to BadExit them, because it puts more load on the servers, that DO support https i.e. - and makes them slower. I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. I think Mike's and Jake's implied claims of clairvoyance regarding an exit node operator's intentions in writing the exit policy for his/her node call for some supporting evidence. Instead, one of them has already admitted that they have no evidence because they have no way to detect any. And I don't see ANY point in BadExit'ing 5 random Nodes, suggesting that no one could capture your unencrypted traffic now. those five high bandwidth nodes with suspicious exit policies haven't been chosen randomly. Olaf, you run four high-capacity exit nodes, each of which allows unencrypted exits. You have a longstanding capacity record, so it wouldn't be random at all to choose to flag your nodes as bad exits; rather, it would simply be recognizing that you have the ability to sniff a significant portion of all unencrypted exit traffic. To avoid having your four nodes flagged as bad exits, perhaps you should block port 80 and all the thousands of other ports that are usually unencrypted. Now, you might point out that Mike's criterion for avoiding BadExit flagging is that you can continue to do your sniffing of unencrypted exit traffic, provided you also allow encrypted exits on a handful of ports. This is all silliness. The tor project until very lately has always promoted end user understanding and responsibility. Now the project *appears* to be undergoing a major philosophical change toward nannying the tor user community, a direction I find very unappealing, to say the least. Horrifying might be a more appropriate word. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011 11:17:27 +0100 morphium morph...@morphium.info wrote: 2011/1/31 Olaf Selke olaf.se...@blutmagie.de: I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. Sniffing is worse than loosing bandwidth, right. But sniffing still occurs, we just don't know where. And we can't tell wether they did. I think concluding only 80: he is sniffing is wrong (and even would be 80 and 443: he is a good guy). And if those nodes really are ran by the bad guys, I don't think it's a problem for them now to setup a new node on a new subnet that allows their old ports + 443 and continue sniffing. Exactly, on all points. I can not see the Tor project won _anything_ with this decision. Well, they've made clear that they know what's good for exit operators better than those exit operators do. Perhaps they should arrange ISP choices, contracts, and bill payment methods for those exit operators next? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, 29 Jan 2011 23:23:55 -0800 Mike Perry mikepe...@fscked.org wrote: Thus spake Eddie Cornejo (corn...@gmail.com): I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. =20 Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. We can detect nodes that fail encrypted connections. We currently scan for failure of port 443. We also detect throttling by virtue of our bw authorities measuring using 443. 443 is the second-most trafficed port by byte on the Tor network, occupying only ~1% of the traffic. If stingy exit nodes really want to And port 80 is the highest-traffic port. Exits to port 80 allow unencrypted access to webmail sites with user ids and passwords transmitted in the clear. Using your argument, all nodes allowing exits to port 80 that do not eliminate all webmail sites by way of their exit policies should be flagged as BadExit. That would certainly be a strange way to put tor into the dustbin of computer history, but it would indeed accomplish that. waste hours to pinch pennies from their malicious exit policy, they gatereloaded is among the top 60 nodes in the network by traffic capacity and is unlikely therefore to be pinching pennies on it. It is a valuable entry and middle node. If the operator wishes to offer in addition some exit services for a handful of ports that are unlikely to trigger problems from the operator's ISP, that is merely added gravy for tor users. can try crafting a throttling policy that we can't detect. Seems like there are better ways to spend their time. Like reading other people's email. So no, I'm not terribly concerned about second-order effects of this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. =20 My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. We're not trying to identify wolves. We are sending a message to the community. =20 If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. =20 I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c I second that discomfort. I further note that the tor project team has repeatedly claimed that there is an ongoing shortage of exit nodes, although it has not often noted for which ports there is a shortage. One of the selling points for potential exit operators is that the exit operator can set an exit policy of his/her choice. The ability to do that means the operator can evaluate his/her own situation vis-a-vis his/her ISP, data rate capacity, etc. and decide upon a policy that will not cause him/her a level of grief unacceptable to him/her. Not really. In reality, it's up to those who write the code to decide what is available and how it works ;). Welcome to The Golden Path. At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Here you threaten that the tor project would someday severely reduce the control that an exit operator would have over his/her node. How would such a reduction help to entice more people to run exit nodes? How would such a reduction not cause at least some existing exit operators to stop offering exit services because they could no longer set an exit policy that they found acceptable in their circumstances? Scott Bennett, Comm. ASMELG, CFIAG
tor weather subscription problem
I just tried to sign up for the tor weather email service. Clicking on the subscribe button after entering the information requested in various places earlier on the page yielded, Forbidden (403) CSRF verification failed. Request aborted. You are seeing this message because this HTTPS site requires a 'Referer header' to be sent by your web browser, but none was sent. This header is required for security reasons, to ensure that your browser is not being hijacked by third parties. If you have configured your browser to disable 'Referer' headers, please re-enable them, at least for this site, or for HTTPS connections, or for 'same-origin' requests. More information is available with DEBUG=True. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[OT] Republicons resume attacks on privacy
The Republicants are back to pushing data retention legislation. :-( http://news.cnet.com/8301-31921_3-20029393-281.html#ixzz1C6p2U2fR 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: U.S. begins censoring Internet at U.K.'s request
On Mon, 8 Nov 2010 04:28:17 + (UTC) John Case c...@sdf.lonestar.org wrote: On Sun, 7 Nov 2010, Scott Bennett wrote: Scott Bennett, Comm. ASMELG, CFIAG What do those two acronyms (ASMELG, CFIAG) mean ? They're a summary of my pilot credentials. If you have to ask, then you're not a pilot, and spelling them out may not mean much to you. Other pilots occasionally subscribe to the same lists and news groups that I do, and they often have stories to share by email when they spot another pilot. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: U.S. begins censoring Internet at U.K.'s request
On Sat, 06 Nov 2010 16:03:24 -0500 David Carlson carlson...@sbcglobal.net
wrote:
On 11/6/2010 1:02 PM, Scott Bennett wrote:
I wrote:
http://news.antiwar.com/2010/11/05/us-censors-muslim-websites-list-of-=
british-mps-who-supported-iraq-war/
Using exit chuckthecanuck gives a Google (!) error page, saying =
URL
not found. I'll add that exit to my ExcludeExitNodes list with a comm=
ent
that the reason is due to DNS hijacking that is probably related to U.=
S.
censorship.
I changed my mind. I'm adding {ca},{uk},{us} to my ExcludeExitNod=
es
list with an appropriate comment for later removal in case the U.S. eve=
r
calls off its War on the Internet. :-(
How do we know whether that article is accurate, and if it is, is it a
Have you tried it? The name servers still resolve the name to an address,
but attempts to reach the address, either by name or by IP address, in a web
browser yield only a Google error page.
single event or a result of a change in policy. How could it have been
implemented anyway?
Routing table fraud seems a likely modus operandi.
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 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: U.S. begins censoring Internet at U.K.'s request
On Sun, 07 Nov 2010 14:17:20 + Geoff Down geoffd...@fastmail.net
wrote:
On Sun, 07 Nov 2010 08:05 -0600, Jon torance...@gmail.com wrote:
On Sat, Nov 6, 2010 at 1:02 PM, Scott Bennett benn...@cs.niu.edu wrote:
I wrote:
http://news.antiwar.com/2010/11/05/us-censors-muslim-websites-list-of-british-mps-who-supported-iraq-war/
Using exit chuckthecanuck gives a Google (!) error page, saying URL
not found. I'll add that exit to my ExcludeExitNodes list with a comment
that the reason is due to DNS hijacking that is probably related to U.S.
censorship.
I changed my mind. I'm adding {ca},{uk},{us} to my ExcludeExitNodes
list with an appropriate comment for later removal in case the U.S. ever
calls off its War on the Internet. :-(
I don't understand why excluding all exit nodes from the US, CA, and
UK, especially if you have only one exit node showing the error?
Altho, I may not understand or I misinterpreted your email
I had no issues with getting the website on google. I had to copy and
paste the url as it would not go directly from the email. Actually,
almost all the url's lately from the email;s don't go directly, I have
to cut and paste to get to them.
Jon
The OP is presumably saying that the domain refered to in the
antiwar.com story is unreachable, not antiwar.com itself.
That's because it's been suspended by the registrar: tor-resolve returns
no IP for it and the .com root server reports that no such domain
exists. There may be cached entries floating around though.
Actually, before posting my original note, I had used tor-resolve to
look for an IP address, and it quickly returned 74.125.93.121. Doing a
reverse lookup of that address (also with tor-resolve -x) returned not the
original name but rather qw-in-f121.1e100.net. Plugging either the IP
address or the latter name into the URL got me the same Google error page.
Now, however, tor-resolve on the original name returns
[warn] Got SOCKS5 status response '4': host is unreachable
but the reverse lookup still gives the name shown above.
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 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
U.S. begins censoring Internet at U.K.'s request
http://news.antiwar.com/2010/11/05/us-censors-muslim-websites-list-of-british-mps-who-supported-iraq-war/ Using exit chuckthecanuck gives a Google (!) error page, saying URL not found. I'll add that exit to my ExcludeExitNodes list with a comment that the reason is due to DNS hijacking that is probably related to U.S. censorship. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: U.S. begins censoring Internet at U.K.'s request
I wrote:
http://news.antiwar.com/2010/11/05/us-censors-muslim-websites-list-of-british-mps-who-supported-iraq-war/
Using exit chuckthecanuck gives a Google (!) error page, saying URL
not found. I'll add that exit to my ExcludeExitNodes list with a comment
that the reason is due to DNS hijacking that is probably related to U.S.
censorship.
I changed my mind. I'm adding {ca},{uk},{us} to my ExcludeExitNodes
list with an appropriate comment for later removal in case the U.S. ever
calls off its War on the Internet. :-(
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 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: New Bundle Version 1.3.10
On Wed, 27 Oct 2010 10:22:07 + Erinn Clark er...@torproject.org wrote: * M moeedsa...@gmail.com [2010:10:16 18:48 +]:=20 Why the switch to noscript? and link on the issue? Hey there, I am working on writing this up -- I sat down with Mike Perry, the Torbutton developer, and we went over what each of the Firefox extensions added. It's= not in any kind of proper document yet, but here are my notes about the new extensions so you aren't left hanging for too much longer: HTTPS-Everywhere - pre-emptively converts http URLs into https URLs for many popular sites that support https NoScript - majority of options are disabled Erinn, I'm not sure what you meant there. Did you mean that NoScript disables the majority of Firefox options? Or that the majority of NoScript options is disabled in this version of the bundle? - allows users to globally toggle javascript - provide click-to-play placeholders in the event that users want to set to= rbutton to enable plugins FWIW, I'd like to recommend also using QuickJava, which allows toggling of Java and JavaScript individually. In other words, allowing scripts in NoScript allows one still to disable Java while leaving JavaScript enabled if one so desires. If scripts are disabled in NoScript, then clicking on the QuickJava buttons has no effect. I, for one, *never* want Java enabled for anything, but in a very few cases, I do allow JavaScript to run. BetterPrivacy - exists only to delete flash cookies in the event that users allow plugins and run certain flash apps. it cleans up any data that flash might write outside of our control. (backup mechanism.) I'll let you know when I have a fuller analysis available. Okay. You might want to look through all the stuff on the NoScript web pages to get a better understanding of the extensive list of pretty awful leakages and attacks that NoScript can block. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excessive scrubs
On Wed, 20 Oct 2010 08:11:25 -0500 Joe Btfsplk joebtfs...@gmx.com wrote: So I won't make same 'mistakes' as Jon, please explain what you mean by: please learn to edit followups in-line, i.e., stop top-posting [Isn't top posting the way most forums work? I'm guessing protocol is diff because it's a mailing list?? I haven't used mailing lists that much.] Nope. I've never seen any non-tor-related lists where so many people top-post. On most lists to which I have ever subscribed, other subscribers firmly object to top-posting when it appears on those lists. Also, feel free to visit http://www.caliburn.nl/topposting.html http://www.html-faq.com/etiquette/?toppost and, please learn to list-reply, i.e. stop breaking threads What is meant by list-reply vs stop breaking threads? Aren't they 2 diff things? This is something I've answered many times on this list already, but I will answer it this one final time. After this, anyone who gives a dam can bloody well look up an instance of my explanation in the list archives. I think what he was referring to was the fact that I do not use a mail interface that supports the use of optional headers for threaded reading of mail by subject similar to the way threaded USENET newsreaders do it. My explanation in this case is in two parts: 1) regardless of the condition of other subscribers to mailing lists, my eyeballs and brain work just fine, so I have no trouble following the flow in the lists, including list digests, which are what I receive for most of my list subscriptions outside of the tor-related lists, especially for lists that are such low-volume lists as the tor-related lists tend to be, and 2) it's out of my control anyway because I not only am not the system administrator on this system, I have merely a guest account for the primary purpose of dealing with email, so I can't install mail software to suit the tastes of other people on the lists to which I subscribe. Respectfully Scott, some would consider your signature / long quote, w/ multiple rows of asterisks dashes a bit excessive. Doesn't bother me particularly, but would some. And some would consider phony names used in email to show lack of courage of convictions when voicing opinions in public, although I do recognize that there are some life-threatening situations where such practices may be necessary to reduce/eliminate the risk and the lack of courage is therefore forgivable. I don't know your situation, and perhaps you are exposed to such dangers, so I cannot comment upon the particular case of your use of a seemingly phony name, nor do I let such usage bother me as a rule either. Many people also would consider my .signature not to be excessive, and there are many whose .signature blocks are far larger than mine, some so much so that I would also be inclined to object if the owner were a frequent poster. FWIW, mine has gone through many changes over the years, but I like the way it is at present. If I run across another quotation that I happen to like better, I may replace it. For mailing list use, I normally omit the postal address lines anyway as below. Although I didn't respond directly to Jon's reply, I'd like to thank him for his update and its reassurance. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excessive scrubs
On Fri, 15 Oct 2010 08:29:04 -0500 Jon torance...@gmail.com wrote: Thanks, followup it is running properly now. I did an upgrade to Vidalia only and it resolved the issue. There have been no more scrubs. [massive top-posting sequence *deleted* --SB] Two requests: 1) please learn to edit followups in-line, i.e., stop top-posting 2) if you plan to continue to run a relay with SafeLogging 0 in its torrc, please post the identifier fingerprint of the relay, so the rest of us can all add it to our ExcludeNodes lists. SafeLogging 0 is a security violation that is only intended for debugging a problem, not for normal use. Read the documentation about it. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
FBI trying to get backdoors legislated again
http://abcnews.go.com/Technology/fbi-backdoor-access-mail-texts/story?id=11825039 (Beware of linewrap in the URL.) 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Sorry I'm so far behind on email. Will try to catch up soon. On Fri, 24 Sep 2010 22:05:45 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Sep 11, 2010, at 3:47 AM, Sebastian Hahn wrote: On Sep 10, 2010, at 10:40 AM, Roger Dingledine wrote: In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. it'd be nice if further discussion could be moved to the bug report. Nick had a nice idea how to solve the situation without breaking our controllers. It would be great to get feedback on this (positive or negative) so please do reply with your thoughts. Patches for the documentation are also welcome, if they help to clarify the situation. Thanks Sebastian To let those know who didn't start monitoring the bug report, as of 851255170 we implemented a new feature to allow using multiple lines when specifying a torrc entry. To indicate that a line ends in the torrc but Tor should treat the next line as if it belonged to the current line, use a backslash at the end of the line. Comments inside such a block are ignored. What terminates a comment inside such a block? To provide an example, here is what the new syntax might look like (basically all previously valid torrcs should remain valid): ExcludeNodes \ # I don't like kittens lolcat1, \ Is the lolcat1, part of the comment about kittens? lolcat2 \ # / I also don't like bunnies! I really hate them. \ Is the \ part of the comment? The early comment line about kittens lacks a \. Are both validly continued lines? ,cutebunny, extracutebunny, \ # and this node appeared on my mother's birthday birthdaynode StrictNodes 1 I hope this is an acceptable solution for those who wanted a change, and doesn't upset those that thought the old behaviour was like it should be. Wow. That's the most incredibly *ugly* kluge I've seen in many a year, but if it works, then at least it does provide the functionality. I'll make the required changes to a copy of torrc and then try the upgrade to 0.2.2.17-alpha sometime in the next few days. Answers to the questions above would be helpful, though, in making those modifications. However, I don't understand the need for compatibility for tor controllers on this one. It seems to me that changes to the ExcludeNodes and ExcludeExitNodes lists are the kind of thing that should require rereading torrc, throwing away the previous lists and replacing them with the new ones read from torrc. Controllers should have the ability to trigger rereading of torrc, but not to make this sort of major operational change on the fly directly rather than by through rereading torrc. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
I had planned to upgrade my node from 0.2.2.14-alpha this evening to 0.2.2.15-alpha, but there is an unfortunate and apparently gratuitous, new restriction upon ExcludeNodes and ExcludeExitNodes that, for the moment at least, is preventing me from upgrading. I have a rather long list of nodes that I have found undesirable in ways that justify (to me, at least, and my opinion rules on my node) their inclusion in one or the other of those lists. After building 0.2.2.15-alpha and installing it, I ran the usual tor --verify-config as a basic test. Surprise! It issued many messages of each of the following types: Sep 10 01:15:29.753 [warn] Option 'ExcludeExitNodes' used more than once; all but the last value will be ignored. Sep 10 01:15:29.753 [warn] Option 'ExcludeNodes' used more than once; all but the last value will be ignored. There is no way that I can fit all of the excluded nodes of each type onto a single line for each type in my torrc. Also, my torrc is full of comment lines documenting the reasons for these exclusions in each case, which allows me to review certain ones from time to time for possible removal from whichever list they are on and also to know which ones should never be removed. Even if an editor were available that could handle line lengths great enough to allow placement of each entire list onto a single line in torrc, the comments would have to be left out or made useless by being separated from the corresponding node identifiers. The upshot is that I cannot upgrade to a version of tor that has this new and seemingly unnecessary change. :-( This is especially irritating at the moment, given that 0.2.2.14-alpha has a bug that causes it from time to time to drastically miscalculate the cutoff time for building new circuits. For example, a couple of days ago, it suddenly changed from cutoff times on the order of 12 to 14 seconds to cutoff times ranging from 130 to 300 seconds. To the developers: please fix the next release of -alpha to allow the use of multiple ExcludeExitNodes and ExcludeNodes lines again. Thank you. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: On Fri, Sep 10, 2010 at 01:36:18AM -0500, Scott Bennett wrote: I had planned to upgrade my node from 0.2.2.14-alpha this evening to 0.2.2.15-alpha, but there is an unfortunate and apparently gratuitous, new restriction upon ExcludeNodes and ExcludeExitNodes that, for the moment at least, is preventing me from upgrading. Sep 10 01:15:29.753 [warn] Option 'ExcludeExitNodes' used more than once; all but the last value will be ignored. Sep 10 01:15:29.753 [warn] Option 'ExcludeNodes' used more than once; all but the last value will be ignored. The ChangeLog entry in question is: - Warn when the same option is provided more than once in a torrc file, on the command line, or in a single SETCONF statement, and the option is one that only accepts a single line. Closes bug 1384. To the developers: please fix the next release of -alpha to allow the use of multiple ExcludeExitNodes and ExcludeNodes lines again. Thank you. As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Can you confirm? I'm not a tor developer, so no, I cannot confirm. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, 10 Sep 2010 10:05:09 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Wow. This is a scandalously bad situation. Is there any chance that it will get a high priority for being corrected *soon*? Please?? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, 10 Sep 2010 04:40:02 -0400 Roger Dingledine a...@mit.edu wrote: On Fri, Sep 10, 2010 at 03:27:01AM -0500, Scott Bennett wrote: Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Wow. This is a scandalously bad situation. Is there any chance that it will get a high priority for being corrected *soon*? Please?? This excludenodes thing has been no end of trouble. The root problem is that it's a feature that absolutely none of the developers use. I wonder if that means there are similar problems with other features that no developers use. In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. I'll see if I can do that over the next couple of days. The old system wouldn't let me do anything beyond simply looking at trouble tickets. Meanwhile, a quick tally through my Exclude* lists shows 10 that were reported to be run by a federal agent of some sort and were not listed as a Family at the time, 2 impersonators of blutmagie, 1 that illegitimately claimed to be a directory authority, a group of 10 not listed as a Family that also inserted text into exit streams on port 80, 11 others that inserted text into or substituted their own web pages for port 80 exit streams, 8 that consistently truncated image files, 1 that redirected port 80 streams to a spyware page, 1 that allowed DNS hijacking, 1 that censored exits to certain IP addresses and/or ports instead of defining its ExitPolicy correctly, 3 that falsified SSL certificates into exit streams for MITM attacks, ~90 that ran very obsolete (e.g., 0.1.x.x, 0.2.0.x) tor software lacking oodles of security fixes, and 31 excluded for another reason of my own preference. These last two groups are ones that I do review from time to time to see whether the reason I excluded them has been eliminated, which would allow their removal from the list. All of the others, however, I've excluded for damned good reason, and I have no intention of ever removing them from the lists. As you can see, they aren't going to fit on just one ExcludeNodes line and one ExcludeExitNodes line. (I guess the angry rants can stay here. ;) I'm still in astonishment, wondering how I can actually exclude the nodes that should be excluded. No angry rants from me at this point. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project 2008 Tax Return Now Online
On Sun, 15 Aug 2010 03:40:57 -0700 Jacob Appelbaum ja...@appelbaum.net wrote: On 08/15/2010 02:56 AM, Anon Mus wrote: I think you'll find that Tor only became officially incapable of protecting from such an adversary around 2004/5 when numerous request to add this protection to Tor was made. Since then its been the official policy not to protect from such a threat (so as to head off any complaints it does not do the job perhaps ??). [citation needed] It a good idea that you speak for Tor only, not other system here, where there are/have been genuine attempts to provide full anonymity, no get out clause. Nice story, bro. Relax, Jake. He/she did write attempts, which, of course, neither equates to nor implies successes. ;-) 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: control time spent with a circuit
On Mon, 28 Jun 2010 20:55:54 +1000 Richard Baron Penman richar...@gmail.com wrote: I am after advice how to control/influence the time spent using a circuit. A few ideas from browsing the manual: - add port 80 to LongLivedPorts No. Listing a port number in LongLivedPorts simply means that circuits used to connect to a destination on port 80 must use only nodes given the Stable flag by the authorities. - decrease CircuitBuildTimeout so have more robust longer lived circuits (or shorter?) No and... - set high CircuitStreamTimeout to change circuits less often (unfortunately not supported in my v0.2.1.26) ...no. Please reread the man page for tor, which makes the functions of the two options above quite clear. The former determines how long tor will allow construction of a circuit to go on before tor abandons it for taking too long and begins constructing a different circuit instead. The latter determines how long tor will wait for a stream to connect to its destination via the circuit to which the stream has been attached before abandoning the attempt and reassigning the stream to a different circuit to try again. - increase NewCircuitPeriod so consider new circuits less often Even by your own line above, it is obvious that that parameter has no bearing upon what you wrote that you are searching for. Is my understanding correct? And are there better approaches? No. You need to read the man page again and with greater care. There is, AFAIK, only one parameter that does what you asked for, and that one is MaxCircuitDirtiness. That is also clear from the man page. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Downloading attachments with Tor - is this secure?
On Sat, 19 Jun 2010 09:15:15 -0400 Aplin, Justin M jmap...@ufl.edu wrote: Yes, if you use Torbutton, the attachment itself will be downloaded only via Tor. I believe this is the short answer to your question, though everything else Mike said is good to keep in mind as well, especially in situations where paranoia is appropriate. This is especially dangerous if you are using Yahoo Mail, because even if you trust the person who sent you the document, your attachment will be downloaded in plaintext (via http, not https). Watch out for this. Yahoo's *login* page for webmail and other services may be HTTPS, but this reverts to plain HTTP once you're actually viewing your mail and downloading attachments. A simple solution for secure webmail at the moment is using Gmail and the new Firefox addon HTTPS-Everywhere available from https://www.eff.org/https-everywhere . This addon is *NOT* magic, as it only works with the particular list of websites available on its option page, but making sure Google Services is checked in it's options will allow all Gmail connections (including downloading attachments) to happen over HTTPS. While HTTPS-Everywhere may be a nice programming exercise for its author(s), it appears wholly unnecessary for Firefox users because Firefox users should *ALREADY* be using NoScript, which allows one to accomplish the same thing, but also provides mountains of other protective measures. Don't be fooled into thinking that HTTPS-Everywhere can protect your anonymity or your privacy. If you and/or the OP continue to refuse to use NoScript, then sooner or later you and/or the OP will get burned and will thus be taught the hard way the lesson you should have understood by now. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Downloading attachments with Tor - is this secure?
On Tue, 22 Jun 2010 01:18:36 -0700 Seth David Schoen sch...@eff.org wrote: Scott Bennett writes: While HTTPS-Everywhere may be a nice programming exercise for its author(s), it appears wholly unnecessary for Firefox users because Firefox users should *ALREADY* be using NoScript, which allows one to accomplish the same thing, but also provides mountains of other protective measures. Don't be fooled into thinking that HTTPS-Everywhere can protect your anonymity or your privacy. If you and/or the OP continue to refuse to use NoScript, then sooner or later you and/or the OP will get burned and will thus be taught the hard way the lesson you should have understood by now. NoScript provides important protections for Firefox users that HTTPS Everywhere doesn't, but there are two kinds of gaps where HTTPS Everywhere provides functionality that NoScript doesn't. (HTTPS Everywhere is also partly based on code from NoScript.) (1) HTTPS Everywhere bundles a specific, and growing, list of sites that support HTTPS, so you don't (necessarily) have to find those sites yourself. The OP, IIRC, asked for a way to force HTTPS usage for *all* sites. (2) NoScript only supports using HTTPS for an entire domain, but we Not true. The NoScript configuration panel allows specification of *sites* (i.e., host+domainnames). However, it also allows the use of wildcards, as I've previously noted on this list, so *.google.com would force HTTPS for all connections to anything that matched that pattern. Similarly, a simple * should force HTTPS for everything. have several examples where sites support HTTPS only on parts of the site, or even using a different hostname, requiring a more specific translation rule and not just a hostname list. That does look like a nice feature, but it's not relevant to what the OP requested. For example, the Google support in the current HTTPS Everywhere tree is currently _fifteen_ different substitution rules, and we are already aware of several parts of Google's services that it still handles slightly incorrectly and that will require additional rules and exclusions. Just adding www.google.com to your NoScript configuration will provide quite a bit less correct functionality; to use a simple example, Google Language Tools currently breaks if you try to access it in HTTPS. Google has also suggested that they may move HTTPS support off of www.google.com entirely in order to help schools censor access to Google services; if they do that, there will be an even more conspicuous need for HTTPS Everywhere to rewrite URLs beginning with http://www.google.com/; to something like https://secure.google.com/; or https://ssl.google.com/;. Again, URL rewriting beyond simple rewriting of the protocol designator goes way beyond what the OP requested, but if it works properly would still seem like a nice feature for the rest of us. In fact, we already have a similar case with Wikimedia services, where the rewrite rules understand things like http://pt.wikipedia.org/wiki/Tiradentes -- https://secure.wikimedia.org/wikipedia/pt/wiki/Tiradentes http://la.wikisource.org/wiki/Carmina_(Catullus)/1 -- https://secure.wikimedia.org/wikisource/la/wiki/Carmina_(Catullus)/1 Again, NoScript currently can't do that kind of substitution. If you tried to force HTTPS access on, say, en.wikipedia.org, it would just break because there is no HTTPS support on that host. On the other hand, some users might definitely prioritize confidentiality over availability and argue that the browser should never load an HTTP resource from an HTTPS page (which I understand was actually a common browser default in the past). The OP's request went still further in that he wanted not to load *anything* by HTTP, even when HTTPS were not available. This policy would break some functionality on some pages, like preventing certain images from displaying. Some users might Of course. But that's the nature of browser security. Leaving Java and JavaScript disabled, as has to be done as part of securing a browser, breaks a lot of supposed functionality (a.k.a., security breaches). Using NoScript breaks more functionality, and using privoxy and/or AdBlock Plus and/or NoRedirect and/or Refresh Blocker will break still more. Disabling cookies does, too. Likewise for any pop-up blocker. How is breaking such functionality relevant if what one insists upon is a secure browser? think that's an appropriate trade-off because of the risks of unencrypted access. Currently HTTPS Everywhere doesn't include Exactly. any rules which deliberately do this when it would break some of the page's functionality. It's possible to implement that behavior on your own machine with either NoScript or HTTPS Everywhere if you know all of the relevant domain names (for example, for Wikimedia you might block access to http://upload.wikimedia.org/;). For Tor users, HTTPS Everywhere particularly provides
Re: Downloading attachments with Tor - is this secure?
On Tue, 22 Jun 2010 09:10:26 +0100 Matthew pump...@cotse.net top-posted (*please* stop doing that!): I am not using NoScript but I used it some time ago. The problem I had was that various websites did not work because it turned off JavaScript which seemed essential. At the moment I am using Polipo and Tor with JavaScript operational but Java, Flash, and QuickTime are all turned off in Firefox. Well, that's rather the point, isn't it? Besides, NoScript has always allowed you to whitelist sites that you *trust entirely*. Further, you can allow script execution globally, but you'd be utterly foolish to do so in a browser not running thoroughly sandboxed. Perhaps you could please tell me why exactly NoScript is superior to the methods I am using? Aside from the aforementioned feature of disabling script execution by default, it provides many other protections, far too many to go into here. Read about them at the NoScript web site at http://noscript.net NoScript should be used with Firefox even when tor is not used. NoScript should be used with Firefox even when Torbutton is not used, but it is much safer to use both NoScript and Torbutton together. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: SSL only firefox add-on?
On Thu, 17 Jun 2010 19:47:44 + judaiko judaiko siriu81...@gmail.com wrote: Let me say this first: One company had a firewall that blocked all non SSL traffic. So if you go https://mail.google.com and you sign in, it will stop you at one URL which was not https. I am not sure if Gmail still does this i.e. redirect you to non https (http) url after login, and then again go into https mode when you enter gmail. So this firewall used to give error saying not allowed, but when you changed it to https, the previous Gmail redirect url worked, and I could login to Gmail. Now is there an add-on that does this in Firefox? As noted previously: 1) Firefox should not be used without NoScript, and 2) NoScript allows the user to specify sites for which it will force the use of HTTPS. Block ALL http traffic by default? Then maybe like how Adblock plus is - Disable on this page only allows http traffic only for that page? AFAIK, NoScript doesn't discriminate among individual pages, only by host+domainname. It does allow the use of wildcards in the names. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
On Sat, 12 Jun 2010 13:15:47 +0200 Moritz Bartl t...@wiredwings.com wrote: On 12.06.2010 13:13, Marco Bonetti wrote: On 12/giu/2010, at 12.49, Moritz Bartl t...@wiredwings.com wrote: The barrier to create hidden services is quite high. I'm not too sure about this: you can run hidden services on tor clients which do not relay any traffic for the network. Starting a service is not that difficult: an home flat Internet connection and a low power computer are ideal for a small personal hidden service. That machine should be up 24/7, and you still need to maintain (ie. update) it. What a strange thing to say! How can you credibly claim to know the availability requirements for other persons' hidden services? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: DerAufbruch{,1,2} nodes not in a Family
On Tue, 01 Jun 2010 02:42:09 + Orionjur Tor-admin tor-ad...@orionjurinform.com wrote: Scott Bennett wrote: There are three nodes currently listed in the directory by the names of DerAufbruch, DerAufbruch1, and DerAufbruch2 without contact information that are not configured into a Family. If you wish to have your tor client treat them as being in a single node Family, just add the following to your torrc file. Very thanks for your information, Scott, It is a pitty that I have read this mail only today. Is it useful to include that line in the torrc-file on my tor-node (I don't use it as a client) or it useful only for tor-clients? AFAIK, it is used only for route selection prior to construction of a new circuit, which is a client activity. P.S. It seems like somebody begin many attacks to the Tor-network, DerAufbruch1, perfect-privacy.com...) I assume that tor is always under attack, but this sort of thing most commonly is not intended as an attack, but is rather due to the failure of some people to read and understand the documentation before using tor. I don't see it as being any different from those who hook up their new TV/DVR/ VCR/stereo systems without deigning to open and read the manuals or other documentation(*) included in the boxes. * Functional illiteracy is apparently now *assumed* by many/all cellular phone manufacturers as evidenced by their elimination of manuals in the packages and the inclusion instead of a folded sheet or small, stapled pamphlet with basic, often pictorial instructions for a very few of the phones' functions and capabilities. The user is apparently expected to figure out anything he/she needs to do with the phone by trial and error. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
DerAufbruch{,1,2} nodes not in a Family
There are three nodes currently listed in the directory by the names of
DerAufbruch, DerAufbruch1, and DerAufbruch2 without contact information that
are not configured into a Family. If you wish to have your tor client treat
them as being in a single node Family, just add the following to your torrc
file.
# The following are the DerAufbruch{,1,2} nodes, which have not been
# configured into a Family and have no contact information in their
# descriptors.
NodeFamily
$9631AB3D9F17A9DF23C4A427DCDE17C38E27E54B,$F334E6A865F58B170428E773F2F1C5AED452E087,$72EABEEEA8290EE39A44A3E06676071B98D17EBD
(Beware of linewrap in the NodeFamily line above.)
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 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: DerAufbruch{,1,2} nodes not in a Family
On Sun, 30 May 2010 15:48:54 -0400 Flamsmark flamsm...@gmail.com wrote: Is there a page on the wiki that contains suggested families? It's great I don't know. that we have people like Scott to find these families, and it's great that he sends them out to the list. However, new users, new subscribers to the list, and so on will have difficulty accessing them. The list archives are quite hard to browse, and it would make sense to have this info in one Absolutely. The archives' usefulness suffers seriously from the lack of search functions. I tend to cringe and procrastinate whenever it looks like I'll have to dig through them for something. :-} place. Scott, could you start a page with this info? Perhaps, but I'm not sure that's the best way to deal with it. It seems to me that this is a security issue much like the bad exits issue, so maybe the directory authorities ought to have a way of enforcing Family groupings in a manner similar to the BadExit flag or the Invalid flag. Any thoughts on this from others, including 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: HTTPS Everywhere Firefox addon
On Fri, 28 May 2010 15:19:25 +0300 What you get is Not what you see wygin...@gmail.com wrote: On Fri, May 28, 2010 at 3:09 PM, Stephen Carpenter thec...@gmail.com wrot= e: On Fri, May 28, 2010 at 7:47 AM, =A0and...@torproject.org wrote: On Thu, May 27, 2010 at 07:34:01PM -0700, mikepe...@fscked.org wrote 1.7= K bytes in 51 lines about: : The eventual idea is to allow an Adblock Plus style model, where users : can submit and exchange rule files and eventually create subscriptions : for the sites they use that partially support SSL. Perhaps this is a dumb question, why not try the https:// version of every http site the user requests? =A0If it works, reload to the https url. That sounds great about 90% of the time. However, think of someone who is troubleshooting something or is dealing with a site that has https and http content that are not the same, but may share the same URLs (or URLs that at least don't error). Doing it by site according to rules makes a lot of sense, that way I just can leave out rules for any special sites, or sites that I might personally be working on and need to be able to use both ways (testing to be sure it works for the masses) -Steve There may be an option to force https for each site requested.Or there may be an add site feature. What seems to be missing from this discussion is the fact that NoScript already supports forcing HTTPS on a site-by-site or pattern basis. You should be using NoScript already if you use Firefox, so just tell it what to do. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: HTTPS Everywhere Firefox addon
On Fri, 28 May 2010 12:55:19 -0700 Seth David Schoen sch...@eff.org wrote: Scott Bennett writes: What seems to be missing from this discussion is the fact that NoScript already supports forcing HTTPS on a site-by-site or pattern basis. You should be using NoScript already if you use Firefox, so just tell it what to do. There's one piece of additional functionality that was added in HTTPS Everywhere that can be important for these sites. Although NoScript lets you use regular expressions to choose which URLs within a site get converted to HTTPS, NoScript doesn't let you rewrite _the URL itself_, which HTTPS Everywhere does (also using regular expression substitutions). For example, the current alpha version of HTTPS Everywhere correctly handles Wikipedia rewrites like http://en.wikipedia.org/wiki/Security -- https://secure.wikimedia.org/wikipedia/en/wiki/Security http://de.wikipedia.org/wiki/Sicherheit -- https://secure.wikimedia.org/wikipedia/de/wiki/Sicherheit http://pt.wikipedia.org/wiki/Segurança -- https://secure.wikimedia.org/wikipedia/pt/wiki/Segurança That is a nice feature! Two questions now occur to me. Will this add-on become available from the Mozilla web site? And are there any interaction problems between HTTPS Everywhere and NoScript? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gwget and tor?
On Thu, 27 May 2010 12:49:26 -0600 Jim jimmy...@copper.net wrote: Scott Bennett wrote: On Wed, 26 May 2010 09:40:29 -0400 Aplin, Justin M jmap...@ufl.edu wrote: I don't know about gwget, but plain wget supports http proxies, which you can point at Polipo. If you're only going to need to do this every once in a while, I'd pop open a terminal and do the following: HTTP_PROXY=127.0.0.1:8118 HTTPS_PROXY=127.0.0.1:8118 FTP_PROXY=127.0.0.1:8118 export HTTP_PROXY export HTTPS_PROXY export FTP_PROXY wget your://url.to/download.here Once again, I strongly recommend that you set the *_proxy environment variables to full URLs rather than to the abbreviated forms you've shown above. See fetch(3) in the man pages for details. Hi Scott, This is the second time I've seen you reference the fetch(3) man page, so I thought maybe I should post. I believe you run one of the BSDs. Just FYI, I cannot find a fetch man page on my Linux systems. I know that several years ago when I was proxying Lynx I looked up this information /somewhere/. I thought it was in some man page but I cannot find it now. Maybe I pulled the info off the web? scratches head http://www.freebsd.org/cgi/man.cgi?query=fetchapropos=0sektion=3manpath=FreeBSD+8.0-RELEASEformat=html 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gwget and tor?
On Wed, 26 May 2010 09:40:29 -0400 Aplin, Justin M jmap...@ufl.edu wrote: On 5/26/2010 7:39 AM, emigrant wrote: is there a way to use gwget with tor? most of the times i download a direct link in tor enabled firefox it stops in the middle despite the internet connection is good. I don't know about gwget, but plain wget supports http proxies, which you can point at Polipo. If you're only going to need to do this every once in a while, I'd pop open a terminal and do the following: HTTP_PROXY=127.0.0.1:8118 HTTPS_PROXY=127.0.0.1:8118 FTP_PROXY=127.0.0.1:8118 export HTTP_PROXY export HTTPS_PROXY export FTP_PROXY wget your://url.to/download.here Once again, I strongly recommend that you set the *_proxy environment variables to full URLs rather than to the abbreviated forms you've shown above. See fetch(3) in the man pages for details. If that doesn't work for you, open your Polipo configuration file and see what port it's set up to run on, and change the bit after the colon in the environmental variables. Wget will pick up on the environmental variables and should route your download through Tor. These settings will only last until you either close the shell, or until you log out (I forget which and can't make it to my linux box to check), so if you'll be doing this a lot you can add the following lines to your .wgetrc file to have them executed automatically: proxy = on HTTP_PROXY = 127.0.0.1:8118 HTTPS_PROXY = 127.0.0.1:8118 FTP_PROXY = 127.0.0.1:8118 See note above. To resume an interrupted download, just add the -c option, like so: wget -c your://url.to/download.here 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[OT] another proxy, but not open source :-(
I don't know who Censorship Research Center might be, but they claim to have a development project going for another encrypted proxy service. However, they say it will be free software, but *not* be open source, so no one can examine what they have done in order to look for bugs, design flaws, etc. :-( There isn't much real information at the web site, http://www.haystacknetwork.com but what little there is looks very much like an attempt to sucker people who don't understand much about security. Oh. I almost forgot. Their FAQ page mentions tor, complaining about tor's publicly available directory and arguing that their method is better, while not mentioning bridges. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] another proxy, but not open source :-(
On Tue, 25 May 2010 03:30:34 -0400 Justin Aplin jmap...@ufl.edu wrote: On May 25, 2010, at 2:45 AM, Scott Bennett wrote: I don't know who Censorship Research Center might be, but they claim to have a development project going for another encrypted proxy service. However, they say it will be free software, but *not* be open source, so no one can examine what they have done in order to look for bugs, design flaws, etc. :-( There isn't much real information at the web site, Without the community support, I wonder how quickly it could be adopted. I'm assuming it's going to rely on user-run exits like Tor, You may well be assuming too much. It's not easy to know at this point because it's still undocumented vaporware. I still think the whole thing smacks of being a honeypot for gullible humans. and I wonder how many large contributors would be willing to install closed-source software that they're not involved in developing on their servers. Well, that, at least, happens all the time. How many installations of Windows Server 200[38] would you guess there are, for example? but what little there is looks very much like an attempt to sucker people who don't understand much about security. Oh. I almost forgot. Their FAQ page mentions tor, complaining about tor's publicly available directory and arguing that their method is better, while not mentioning bridges. Haters' gonn' hate. I'll admit, though, that using bridges might be a bit above the average user, especially when it comes to finding them. Not exactly plug-n-play. I also don't see why it would be terribly difficult for a sufficiently determined government to amass a large list of bridges and make that option essentially (if not completely) inviable. China has done that at least once already. They apparently managed to get ~80% of what the bridge authorities had at the time, IIRC. Yet the remainder continued to operate and serve many people in China during that time. And bridges come and go, just like ordinary relays. Many are on dynamically assigned IP addresses, so their addresses change, thereby invalidating those data in the Chinese government's list. I am a tad unnerved at the number of links to the donation page, though I appreciate the costs associated with such an endeavor. Indeed. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] another proxy, but not open source :-(
On Tue, 25 May 2010 05:55:34 -0400 Aplin, Justin M jmap...@ufl.edu wrote: On 5/25/2010 4:59 AM, Scott Bennett wrote: You may well be assuming too much. It's not easy to know at this point because it's still undocumented vaporware. I still think the whole thing smacks of being a honeypot for gullible humans. I'll admit I could be totally off base. But it's 5 in the morning and I honestly can't think of another way they could implement what they're trying to do (effectively, anyway) without an enormous infrastructure. Cheapest way to create one seems to be distributing your free software and having your users act as... oh wait, somebody thought of that already! :-) Well, that, at least, happens all the time. How many installations of Windows Server 200[38] would you guess there are, for example? Maybe I've been out of the game for too long, but in my experience proprietary software is used either because it works well, or because it Proprietary means the client companies pay for it, right? Which means they are funding its development, right? Windows Server releases are closed source, right? And client companies install and use it, right? Now, none of that tells us how many large contributors would be willing to install closed-source software that they're not involved in developing on their servers, but I should think that the number may be fairly large. comes with support (i.e. insurance). The Windows servers, for example, work well in corporate environments running a large number of Windows machines in a Domain, and often said corporation will purchase support to go with it. It's worth the cost to keep things running (somewhat) smoothly. If you have a free alternative that works just as well and can be maintained by your staff without too much ado, odds are it will be used. Apache on *nix comes to mind as one example, as opposed to IIS. So if we have two free softwares, one open-source and one closed-source, neither with any *explicit* support, the choice is going to come down to which one works better, and which one looks better. If they put out a crappy product, odds are it'll get uninstalled by the majority of users who just don't want to bother fucking with it. If it's a decent product, however, and it has a decent UI, and their production team can keep up with releases and bugfixes and whatnot, we may be in for some viable competition. We'll see. Somehow I doubt it. China has done that at least once already. They apparently managed to get ~80% of what the bridge authorities had at the time, IIRC. Yet the remainder continued to operate and serve many people in China during that time. And bridges come and go, just like ordinary relays. Many are on dynamically assigned IP addresses, so their addresses change, thereby invalidating those data in the Chinese government's list. The picture in my head reminds me of this, for some reason: http://xkcd.com/350/ Nice call! ;) I am a tad unnerved at the number of links to the donation page, though I appreciate the costs associated with such an endeavor. Indeed. As an aside, they do have a shiny-looking website, and I won't pretend users aren't attracted to that. We could do with a little shininess ourselves. Still though, pandering for donations when you're not even offering any sort of product or service... honeypot indeed. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] another proxy, but not open source :-(
On Tue, 25 May 2010 13:33:23 -0400 Ted Smith ted...@gmail.com wrote: On Tue, 2010-05-25 at 01:45 -0500, Scott Bennett wrote: I don't know who Censorship Research Center might be, but they claim to have a development project going for another encrypted proxy service. However, they say it will be free software, but *not* be open source, so = no one can examine what they have done in order to look for bugs, design fla= ws, etc. :-( There isn't much real information at the web site, =20 http://www.haystacknetwork.com =20 but what little there is looks very much like an attempt to sucker people who don't understand much about security. Oh. I almost forgot. Their FAQ page mentions tor, complaining abou= t tor's publicly available directory and arguing that their method is bette= r, while not mentioning bridges. I saw this a while ago. From what I could get from their website, it What drew my attention to it was a small newspaper column in yesterday's _Fib_ (a.k.a. _Trib_ a.k.a. _The_Chicago_Tribune_) that I saw at a coffee shop. The author was all ga-ga about it, praising Austin Heap as if he should be canonized ASAP for his wonderful work for freedom of speech. Being somewhat of a skeptical nature, I looked up the web site referred to in the article when I got back to my apartment last night. I couldn't figure out why the author, Kurt Knutson of WGN TV, was so taken in by something that isn't even available yet and about which there is so little publicly available information. looks like they'll be running single-hop proxies from various hosts, and distributing that list inside the proprietary software they distribute That's more than I managed to extract from it, but that certainly looks very bad if that is indeed what they are doing. (IIRC). They also say they'll be using HTTP as the transport protocol, which means either that the content will be unencrypted or that it'll be tunneled through HTTP.=20 I wonder if they'll sign the binary blobs they distribute; it would be very easy for the police in any country to distribute their own backdoored version (via sneakernet) and just arrest everyone who uses it. Maybe they'll sign it with their own in-house equivalent to PGP, too. :-} 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Exit Node hosting: torservers.net
Mike and Moritz, Would you both *please* stop posting each message to multiple lists? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Answer by perfect-privacy.com Re: perfect-privacy.com, Family specifications, etc.
On Thu, 20 May 2010 08:23:34 +0200 (CEST) Sebastian Hahn m...@sebastianhahn.net wrote: All that would do would be to say to all clients, Don't include this node in the same circuit as any of the blutmagie nodes. How would that be an attack? I can list all the nodes I don't control... What is the limit on line length for such a MyFamily statement? What is the limit on descriptor length? Listing ~1500 nodes sounds like the sort of thing that wouldn't work very well. Also, my other question remains: what would stop me from listing nodes that I don't control in a MyFamily statement now? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: perfect-privacy.com, Family specifications, etc.
On Thu, 20 May 2010 07:37:17 + The23rd Raccoon the.raccoo...@gmail.com wrote: On Thu, May 20, 2010 at 5:47 AM, Scott Bennett benn...@cs.niu.edu wrote: =A0 =A0 On Thu, 20 May 2010 00:40:42 -0400 =3D?utf-8?Q?Jerzy_=3DC5=3D81og= iewa?=3D jerz...@interia.eu wrote: I apologize for altering the nature of this thread, but can someone =3D please summarize what this discussion is about? Who is =3D perfect-privacy.com and why are they of concern to Tor users? I am =3D having a difficult time following the threads. =A0 =A0 If you subscribed to this list after the start of the thread, jus= t go to the list archives, and look for my original message. =A0It should all then become clear. This suggestion, coming from you, is especially hilarious. You haven't yet successfully preserved a single thread you are present in. You really need a mail client from this millennium. STFW for 'In-Reply-To header'. As anyone who has been around long enough is aware, the thread is the content of the Subject: header, not the content of any USENET newsreader- derived, latecoming header. The only times I have failed to preserve the content of the Subject: have been on other lists, where I receive messages in digest form and have made an error in editing. Now, having stated that again, I just went to the archives page and found it in seconds, so it certainly wasn't difficult at all. http://archives.seul.org/or/talk/May-2010/msg00108.html (Sorry for the noise or-talk, I was obliged to comment at that hypocrisy. I'll go back to rummaging through the trash for delicious snacks and discarded research papers now.) Your comment is misplaced, given that I have repeatedly stated on this list that I am *not* the system administrator of this system and that I do *not* install or delete software on this system. I have nothing at all to do with it. P.S. I too had a bit of a problem following exactly why MyFamily has to be this cumbersome. If Tor clients are already doing pair-wise Ah. I see. You wait until your post script to discuss the subject at hand. checking anyways, why can't all nodes just refer to a 'mother' node's descriptor that lists a family key that can be used to sign a simpler family statement. Or, just limit the number of families a node can be Yes, that was essentially the suggestion of Bruce from perfect-privacy.com. a part of to just one, specified by a UUID, to limit the damage they can do. Also, I still fail to see why having extra nodes (i.e., nodes *not* under the control of a given node's operator) creates any real problem. I suppose in a tiny, experimental network, one could pretend that such a threat might exist, but in the real world, I just don't see it. Further, Bruce's suggestion avoids the issue entirely by requiring each node to subscribe *itself* to a Family by specifying only the key/ name/other type of identifier of that Family. Sebastian's attack could not be done. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
Oh. My. Goodness. Gracious! I go to sleep for a few hours, and the discussion descends into total confusion because a number of participants, including some tor developers, did not bother to read the proposal by Bruce from perfect-privacy.com. He did *not* propose, for example, any equivalent to #include statements. He did *not* propose, for example, any method of allowing a node to specify other members of a Family. Let's see if we can get the discussion back on track. Please read below carefully. On Thu, 20 May 2010 10:44:44 -0400 Andrew Lewman and...@torproject.org wrote: On Thursday May 20 2010 09:39:00 Flamsmark wrote: On 20 May 2010 07:44, and...@torproject.org wrote: If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. That was not Bruce's proposed method. Please go back and read it carefully. Why would this screw everyone? If only one side could declare a valid family that clients honored, you can control the paths clients choose. Eventually, some large percent of the network will find your declaration and be unable to build paths because they are all in the one-sided MyFamily declaration. Or, worse off, you run three nodes, let's call them TheMan0, TheMan1, and TheMan2. All three nodes list every other node in the network, except your three TheMan# nodes. Now as clients find your MyFamily declaration, they can only build paths through TheMan0, TheMan1, and TheMan2. Now you've won. Bruce's proposal prevents any such possibility because it does not allow specification of any nodes by Nickname, key fingerprint, or any other method. Rather, it allows a node to identify a Family by some Family name or other label of which it itself is a member. Alice runs nodes A1, A2, and A3. In the torrc file of each would be a line like MyFamily We'reOff Bob runs nodes B1, B2, B3, and B4. Each of his nodes' torrc files contains a line like MyFamily toSee Carol runs nodes C1 and C2. Both of these nodes' torrc files contain the following line. MyFamily theWizard Now, Dave has a client that downloads the descriptors for all of Alice's, Bob's, and Carol's nodes. Seeing the Family name each node says it belongs to, the client groups Alice's nodes into one Family, Bob's nodes into another Family, and Carol's nodes into a third Family. Dave's client then chooses routes for circuits that will use no more than one node from each Family, just as clients do now. If Ed comes along and fires up a node E1 that says, I'm in toSee Family, then if Dave's client chooses E1 for a route, it will not choose any of Bob's nodes for other positions in the same route. Likewise, if Dave's client chooses any of Bob's nodes for a circuit, Ed's E1 node will not be used for other positions in the same circuit. Ed, however, has no way to force Dave's client to choose Ed's nodes for circuit routes. This is one reason why the MyFamily declaration has to be the same on both sides in order for clients to honor it. Tor clients do not trust the Tor network by design. There are flaws in the MyFamily scheme, as we're seeing with perfect-privacy. It's a pain in the ass if you run a lot of nodes, so you just don't bother. It also assumes an honest relay operator will list all of all the nodes that should be in a MyFamily declaration. Again, that is completely inapplicable and irrelevant to Bruce's proposed method. To reiterate, his method enables each node to tell clients, I'm in Family xyz. Don't use more than one of us in a circuit. It does not allow any node to specify other nodes. A node simply specifies the name of a Family to which it belongs. Jeesh. It's really not very difficult, and no, it is not vulnerable to the sort of attack you, Roger, and Sebastian have now misdirected the discussion. Sigh. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Answer by perfect-privacy.com Re: perfect-privacy.com, Family specifications, etc.
On Thu, 20 May 2010 12:31:17 +0200 Moritz Bartl t...@wiredwings.com wrote: On 20.05.2010 06:25, Roger Dingledine wrote: The trouble here is that if we make family declarations one-sided, then I can tell everybody that I'm in blutmagie's family (and X's family and Y's family and Z's family and ...), and suddenly I'm influencing the path selection of other clients in a way I shouldn't be able to. Maybe it is a misunderstanding on my side, but I agree with Scott. How could this influence the network in a way that one can speak of an attack? My idea was that by stating a family, I say that *my node* musn't be used in a circuit together with other members of that family, no more, no less. So, by misconfiguring the family on my side, I cannot hurt the network more than (in the extreme) by running no node at all. Exactly. Thank you, Moritz. Roger just didn't read what Bruce wrote. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
Hi Paul, On Thu, 20 May 2010 15:12:38 -0400 Paul Syverson syver...@itd.nrl.navy.mil wrote: On Thu, May 20, 2010 at 01:44:36PM -0500, Scott Bennett wrote: Oh. My. Goodness. Gracious! I go to sleep for a few hours, and the discussion descends into total confusion because a number of participants, including some tor developers, did not bother to read the proposal by Bruce from perfect-privacy.com. He did *not* propose, for example, any equivalent to #include statements. He did *not* propose, for example, any method of allowing a node to specify other members of a Family. Your interpretation of what Bruce said makes sense. But it is not how I parsed, BelongToFamily xyz in his message. I read it the same way it seems that Roger did, as giving a list: node x, node y, and node z. And then we're off and running. I think what Bruce/you You parsed xyz as meaning x,y,x or perhaps x y z? How bizarre. Even the current MyFamily statement doesn't do that. suggest is better than what I proposed to avoid the problems Roger and Andrew noted. As I said before, it's not how MyFamily now works. And I No, indeed it's not. Bruce was proposing an alternative method, one that looks far more sensible than the current method. believe Andrew/Roger/me/others were addressing trying to use the existing functionality in a different way, which was another disconnect. Anyway, this is certainly an idea worth considering. Now, should you ever say you are in multiple families at once? That's an interesting question, and I'm not sure of the answer. However, it's worth noting that it would not open any useful attack because each time a node adds itself to a Family reduces by some amount its probability of being selected for a route. And should there be a lattice structure for families, hmmm? ;) Not sure what that would accomplish. Seems to me that a client would maintain a list of Family names that it has encountered. Each time it encounters a descriptor with a Family name not already present in its list, it would add a new entry for that Family to the list. Each node claiming membership in a Family would have an membership entry linked off of the appropriate entry in the Family list. When a new descriptor for a node is encountered, it would be checked for Family designation(s) against the appropriate membership list(s) to see whether the membership list(s) should be updated. If a node vanishes from the directory, its memberships should be removed. If an entry in the Family list ends up with no membership entries linked from it, then that Family entry should be removed from the Family list. It's just mundane list maintenance stuff. Shouldn't be a big deal. Each node's descriptor entry in tor's internal representation of the directory would link directly to the appropriate Family list entry. If multiple Family designations are permitted for a node, then the internal directory entry would instead anchor a short list of pointers to the Family list entries. I suppose a bit could be reserved somewhere nearby that would say whether the field in the internal directory entry were a direct pointer or a list anchor in order to accommodate the most likely case, namely, that a node would be a member of, at most, a single Family. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Answer by perfect-privacy.com Re: perfect-privacy.com, Family specifications, etc.
On Thu, 20 May 2010 00:25:33 -0400 Roger Dingledine a...@mit.edu wrote: On Mon, May 17, 2010 at 09:44:21PM +0200, Moritz Bartl wrote: Original Message Subject: Re: - Medium - Tor servers, Tor community wants to disable your nodes - General Date: Mon, 17 May 2010 13:46:04 +0200 From: Perfect Privacy Administration ad...@perfect-privacy.com Organization: PP Internet Services [snip] A proposal to the TOR developers: I don't know if it's technically possible, but maybe one could introduce a BelongingToFamily entry or a similarly named command in future versions of TOR which could work as such, as that every server which contains the same BelongingToFamily entry (e.g. BelongingToFamily xyz) belongs to the family xyz. That way one wouldn't have to enumerate all server names in the MyFamily section of each and every individual torrc file what causes an enormous effort if one adds a lot of servers (and donates a lot of traffic) to the Tor network. As mentioned, we currently would have to edit 45+ torrc files on 45+ TOR servers whenever a server is added or removed, and the number of our servers is constantly increasing. The trouble here is that if we make family declarations one-sided, then I can tell everybody that I'm in blutmagie's family (and X's family and Y's family and Z's family and ...), and suddenly I'm influencing the path selection of other clients in a way I shouldn't be able to. How would that be any different from me adding a MyFamily statement of the current form to my node's torrc that included all four blutmagie nodes? We need to have each set of relays in a family declare the others, or it's open to attacks like this. All that would do would be to say to all clients, Don't include this node in the same circuit as any of the blutmagie nodes. How would that be an attack? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: perfect-privacy.com, Family specifications, etc.
On Thu, 20 May 2010 00:40:42 -0400 =?utf-8?Q?Jerzy_=C5=81ogiewa?= jerz...@interia.eu wrote: I apologize for altering the nature of this thread, but can someone = please summarize what this discussion is about? Who is = perfect-privacy.com and why are they of concern to Tor users? I am = having a difficult time following the threads. If you subscribed to this list after the start of the thread, just go to the list archives, and look for my original message. It should all then become clear. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
NodeFamily statement to fix the perfect-privacy.com problem
For anyone else who is interested in having no more than one hop of any given circuit constructed by their tor client to be a perfect-privacy.com hop, just add the following to your torrc file, and send tor a SIGHUP. Please pardon the run-on line, but without answers to the questions I posed earlier here, I have to assume that it is necessary to list every node that should be in a single Family on the same NodeFamily statement. Just copy and paste. # The following are the perfect-privacy.com nodes, which their operator(s) # failed to group into a single Family specification NodeFamily $0D5D6C7BDE53A1D1A65C083440099DD0729D69FE,$AA24083148432D665D370649EDD7815FC184D61D,$6D080ECCAA6D65DC68E1B3B50E8F199FA9ADA04C,$8BD39755B5CAA9C060CA4AEAC024B9AE0DBF1DE1,$B555A2B276678135EFE6F0F8173F21579BF1CACD,$698099D22DA44C543656F30C8B7FEAD3905C3268,$6CDC0D7AAA97214DD6C4F3BD43ACD28F220D7967,$B1114339D7392BCDCEF6D5D14269CA941A988EA7,$A2C05FEE9D8B08793D6312694BBF6A20F480D57F,$34A46B317DCAD4CA52C449D3AF3786344EE75054,$64E8787C3A9B4CD13A0104FE29ABEA367954D124,$8C63F2742DD4E56413BE89D3441372B57796A597,$DA0E7FE627F9C64D44FE85821B6BD0F08D8725E3,$EE86965F7B25806BF5F056E6B7EB042E3C51,$9D3007FFE14CA19721AE8A961CB5CF81C436758F,$03D3F63B7DABD3413074F8E9996E7A9C1EFD4ADE,$E08DB33E447EF7A82804875F9400A6B378A1B92E,$FEE06055B622C3FF26A93651B840829A629C66F4,$9479D745380DDC1AA5F56EAB28B4EB4B18CFECFB,$7299B48FBE94394DDBB02F03AA262E0FB2C544D1,$65F118FD5BD158FA10C833D6E210DFB8457E0A6C,$A92C8E3A134F915E15DDEF12D374A3BD469A600B,$5B3EFAA427945B1A3EB364922A897A7A4759C7E2,$13CA99FA910! 772C249AF3CFF57F2D3BA233E7A82,$4FEF67238E4A8FBD90A9A4688B25F243CFDA7676,$D6B853609274A578869E6FA3084601086BADE9A0,$1ADABAC444018AB38B672F53E067EC9F3740D1FA,$ECB6B881832DC51712119E720C2B2B96B6405B11 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: perfect-privacy.com, Family specifications, etc.
On Sun, 16 May 2010 23:18:59 +0300 =?UTF-8?Q?ilter_y=C3=BCksel?= ilteryuk...@gmail.com top-posted (please don't do that): Isn't there any way to detect automatically if these 28 relays in same family? Why do you need configure your torrc file manually? See the MyFamily statement's description in the tor man page. Then look at what I posted before about the perfect-privacy.com nodes being misconfigured w.r.t. Family designations. Their operator(s) did it wrong and have not responded to email sent to the address in those nodes' contact information. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: why is the traffic not more linear?
On Fri, 14 May 2010 01:04:11 -0400 and...@torproject.org wrote: On Wed, May 12, 2010 at 10:22:49AM -0400, michael.gom...@gmail.com wrote 1.6K bytes in 47 lines about: : significant parts of my torrc: : : RelayBandwidthRate 100 KBytes # Throttle traffic to 100KB/s (800Kbps) : RelayBandwidthBurst 200 KBytes # But allow bursts up to 200KB/s (1600Kbps) : : AccountingStart day 00:00 : AccountingMax 10 GB You told Tor to only do 10GB of transit a day. I suspect your relay spends lots of the day hibernating waiting for the next accounting period to start. Unfortunately for that argument, 100 KB/s * 86400 s/d = ~ 8.24 GB. Given that a relay typically averages about half the target limit, my take on this is that we don't have enough information to determine why he sees what he does. He really didn't tell us what sort of variability he see anyway. Does he mean that it is erratic on a minute-to-minute basis? Or at various times of day? The graphs at the link he gave appeared damaged in Firefox, appearing as straight, horizontal lines (yes, plural) in and below the graph boundaries. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
perfect-privacy.com, Family specifications, etc.
There is someone going by the name of perfect-privacy.com who is listed in the contact information of roughly 28 relays' descriptors with widely varying throughput capacities in the tor directory. These relays' descriptors are grouped into quite a few separate Family specifications, although some appear to be orphans without a Family. I wrote to the address given in the contact information to ask them to explain/justify their peculiar non-conformance to the rule about Family specifications, stating that I would post to this list quite soon, but wanted to give them a chance to explain/justify their actions first. That was at 13:25 CDT on 11 May 2010. I have not received any response. (So much for the contact information...) I would appreciate having these relays lose their Valid flags in the consensus until such time as their operator(s) group all of them into a single Family specification. I hope the authority operators will take this action in a timely fashion. Until this situation is dealt with, it will remain entirely possible that clients may build circuits whose entire routes consist of perfect-privacy.com's nodes. FWIW, I have not thoroughly combed the directory for similar cases. It is entirely possible that others exist, but for now, it would be good to eliminate the violators ASAP. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
On Sat, 8 May 2010 22:49:26 + (UTC) John Case c...@sdf.lonestar.org On Sat, 8 May 2010, Mike Perry wrote: This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. Thanks. So, it's hard to say, but I can assume there will be significant exit traffic, even with just one TCP port valid for exit... I suppose I could see the ratio of actual connections by simply running 'netstat', yes ? If my orport and dirport are 9001/9030, and I am allowing port 80 exit, then all netstat connections showing port 80 are exit connections, so I could (roughly) calculate these numbers myself, right ? No, not really. That method does not distinguish between connections going to actual web servers and connections going to other tor relays that listen on 80 as their ORPort or DirPort, of which there are quite a few. You would need to compare each address and port number with the addresses and port numbers listed in the directory to determine which case you were seeing. Also, netstat doesn't tell you whether your system connected to the other end or vice versa. pftop(8) does identify connections as being inbound (I) or outbound (O), but if you don't have pf(4) support on your system (OpenBSD and FreeBSD only, I think), then you don't have pftop available. I don't know what similar tools may be available for use with other systems. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Using tor as proxy for the command line
On Thu, 06 May 2010 11:05:17 +0200 Jacob Appelbaum ja...@appelbaum.net wrote: Scott Bennett wrote: On Wed, 5 May 2010 20:22:55 +0200 Borja Luaces borja.lua...@gmail= =2Ecom wrote: I would like to know if it is possible to use tor as proxy for the com= mand line under linux (Ubuntu). If it is possible, how can I do it? PS: I would like to proxymise all the comunications from the command l= ine (wget, nmap,...) Note that wget(1) abides by the ftp_proxy and http_proxy environme= nt variables described in fetch(3). I suspect that torify(1) used with nm= ap will not be particularly useful to you nor would you endear yourself to= exit operators by doing that. =20 I wrote a little program to ease my use of wget with Tor/Polipo/Privoxy: % cat tor-wget #!/bin/bash -x export http_proxy=3D127.0.0.1:8118 export https_proxy=3D127.0.0.1:8118 wget -U $@ EOF I would recommend using the full form in each of those above. There are apparently a few cases where the abbreviated form you show here will not work. Also, you might define ftp_proxy; otherwise FTP requests will go directly, instead of being blocked by privoxy. Or if you have something like 3proxy installed, you could set ftp_proxy to use that, but I don't see a very easy way to stop DNS query leakage if you do that. I also started working on a patch to nmap with Fyodor to work with SOCKS proxies; it's in my (ioerror) svn branch on the nmap subversion server. It sorta works but it's not great for anonymity because of the many kinds of packets that nmap wants to send. I think using nmap in the context of tor is really barking up the wrong tree. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Using tor as proxy for the command line
On Thu, 06 May 2010 15:56:25 +0200 Jacob Appelbaum ja...@appelbaum.net wrote: Scott Bennett wrote: On Thu, 06 May 2010 11:05:17 +0200 Jacob Appelbaum ja...@appelbau= m.net wrote: Scott Bennett wrote: On Wed, 5 May 2010 20:22:55 +0200 Borja Luaces borja.lua...@gma= il=3D =3D2Ecom wrote: I would like to know if it is possible to use tor as proxy for the c= om=3D mand line under linux (Ubuntu). If it is possible, how can I do it? PS: I would like to proxymise all the comunications from the command= l=3D ine (wget, nmap,...) Note that wget(1) abides by the ftp_proxy and http_proxy environ= me=3D nt variables described in fetch(3). I suspect that torify(1) used with = nm=3D ap will not be particularly useful to you nor would you endear yourself = to=3D exit operators by doing that. =3D20 I wrote a little program to ease my use of wget with Tor/Polipo/Privox= y: % cat tor-wget #!/bin/bash -x export http_proxy=3D3D127.0.0.1:8118 export https_proxy=3D3D127.0.0.1:8118 wget -U $@ EOF =20 I would recommend using the full form in each of those above. The= re are apparently a few cases where the abbreviated form you show here wil= l not work. Also, you might define ftp_proxy; otherwise FTP requests wil= l go directly, instead of being blocked by privoxy. Or if you have somet= hing like 3proxy installed, you could set ftp_proxy to use that, but I don't= see a very easy way to stop DNS query leakage if you do that. I've reread the man pages for 3proxy and its author's other proxies since posting that. It appears that none of them will translate ordinary proxy protocols into SOCKS stuff, so please ignore my earlier comments regarding 3proxy. Any FTP connections will, at some point, be in the clear from your system and cannot be diverted through tor by ordinary FTP proxies. I don't understand what you mean by this? What do you mean full form? As documented in the man page for fetch(3), it should look like a URL. For example, http_proxy=http://127.0.0.1:8118 https_proxy=https://127.0.0.1:8118 export http_proxy export https_proxy How does this leak DNS...? No, I was referring there to the use of 3proxy as an FTP proxy, which I now see won't help here anyway, so just forget all that. I agree that ftp_proxy is probably a good idea. I've added that to the helper script. I also started working on a patch to nmap with Fyodor to work with SOC= KS proxies; it's in my (ioerror) svn branch on the nmap subversion server= =2E It sorta works but it's not great for anonymity because of the many kinds of packets that nmap wants to send. I think using nmap in the context of tor is really barking up the wrong tree. Perhaps, the goal was more general than Tor - it's specifically a set of patches for SOCKS5. Would you post your specifications for it, please? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Using tor as proxy for the command line
On Wed, 5 May 2010 20:22:55 +0200 Borja Luaces borja.lua...@gmail.com wrote: I would like to know if it is possible to use tor as proxy for the command line under linux (Ubuntu). If it is possible, how can I do it? PS: I would like to proxymise all the comunications from the command line (wget, nmap,...) Note that wget(1) abides by the ftp_proxy and http_proxy environment variables described in fetch(3). I suspect that torify(1) used with nmap will not be particularly useful to you nor would you endear yourself to exit operators by doing that. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
circuit construction timeout values
I've noticed something odd in info-level log messages that show circuit build timeout values being set. Given that the maximum length of circuit construction time history of 5000 construction times has already been reached, it seems weird to see huge jumps in the timeout values from one such message to the next. Here are two examples. Apr 27 16:16:08.917 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 68s (67721.267133ms, Xm: 6025, a: 0.665199) based on 5000 circuit times The next message of this form is Apr 27 16:16:08.917 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 68s (67721.267133ms, Xm: 6025, a: 0.665199) based on 5000 circuit times That one is followed by Apr 27 16:26:14.040 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 93s (93292.661928ms, Xm: 2525, a: 0.445889) based on 5000 circuit times Messages showing similar timeouts (i.e., 93-94 s) continue for quite some time. Then the following sequence occurs. Apr 27 18:15:53.967 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 94s (93616.547344ms, Xm: 2525, a: 0.445462) based on 5000 circuit times Apr 27 18:15:59.672 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 65s (64619.917420ms, Xm: 9075, a: 0.819887) based on 5000 circuit times So I'm wondering what is going on here. If the timeout being set is supposed to reflect some sort of smoothed values of a time series of circuit construction time, where the smoother is 5000 values wide, how can such jumps occur? I guess I don't understand what algorithm is being used here. Any clarification would be appreciated. Thanks in advance! 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Botnet attack? [was: Re: Declining traffic]
the tor directory on several occasions and found that there were as many as three relays operating at varying times with addresses in that range. As of that time, none of the relays' addresses appeared in my block list, so I first added a list of tor relay IP addresses from which connections to my relay's ORPort are passed before the block list gets applied. That list is updated every 30 minutes to match the current tor consensus most recently fetched by my relay. The upshot of all of this is that anybody mucking around with making illicit attempts to connect to my system gets their system added to the block list. From that moment forward, regardless of whether I someday have applications listening on other ports and regardless of what protocol or port number a packet is received from an address or address range appearing in my block list, will *never* get any response whatsoever from my system, except in the case of a tor relay running on such a system and appearing in the most recently fetched tor consensus. Such exceptions will be allowed to connect to the ORPort (and DirPort, too, if I am ever in a position to offer directory services again) for as long as their addresses appear in the consensus. An additional note I should make is that if an address appears in a /24 that already has one address in the block list, I replace that original entry with a large enough IP address range mask to cover both the original and the newcomer. I draw the line at /27, though, and don't make entries that are smaller than a /27 but larger than a single IP address. On a loosely related note, it would generally be a good idea to mask IP addresses on public mailing lists. That is a good idea for client IP addresses, to be sure. However, any relay already has its IP address made public in the consensus and the directory. And I have no qualms at all about making crackers' addresses as public as possible. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Botnet attack? [was: Re: Declining traffic]
On Tue, 27 Apr 2010 13:07:24 +0200 Hans Schnehl torvallena...@gmail.com wrote: On Tue, Apr 27, 2010 at 01:35:20AM -0500, Scott Bennett wrote: On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark flamsm...@gmail.com wrote: On 26 April 2010 09:59, Timo Schoeler timo.schoe...@riscworks.net wrote: (Deutsche Telekom AG). For me it really seems as there's some kind of botnet attack going on. What makes you think that this is a botnet attack? What are the characteristics of a botnet attack, and how do these logs exhibit them? If someone playing around, it's rather background noise... relax, guys ;) What my system logged over a two- to three-hour period was a very high rate of illicit connection attempts being logged, a rate much higher that usual and for an extended period of time. Some of the connection attempts involved only one or two tries for a single port number. However, consider another type that also occurred frequently during that time span. That other type looked more like an individual attack that came in this evening: [snip] 2010-04-26 23:38:20.086026 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3422 24.1.225.89.8080: tcp 16 [bad hdr length 12 - too short, 20] 2010-04-26 23:38:20.990386 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3416 24.1.225.89.8000: tcp 16 [bad hdr length 12 - too short, 20] 2010-04-26 23:38:25.214087 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3419 24.1.225.89.8001: tcp 16 [bad hdr length 12 - too short, 20] 2010-04-26 23:38:26.122380 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3422 24.1.225.89.8080: tcp 16 [bad hdr length 12 - too short, 20] [lot's of snip] There was a scan. yes. Happens. But these - [bad hdr length 12 - too short, 20] - are *NOT* a maliciuos attempt of something but rather a matte ofr tcpdump running against a pflog* interface. There are different expectations about the snaplen , so if increasse the snaplen to sth. higher than 68 bytes the message will disappear, it is rather harmless. Yes, yes, I understood all that. That wasn't my point. My point was that on the morning in question, I was getting scans similar to that example, each batch from a different IP address, as frequently as a couple of scans in two or three seconds, and that that kind of thing went on almost continuously for about three hours. That was the first time I had seen a protracted onslaught of such stuff on my system. There are probably many culprits that escaped getting added to my block list because after three hours of trying to add each address by hand, scrolling back and forth through the intermingled addresses in messages in an xterm, I was worn out and gave up. By the time I gave up, I had added over 220 addresses or address ranges. Then the onslaught stopped very abruptly and has not recurred. I still get several scans per day of varying sets of ports, just as I did before, but no further deluges of scans and individual port attempts coming from lots of different IP addresses. The event that morning was intense, but of finite duration. While we're on the subject of illicit TCP connection attempts, I'd like to mention something that I've noticed begin only in the last two months or so and seems to be becoming more frequent as time passes. At first, it was the occasional attempt to connect to port 9030, which became more frequent over the last few weeks. Then 9001 was added to that and has also been getting more frequent. In the last day or so, I've begun seeing 8118 in addition to those. Hmmm... 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Declining traffic
On Sat, 24 Apr 2010 06:45:38 -0400 Roger Dingledine a...@mit.edu wrote: On Fri, Apr 23, 2010 at 08:51:32PM -0500, Scott Bennett wrote: I hope that, in the future, openssl.org will make some effort to coordinate such things with the various operating system developers in a way that avoids turning the situation into such a cl*f*** again. It's obviously been a nightmare for you and the rest of the tor project, and I'd bet heavily that the tor project is not the only one so affected. But we haven't yet put out a stable release that includes that patch. So if you upgraded to the latest 0.2.2.x-alpha to get the fixes for other bugs, you would get the fix for this bug too. Let us know if it works. Are there any ideas floating around yet as to why tor doesn't work with openssl 1.0.0? It does work, as far as I am told. Or are you talking about yet another operating system vendor that crippled its openssl in some new way? I tried it from ports, so it's not the aborted version in the FreeBSD base system. I first posted about the problem on tor-relays earlier this month. http://archives.seul.org/or/relays/Apr-2010/msg9.html Ended up using portdowngrade to get back to 0.9.8n, which works just fine. I believe some of the BSDs took tls renegotiation out of their openssl entirely. It's quite possible they would be bold enough to declare that their openssl is the real openssl 1.0.0. The only answer there is to not use their crippled openssl. No, the version in the FreeBSD base system is a crippled 0.9.8e, IIRC. Has anybody else here tried Tor with openssl 1.0.0 and found that it worked / didn't work? Someone (perhaps Nick or Andrew--I don't remember who) posted a note before that to the effect that a 1.0.0-beta seemed to work with tor and was faster, to boot, which I was looking forward to. I didn't try the beta version, though, so I have no direct experience with it myself. The released version definitely does not work with tor. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Declining traffic
On Fri, 23 Apr 2010 15:51:59 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Apr 23, 2010, at 3:21 PM, Timo Schoeler wrote: thus Brian Mearns spake: Any chance your ISP is throttling you? 100% *not*. Another possibility would be that your relay is heavily overloaded. See the big thread on tor-relays about the problems and potential solutions [0]. Sebastian, there was something that looked very much like a botnet attack running for two or three hours this a.m. It seems to have stopped now. I had shut down my machine to install operating system updates. When all that was finished and I finally brought the system back up, for some unknown reason, pf did not start. (As if there were not going to be enough confusion as things already were. Sigh.) As soon as I noticed pf wasn't running, I started it manually and loaded a block list. But pftop continued to pour forth log entries of illicit connection attempts from untold numbers of IP addresses and to scads of different TCP port numbers. I kept stopping and starting the logging, so that I could see the log entries long enough to add the addresses to that block list. I eventually got crosseyed from adding somewhere between 200 and 300 IP addresses to the list. :-( When I then let the logging continue, it had stopped getting any new stuff to log. It was very intense while it lasted, but in the larger scheme of things, it was of very short duration for a coordinated attack. I doubt that my system was the onlyt tor relay being attacked. In fact, I think the attack began a short time after my node appeared in the consensus, although at this point I can't prove it. What I would like to know is how many systems were attacked this a.m. in that manner, were only systems running tor relays attacked, who shut it off, etc. If anyone else on this list noticed anything between 5:00 a.m. CDT and 8:00 a.m. CDT, please post the details here. Thanks! 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Declining traffic
On Fri, 23 Apr 2010 10:42:25 -0500 Jon torance...@gmail.com top-posted: I came across this info which may be related or not about the possible botnets. There is a new P2P botnet forming. The Trojan it uses is ' Heloag ' . this is the url that gives info about it: http://threatpost.com/en_us/blogs/new-p2p-botnet-forming-041310?utm_source= =3DThreatpost+Spotlight+Emailutm_medium=3DEmail+Marketing+-+CRM+Listutm_c= ampaign=3DThreatpost+SpotlightCID=3D this is the short url: http://threatpost.com/en_us/OTQ Hmmm...doesn't look like the same thing to me. What I saw were several hits per second, sometimes up to 10 or 20 per second, on all sorts of port numbers and coming from IP addresses all over the place. There is no malware running on my FreeBSD system (unless, of course, someone is afflicted with religious problems over that:-), so this system would not have registered itself at either of the sites mentioned in the latter article. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Declining traffic
On Fri, 23 Apr 2010 14:16:57 -0400 Roger Dingledine a...@mit.edu wrote: On Fri, Apr 23, 2010 at 02:35:01PM +0200, Timo Schoeler wrote: I'm seeing declining traffic over the last few weeks, please see graph: It dropped from a sustainted 2,5Mbps (or more) to about a fifth, with a massive drop today. I'm running tor-0.2.1.25-1.el5.rf on a 64Bit CentOS machine. Is there something going in the TOR network? My first thought is that you updated your openssl rpm in centos, which disabled tls renegotiation in yet another new way, and that broke your Tor relay. Meaning your relay still worked, but it would only do tls renegotiation with other people with centos's particular openssl twist. Tor 0.2.2.11-alpha fixes the issue we hope: - Fix SSL renegotiation behavior on OpenSSL versions like on Centos that claim to be earlier than 0.9.8m, but which have in reality backported huge swaths of 0.9.8m or 0.9.8n renegotiation behavior. Possible fix for some cases of bug 1346. I hope that, in the future, openssl.org will make some effort to coordinate such things with the various operating system developers in a way that avoids turning the situation into such a cl*f*** again. It's obviously been a nightmare for you and the rest of the tor project, and I'd bet heavily that the tor project is not the only one so affected. But we haven't yet put out a stable release that includes that patch. So if you upgraded to the latest 0.2.2.x-alpha to get the fixes for other bugs, you would get the fix for this bug too. Let us know if it works. Are there any ideas floating around yet as to why tor doesn't work with openssl 1.0.0? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.11-alpha and 0.2.2.12-alpha are out
On Thu, 22 Apr 2010 19:39:07 -0400 Roger Dingledine a...@mit.edu wrote: Tor 0.2.2.12-alpha fixes a critical bug in how directory authorities handle and vote on descriptors. It was causing relays to drop out of the consensus. Was there some point in releasing the above without your directory fetch circuit timeout patch, at least as a temporary fix that might be replaced by something better in 0.2.2.13-alpha? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BadExit flag still needed for PrivacyNow...
On Sun, 18 Apr 2010 13:21:33 -0400 Roger Dingledine a...@mit.edu wrote: On Thu, Apr 15, 2010 at 11:59:31PM -0500, Scott Bennett wrote: My weather satellite images got blocked again, due to the PrivacyNow exit using OpenDNS with a misconfigured account and the fact that ExcludeExitNodes still doesn't work reliably. Will the the authority operators *please* stick a BadExit flag onto that router's entry in the consensus? Thanks! Sebastian just confirmed for me that it was really happening, so I've set the BadExit flag for moria1. I agree that dns filtering is a good reason for earning the BadExit flag. Once tor26 or ides set it also, it should take effect. Thanks much, Roger. Since the flag appeared, I've had no further failures of that sort. Sorry for the delay in response. As usual, we're all overbusy over here. I was supposed to be on an airplane over the Atlantic now -- Bummer. I hope whatever you were going to attend can be rescheduled. but it looks instead like I can catch up on my email. :) On the bright side though, it's looking good that we'll be able to get a google summer of code student to revive Mike Perry's Snakes on a Tor project, and hopefully that means we will a) have some automated scans looking for really obviously broken relays, and b) build a clearer policy about what counts as badexit and what doesn't, so we can react faster next time. Both would be Very Good Things (tm). 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BadExit flag still needed for PrivacyNow...
On Sun, 18 Apr 2010 21:29:04 -0700 Jacob Appelbaum ja...@appelbaum.net wrote: Roger Dingledine wrote: On Thu, Apr 15, 2010 at 11:59:31PM -0500, Scott Bennett wrote: My weather satellite images got blocked again, due to the Privacy= Now exit using OpenDNS with a misconfigured account and the fact that ExcludeExitNodes still doesn't work reliably. Will the the authority operators *please* stick a BadExit flag onto that router's entry in th= e consensus? Thanks! =20 Sebastian just confirmed for me that it was really happening, so I've set the BadExit flag for moria1. I agree that dns filtering is a good reason for earning the BadExit flag. =20 Once tor26 or ides set it also, it should take effect. I've also set the authdirbadexit on urras for the PrivacyNow node. Thanks, Jake. It seems like we should make a baddns flag at some point. I've been turning that over in my mind for day or two now, and I'm still trying to think of why we would need it. What the authorities would communicate to clients is basically, Don't use this node as an exit. Well, we already have a flag for that. We also have a flag (Invalid) that says, Don't use this node at all, which could have been used to deal with the throughput capacity exaggeration attack-- which the tor network is *not* known to have ever experienced--quite easily, rather than the frankly ham-handed method that was implemented instead. If you're worried about a NORDO relay operator like PrivacyNow's operator who discovers his/her node has been assigned a BadExit flag and wants to know why, that operator can always write to tor-ops@ to find out. Perhaps a note to that effect regarding all cautionary flags-- is there still a bad directory flag, as referenced on the torstatus page?--(e.g., BadExit, Invalid) could be added to the torproject.org web pages somewhere. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re:Eventdns: All name servers have failed
On Mon, 19 Apr 2010 19:00:20 -0500 David Carlson carlson...@sbcglobal.net wrote: I am a newbie here, so perhaps this is an overly naive response to this All of us have been at some point. subject. Your discussion below presents one plausible explanation. I am using Windows XP and I am behind a digital modem provided by ATT. That modem is the DNS for my local network. Does your LAN have any non-Windows systems on it on which you might more easily run a name server of your own? I see that message at times when I think that ATT is re-booting that=20 modem (lately that is at least once a night), which would make the DNS Why do you think that is happening? Does it have a column of lights that show a distinct pattern when the modem is reinitializing itself? un-available for a short time. Another possibility is that the other end of the connection is on an ISP subnet that is momentarily flooded with traffic, resulting in your LAN's queries or the ISP's name server's responses from completing their trips before the timeout period expires. The default timeout period for DNS queries these days is normally only 3 s. I am sure there are other possible causes, but when this is suspected, I would just let the notes fill up the log. It's certainly worth further investigation. A phone call to the ISP to find out what its policies and practices are about daily reboots and so on might be well worth your time. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re:Eventdns: All name servers have failed
On Tue, 20 Apr 2010 05:50:42 -0500 (CDT) I wrote: On Mon, 19 Apr 2010 19:00:20 -0500 David Carlson carlson...@sbcglobal.net wrote: I am a newbie here, so perhaps this is an overly naive response to this All of us have been at some point. subject. Your discussion below presents one plausible explanation. I am using Windows XP and I am behind a digital modem provided by ATT. That modem is the DNS for my local network. Does your LAN have any non-Windows systems on it on which you might more easily run a name server of your own? I see that message at times when I think that ATT is re-booting that=20 modem (lately that is at least once a night), which would make the DNS Why do you think that is happening? Does it have a column of lights that show a distinct pattern when the modem is reinitializing itself? un-available for a short time. I see I thoroughly garbled the following sentence (aarrghh...). Another possibility is that the other end of the connection is on an ISP subnet that is momentarily flooded with traffic, resulting in your LAN's queries or the ISP's name server's responses from completing their ^^^ That should read, failing to complete. Apologies for the noise. trips before the timeout period expires. The default timeout period for DNS queries these days is normally only 3 s. I am sure there are other possible causes, but when this is suspected, I would just let the notes fill up the log. It's certainly worth further investigation. A phone call to the ISP to find out what its policies and practices are about daily reboots and so on might be well worth your time. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BadExit flag still needed for PrivacyNow...
On Sat, 17 Apr 2010 21:54:16 -0400 Andrew Lewman and...@torproject.org wrote: On 04/16/2010 12:59 AM, Scott Bennett wrote: My weather satellite images got blocked again, due to the PrivacyNow exit using OpenDNS with a misconfigured account and the fact that ExcludeExitNodes still doesn't work reliably. Will the the authority operators *please* stick a BadExit flag onto that router's entry in the consensus? Thanks! I think it's time for a baddns attribute, rather than solely bad exit. The nxdomain test is fairly binary, either your local nameserver is lying to you or not. No objection occurs to me on first reading. Give it shot, and see whether it stops this recurrent problem, which has been griped about on this list by people encountering many instances of it at different exits. Of course, there is the inertial resistance to changes to the directory and consensus specifications, but I doubt most of us have much influence on the development in such cases. In the meantime, however, WE *STILL* NEED A BadExit FLAG FOR PrivacyNow. *PLEASE* *DO* *IT*, and stop stalling! Unless your point in not doing so is that you don't want us to report bad exit behavior so that it can be prevented from messing up the validity of clients' circuit route selections. It is a very high throughput exit node, so it gets to censor *many* streams. I may be misunderstanding the using opendns with a misconfigured account statement. Probably not. The OpenDNS servers, AFAIK, require a free account be established before they will answer queries about domains other than OpenDNS's own domain(s). That can be accomplished via their web site, which also allows the account holder to select various options, one of which determines whether the account holder wishes to have queries about certain domains be hijacked by OpenDNS in accordance with some list OpenDNS maintains. OpenDNS defaults to the censorship option, so an account holder has to make the effort of turning the censorship off. (Apparently, A RR queries for the ghcc.msfc.nasa.gov. domain are hijacked in that way.) The account holder can turn off all hijacking, supposedly, to get the same response they would get from a fully honest name server. tor exit operators are obligated to use name servers that give true answers, so an exit that is querying an OpenDNS name server and that has the highjacking feature--again, a Micro$lop usage of the word--enabled is therefore a BadExit. Even though I no longer run an exit, I had been truly fed up with Comcast's hijacking name servers for a long time, so when Google started offering free and open access to honest, though logging, name servers at 8.8.4.4 and 8.8.8.8, I switched to them immediately. I'm not too worried about the logging, because very few name server queries leave my machine anyway, mainly thanks to tor. And if I were running an exit, it still wouldn't bother me much because nearly all queries leaving my machine would have nothing to do with anything I was doing at the time. I've procrastinated so far about setting up a small name server here, basically for cacheing, and I've gotten away with it, I suspect, largely because I discovered nscd(8) on my system and configured it for use. nscd can be configured to cache results in caches for hosts, passwd, group, services, protocols, and RPCs. Additional, system-particular caches can also be defined if one has the need to do so. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BadExit flag still needed for PrivacyNow...
On Sun, 18 Apr 2010 09:54:31 -0500 Bill Weiss houdini+...@clanspum.net wrote: Scott Bennett(benn...@cs.niu.edu)@Sun, Apr 18, 2010 at 03:18:47AM -0500: On Sat, 17 Apr 2010 21:54:16 -0400 Andrew Lewman and...@torproject.org wrote: I may be misunderstanding the using opendns with a misconfigured account statement. Probably not. The OpenDNS servers, AFAIK, require a free account be established before they will answer queries about domains other than OpenDNS's own domain(s). That can be accomplished via their web site, which also allows the account holder to select various options, one of which determines whether the account holder wishes to have queries about certain domains be hijacked by OpenDNS in accordance with some list OpenDNS maintains. OpenDNS defaults to the censorship option, so an account holder has to make the effort of turning the censorship off. (Apparently, A RR queries for the ghcc.msfc.nasa.gov. domain are hijacked in that way.) The account holder can turn off all hijacking, supposedly, to get the same response they would get from a fully honest name server. tor exit operators are obligated to use name servers that give true answers, so an exit that is querying an OpenDNS name server and that has the highjacking feature--again, a Micro$lop usage of the word--enabled is therefore a BadExit. I'm not weighing in on the BadExit issue, just the technical details. Anyone can use the OpenDNS resolvers without having an account with them. You just don't get to toggle any of the options without doing so. I think Oh. Okay. Thanks for the correction. that, without an account, you get everything under OpenDNS Basic on their website[1] (Web content filtering, Proxy/anonymizer blocking, Phishing protection and Botnet protection being the ones we probably care about here). Looks about right. Scott: if the current owner doesn't have an account set up, _you_ could go to the OpenDNS page (via Tor so it come from that IP) and fix their settings :) [1] http://www.opendns.com/start/ Tsk, tsk. Although I suspect that that would not actually violate the criminal statute about unauthorized access, it would nevertheless be quite unethical. Consider the possibility that, laying tor out of view for a moment, there are other uses being made of that computer and/or network for which such blocking might be desired by the owner, e.g., content blocking for a household full of children with several computers available to them on their home network. Granted, an exit should *not* be run in such an environment, but it is not anyone's business to muck with the configuration of someone else's computer or network. Even though I no longer run an exit, I had been truly fed up with Comcast's hijacking name servers for a long time, so when Google started offering free and open access to honest, though logging, name servers at 8.8.4.4 and 8.8.8.8, I switched to them immediately. I'm not too worried about the logging, because very few name server queries leave my machine anyway, mainly thanks to tor. And if I were running an exit, it still wouldn't bother me much because nearly all queries leaving my machine would have nothing to do with anything I was doing at the time. I've procrastinated so far about setting up a small name server here, basically for cacheing, and I've gotten away with it, I suspect, largely because I discovered nscd(8) on my system and configured it for use. nscd can be configured to cache results in caches for hosts, passwd, group, services, protocols, and RPCs. Additional, system-particular caches can also be defined if one has the need to do so. Assuming your ISP doesn't damage your queries for you or redirect outgoing port 53 activity to their servers, setting up Bind as a local resolver is super easy. I'd be glad to help you out with a config if you'd like. Thanks, but I used to run the primary for the local university long ago, as well as a few unofficial secondaries around the campus. I've just been lazy about setting one up because I haven't really needed one. And, as I wrote before, nscd has been a blessing, not only for A RR queries, but for several other data sets as well. I appreciate the offer, though. FWIW, most of the situations in which my current setup fails involve being disconnected from the ISP due to some outage or modem screwup, so having a name server running wouldn't really help anyway. I just checked again, and as of 8:49 a.m. CDT, there was still no BadExit flag assigned to PrivacyNow. :-( 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
Re: TOR Not Starting after upgrade
On Fri, 16 Apr 2010 07:23:28 -0500 Edward Langenback apos...@peculiarplace.com wrote: krishna e bera wrote: On Thu, Apr 15, 2010 at 09:45:56PM -0500, Edward Langenback wrote: I've just upgraded to vidalia-bundle-0.2.1.25-0.2.7.exe and now TOR is not starting at all. I've tried a full uninstall-reinstall with no changes. Any ideas what the problem is? I'm still getting the same behavior after several reboots and complete re-installs. 1) Your insecurity software may have detected changed .exe files and therefore blocked Tor from starting (it is easy to miss the prompt). Not too easy to miss in the case of Sygate which puts up a large 'always on top' box asking if the change is ok. 2) The Tor might have started but browsing though it with Firefox not be working due to a legacy Privoxy hanging around (it was not automatically uninstalled by previous bundles for some reason) and occupying port 8118 so Polipo cannot start. I did have Privoxy running. After shutting it down progress went from stuck at 5% to stuck at 80% 3) Check the Tor log file for other possibilities. Check the Windows Events log for related System and Application events. Even though I had set the firewall to allow TOR, it was being blocked. After I created an explicit rule for TOR allowing it to connect to any port, it started working. That's good news. However, it most likely also means that you will need to do something with the firewall every time that you install a new tor. Most firewall/packet filter software for Windows makes a checksum or digest of each program that is allowed to have network access, and when an already approved program tries to use the network, its checksum or digest is calculated afresh and compared with the one already on record. If it has changed, then the current process will be blocked network access until someone approves the new version of the checksum or digest. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
you ever use tor at all, so that you *will* have most of the understanding you say you lack. Do I go to Tor's list of naughty exit nodes for the addresses to input? I need lots of help here so I'm asking for your patience too. Again, tor itself maintains no such list. The directory authority operators are the final arbiters of BadExit flag assignment, which tor clients are supposed to obey automatically in the route selection routines. You, yourself, are the maintainer of your own client's ExcludeExitNodes and ExcludeNodes lists in your torrc file. Meanwhile, I see that PrivacyNow still has the following flags assigned to it in the consensus document: s Exit Fast HSDir Named Running Stable V2Dir Valid I ask again that the authorities quickly either assign a BadExit to that node or, if they know how, contact its operator about the problem to get it corrected. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
On Thu, 15 Apr 2010 08:25:07 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Apr 15, 2010, at 8:17 AM, Scott Bennett wrote: Unfortunate (IMO), the latest versions have the support for .exit either disabled or deleted, apparently leaving us no easy way to perform such tests. I've asked recently on this list whether some other easy way were available, but have been met with silence, so I assume that there still is none. If you want the functionality, feel free to set the AllowDotExit config option to 1. Note that this can't be recommended, because it opens you up for That is what I have been doing in order to be able to test for exit misbehavior. However, the ChangeLog notes under Minor bugfixes for 0.2.2.9-alpha the following: - Resume handling .exit hostnames in a special way: originally we stripped the .exit part and used the requested exit relay. In 0.2.2.1-alpha we stopped treating them in any special way, meaning if you use a .exit address then Tor will pass it on to the exit relay. Now we reject the .exit stream outright, since that behavior ^^^ might be more expected by the user. Found and diagnosed by Scott ?? Bennett and Downie on or-talk. I understood the Now we reject part as meaning that the .exit support had been completely removed. I do not understand why that behavior might be more expected by the user. In any case, the above note is why I've paused at 0.2.2.7-alpha while waiting to discover some fairly easy-to-use alternative method of testing exit behavior. attacks where the exit node can choose who your exit is going to be, unless you use encrypted protocols when webbrowsing only. Regarding the attack route you mention, I have some firefox plug-ins like NoRedirect and RefreshBlocker installed in addition to the recommended plug-ins (including QuickJava, NoScript, and Torbutton especially) that should help with automated stuff, and I'm in the habit of checking the actual URLs in links before using the links manually. In many cases, I don't even use firefox to get stuff from the links, but rather do a copy-and-paste to a wget(1) or some other downloader command in an xterm(1), so I have plenty of opportunity to notice that sort of interference. If those strategies still miss something, please do let me know. # This file was generated by Tor; if youedit it, comments will not be pres= I think the comment may be a lie. It's most likely a torrc produced by vidalia, not tor. (Someone please correct me if I've forgotten some special case in which tor does rewrite a torrc.) I think it is more likely that the file was written by Tor, via the SAFECONF torctl command. Okay, I guess I had forgotten tor implemented such a command, but who is issuing the command? Vidalia? Thanks for the information, 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
On Wed, 14 Apr 2010 17:23:35 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett wrote: It appears memory consumption with the wrapped Linux malloc() is still larger than than with openbsd-malloc I used before. Hugepages don't appear to work with openbsd-malloc. Okay, that looks like a problem, and it probably ought to be passed along to the LINUX developers to look into. yes, but I don't suppose this problem being related to hugepages wrapper. Linking tor against standard glibc malloc() never worked for me in the past. Always had the problem that memory leaked like hell and after a few days tor process crashed with an out of memory error. Running configure script with --enable-openbsd-malloc flag solved this issue but apparently it doesn't work with libhugetlbfs.so. After 17 hours of operation resident process size is 1 gig. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 1943m 1.0g 24m R 79.4 26.9 927:51.27 1 tor On the other hand cpu load really seems to be reduced compared with standard page size. Olaf, if you're awake and on-line at/near this hour:-), how about an update, now that blutmagie has been running long enough to complete its climb to FL510 and accelerate to its cruising speed? Also, how about some numbers for how it ran without libhugetlbfs, even if only approximate, for comparison? (The suspense is really getting to me.:^) Thanks! 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
On Thu, 15 Apr 2010 09:17:39 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Apr 15, 2010, at 9:11 AM, Scott Bennett wrote: On Thu, 15 Apr 2010 08:25:07 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Apr 15, 2010, at 8:17 AM, Scott Bennett wrote: Unfortunate (IMO), the latest versions have the support for .exit either disabled or deleted, apparently leaving us no easy way to perform such tests. I've asked recently on this list whether some other easy way were available, but have been met with silence, so I assume that there still is none. If you want the functionality, feel free to set the AllowDotExit config option to 1. Note that this can't be recommended, because it opens you up for That is what I have been doing in order to be able to test for exit misbehavior. However, the ChangeLog notes under Minor bugfixes for 0.2.2.9-alpha the following: - Resume handling .exit hostnames in a special way: originally we stripped the .exit part and used the requested exit relay. In 0.2.2.1-alpha we stopped treating them in any special way, meaning if you use a .exit address then Tor will pass it on to the exit relay. Now we reject the .exit stream outright, since that behavior ^^^ might be more expected by the user. Found and diagnosed by Scott ?? Bennett and Downie on or-talk. I understood the Now we reject part as meaning that the .exit support had been completely removed. I do not understand why that behavior might be more expected by the user. In any case, the above note is why I've paused at 0.2.2.7-alpha while waiting to discover some fairly easy-to-use alternative method of testing exit behavior. Ah no, that's not what is meant here. The idea is that when .exit is disabled, we reject connections to some domain ending in .exit, instead of passing that URL to the exit node. This is more expected behaviour because there is no .exit tld currently, so people telling to to go to xyz.exit are most likely thinking that they are talking to a tor with the .exit functionality enabled. Great! Thanks for the clarification. I'll go ahead and upgrade soon. attacks where the exit node can choose who your exit is going to be, unless you use encrypted protocols when webbrowsing only. Regarding the attack route you mention, I have some firefox plug- ins like NoRedirect and RefreshBlocker installed in addition to the recommended plug-ins (including QuickJava, NoScript, and Torbutton especially) that should help with automated stuff, and I'm in the habit of checking the actual URLs in links before using the links manually. In many cases, I don't even use firefox to get stuff from the links, but rather do a copy-and-paste to a wget(1) or some other downloader command in an xterm(1), so I have plenty of opportunity to notice that sort of interference. If those strategies still miss something, please do let me know. I suppose you still load images and possibly other resources, too; those can be fetched from arbitrary locations unless disabled via special-purpose addons like RequestPolicy. Hmmm...yes, some images load without intervention, although many do not. Okay, I'll change my habits, so that torrc will have it turned off by default, and I'll only turn it on (and send tor a SIGHUP) when I really need it. OTOH, thanks very much for the tip about RequestPolicy. I didn't know about that one, so I'll check into it. # This file was generated by Tor; if youedit it, comments will not be pres= I think the comment may be a lie. It's most likely a torrc produced by vidalia, not tor. (Someone please correct me if I've forgotten some special case in which tor does rewrite a torrc.) I think it is more likely that the file was written by Tor, via the SAFECONF torctl command. Okay, I guess I had forgotten tor implemented such a command, but who is issuing the command? Vidalia? Thanks for the information, Sebastian. Yes, Vidalia as the only Tor controller in a typical setup would be issuing the saveconf command. Okay, so tor does the actual (re)write, but Vidalia is still the perpetrator as far as the OP should be concerned. :-) Thanks 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
PrivacyNow node has misconfigured OpenDNS account
I just found my weather information being blocked, giving me the OpenDNS access blocked web page. After some checking, I found the culprit exit: PrivacyNow. There is no contact information in its descriptor in the current directory, so I'm adding it to my ExcludeExitNodes list. :-( 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
messages indicate strange choice by tor
I would be most interested in knowing the explanation for the decision that tor announced in the following pair of messages. Apr 14 08:55:50.861 [info] connection_or_group_set_badness(): Marking OR conn to 194.109.206.212:443 as too old for new circuits: (fd 7, 900 secs old). We have a better canonical one (fd 118; 2239 secs old). Apr 14 08:55:50.861 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 7 (194.109.206.212:443) [Too old]. Why is the younger connection too old, yet the much older connection is somehow better? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 18:18:02 -0700 (PDT) Christian Kujau li...@nerdbynature.de wrote: On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: and straighten us out. Remember that Olaf runs the highest-load-bearing tor node in our whole network, and there are at least two or four dozen others that should be considered heavyweight relays that are also on LINUX systems. ...and some of them are running on old notebooks and the tor process is only a few megabytes in size :-| If tor is only using, say, 25 MB or so, then tor's CPU load is probably low anyway. Nevertheless, any other process on a small x86-type of LINUX system that has a working set greater than 256 KB of instruction pages and/or 256 KB of data+stack pages would benefit from using enough hugepages to cover its needs. However, if it turns out that using hugepages in Linux would help larger Tor installations (and superpages can be recommended for *BSD systems[0] as well), maybe this can be documented somehwere under doc/ or in the wiki. But let's see how Olaf's experiment turns out. Christian. [0] http://www.freebsd.org/releases/7.2R/relnotes-detailed.html This is disabled by default and can be enabled by setting a loader tunable vm.pmap.pg_ps_enabled to 1. A couple of caveats regarding the automatic version available in FreeBSD 7.2 and later releases are in order here. To the best of my knowledge, this feature is not yet available :-( in any of the other BSDs, so tor relay operators on NetBSD, OpenBSD, DragonflyBSD, MirBSD, etc. can disregard all of this stuff for the time being. Another matter is that FreeBSD systems on AMD processors of designs older than the K10 types may actually get poorer performance with the feature enabled. That's because on those processors the number of entries in the TLBs is drastically reduced in the 4 MB pages mode. So on pre-K10 AMD processors the official recommendation that I read was to try it if you have a large process that is bogging down, and just see what happens. If it helps, then that's great, but be prepared for the strong possibility that it might just make matters worse. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
On Wed, 14 Apr 2010 13:34:47 +0200 Runa Sandvik runa.sand...@gmail.com wrote: On Wed, Apr 14, 2010 at 1:31 PM, zzzjethro...@email2me.net wrote: Hello Hi, When you add the exit PrivacyNow to your ExcludeExitNodes list, is this done automatically inside of the Tor program afterwards, for any or all clients,=A0 or is this something I need to do also do in my torrc file? This is something that you will have to do in your torrc file as well. Yes, I guess I kind of botched my first message on this. I should have also added a request that the directory authorities flag PrivacyNow as a BadExit because it clearly meets the definition of a bad exit. However, 1) any bad exits that I report I also add to my own torrc's ExcludeExitNodes list because a) I want it to take effect immediately and b) sometimes the authority operators appear to make exceptions for some misconfigured/miscreant nodes, and 2) I wasn't really awake yet when I was composing the alarm. PrivacyNow is a very high-performance node, and it will be a shame to lose it as an exit node. (A few hours ago, it was ranked by torstatus as the #44 node by throughput.) However, its owner/operator clearly does not want to be contacted about problems, so we aren't really left with much choice. In any case, it will still be a good entry or middle node for many, many circuits per second. So now I guess I should make the request. Unless the authorities know how to reach the operator of PrivacyNow to get his/her OpenDNS configuration fixed (or switched to Google's open name servers or something similar), will the authorities please flag PrivacyNow as a BadExit ASAP? Thanks. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
On Wed, 14 Apr 2010 15:00:52 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Christian Kujau wrote: On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: and straighten us out. Remember that Olaf runs the highest-load-bearing tor node in our whole network, and there are at least two or four dozen others that should be considered heavyweight relays that are also on LINUX systems. ...and some of them are running on old notebooks and the tor process is only a few megabytes in size :-| In the end of all days tor traffic has to pass thru the exit nodes. About 50% of all traffic leave tor network thru the top 15 exit nodes only. If they can't cope with their load all nifty tor ports for smartphones, dsl routers or whatsoever acting as entry or middle man will be in vain. Exactly. However, if it turns out that using hugepages in Linux would help larger Tor installations (and superpages can be recommended for *BSD systems[0] as well), maybe this can be documented somehwere under doc/ or in the wiki. But let's see how Olaf's experiment turns out. process size is still growing: anonymizer2:~# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 313 1000* It appears memory consumption with the wrapped Linux malloc() is still larger than than with openbsd-malloc I used before. Hugepages don't appear to work with openbsd-malloc. Okay, that looks like a problem, and it probably ought to be passed along to the LINUX developers to look into. But the important question is how is tor's CPU usage looking now with the hugepages as compared to before? It was the CPU usage that you said was the severe problem before. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
On Wed, 14 Apr 2010 17:23:35 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett wrote: It appears memory consumption with the wrapped Linux malloc() is still larger than than with openbsd-malloc I used before. Hugepages don't appear to work with openbsd-malloc. Okay, that looks like a problem, and it probably ought to be passed along to the LINUX developers to look into. yes, but I don't suppose this problem being related to hugepages wrapper. Linking tor against standard glibc malloc() never worked for me in the past. Always had the problem that memory leaked like hell and after a few days tor process crashed with an out of memory error. Running configure script with --enable-openbsd-malloc flag solved this issue but apparently it doesn't work with libhugetlbfs.so. Is tor statically linked? If not, I wonder if it's a library-ordering problem, where a version of malloc() in libhugetlbfs or in a library called by a routine in libhugetlbfs gets linked in ahead of the OpenBSD version. I don't know how much flexibility that LD_PRELOAD method gives you, but perhaps you could try the -rpath trick we FreeBSD folks had to use to force use of openssl from ports rather than the broken one in the base system. After 17 hours of operation resident process size is 1 gig. How much was it typically using before? PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 1943m 1.0g 24m R 79.4 26.9 927:51.27 1 tor On the other hand cpu load really seems to be reduced compared with standard page size. Holy Crapola! 79.4% is a *reduction*?!?? 8-Q What did it use before? 100%? 1 GB is 512 hugepages. I wonder if getting the malloc() issue resolved and lowering the working set size would reduce the CPU time still further, given that each TLB only holds 64 entries. (I fail to see yet why the LINUX developers picked a hugepage size that is not supported by hardware, at least not for the data and stack segments.) A long time back, we tossed an idea around briefly to the effect that you might get more balanced utilization of your machine by running two copies of tor in parallel with their throughput capacities limited to something more than half apiece of the current, single instance's capacity. That would bring the other core into play more of the time. A configuration like that would still place both instances very high in the list of relays ordered by throughput, but the reduction in the advertised capacity of each would help to spread the requests to both better. They would still be limited by the TCP/IP's design limit on port numbers for the system as a whole, which you would likely never see because the kernel would probably just refuse connections when all port numbers were already in use, but would probably allow you to squeeze more total tor throughput through the machine than you get at present, while still leaving a moderate amount of idle time on each core that would then be available for other processing. Have you given any more thought to this idea over the ensuing months? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 19:10:37 +0200 Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: Scott Bennett wrote: BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. I'm not an expert, but I managed to perform some google searches. http://libhugetlbfs.ozlabs.org/ From that website: libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. [Aside to Olaf: oh. So forcing the use of OpenBSD's malloc() might prevent the libhugetlbfs stuff from ever knowing that it was supposed to do something. :-( I wonder how hard it would be to fix the malloc() in libhugetlbfs, which is most likely derived from the buggy LINUX version. Does libhugetlbfs come as source code? Or is the use of LD_PRELOAD simply causing LINUX's libc to appear ahead of the OpenBSD version, in which case forcing reordering of the libraries might work? --SB] Someone is working on transparent hugepage support: http://thread.gmane.org/gmane.linux.kernel.mm/40182 I've now had time to get through that entire thread. I found it kind of frustrating reading at times. It seemed to me that in one of the very first few messages, the author described how they had long since shot themselves in the feet (i.e., by rejecting the algorithm of Navarro et al. (2002), which had already been demonstrated to work on an early FreeBSD 5 system modified by Navarro's team) on emotional grounds (i.e., we didn't feel its [Navarro's method's] heuristics were right). They then spent the rest of the thread squabbling over the goals and individual techniques of Navarro et al. that they had reinvented, while not admitting to themselves that that was what they had done, and over the obstacles they were running into because of the parts that they had *not* adopted (yet, at least). At times, it appeared that the author of the fairly large patch that implemented the improvements to the hugepage system was arguing directly from Navarro et al. (2002) with one of the other participants. Shades of Micro$lop's methods and not-invented-here attitude. What a bummer to see LINUX developers thinking in such denial! So if the guy who had written that early kernel patch for LINUX (the thread was a year and a half ago) has persisted in his implementation, he may have the bugs out of it by now, but in the long run, his design (or lack thereof) should provide something that provides significant improvement for some large processes on LINUX, but the way it is done won't be at all pretty. Unlike the method of Navarro et al., which that team had actually done not on an x86-type of system, which is the only type so far supported for superpages in FreeBSD 7 (not sure about 8.0), but on an alpha machine, using the four page sizes offered by the hardware, the method implemented by the OP of the thread used a hugepage size (2 MB) that is not supported by the hardware, except for pages in instruction (text) segments. I didn't see anywhere in the thread an explanation of how their software pages are made to work with the hardware, but I would imagine they must combine two software hugepages to make a single 4 MB page as far as the address translation circuitry is concerned. It left me wondering much of the time which processor architecture they were working with, though it eventually became clear that they were indeed talking about x86 processors. The others in the thread also voiced opinions that the method would prove to be not easily portable to other hardware architectures, unlike the Navarro method. Navarro et al. (2002) found that their array of test applications did not all benefit at all superpage sizes. Which superpage size crossed the threshhold into reduced TLB thrashing varied from application to application. Some benefited after the first promotion from 8 KB base pages to 64 KB superpages. Others benefited after the further promotion to 512 KB superpages. Still others' performance characteristics did not improve much until after the third promotion to 4 MB superpages. Which size causes the big improvement for an application depends almost entirely upon the memory access patterns of that application. It remains to be seen whether an application that doesn't speed up in FreeBSD tests until after the application has been promoted to the 4 MB superpages will speed up in LINUX's 2 MB hugepages. I'm still tired. I think I might take a short nap again, so I might not post replies to anyone's followups on this for a few hours. (Yawn...) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet
Re: huge pages, was where are the exit nodes gone?
Hi Arjan, On Wed, 14 Apr 2010 22:03:33 +0200 Arjan Scott Bennett wrote: On Tue, 13 Apr 2010 19:10:37 +0200 Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: Scott Bennett wrote: BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. I'm not an expert, but I managed to perform some google searches. http://libhugetlbfs.ozlabs.org/ From that website: libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. [Aside to Olaf: oh. So forcing the use of OpenBSD's malloc() might prevent the libhugetlbfs stuff from ever knowing that it was supposed to do something. :-( I wonder how hard it would be to fix the malloc() in libhugetlbfs, which is most likely derived from the buggy LINUX version. Does libhugetlbfs come as source code? Or is the use of LD_PRELOAD simply causing LINUX's libc to appear ahead of the OpenBSD version, in which case forcing reordering of the libraries might work? --SB] If Olafs test shows that CPU usage is reduced and throughput stays the same or improves, modifying Tor to support linux huge pages might be an option. Part 2 of this article contains some information about the available interfaces: http://lwn.net/Articles/374424/ Thanks. I'll take a look at it, but I still haven't had the nap I was going to take. :-( Getting the wrapper to work with (or like) the OpenBSD version will probably be easier. One of the reasons I'm still awake is that I was browsing through the OpenBSD version of malloc() that is shipped with tor and libhugetlbfs's morecore.c module. I'm still not sure quite what is going on with how the stuff gets linked together, so I don't know which avenue might be the easiest approach, but modifying tor is probably the worst option. If the LINUX side of things gets fixed, then the patches ought to be contributed to the LINUX effort. However, it may be easier to modify the OpenBSD malloc() to call something in morecore.c to get memory allocated by the kernel, falling back to whatever it currently does if the morecore.c stuff returns an error because it can't allocate the hugepages necessary to satisfy a request. Of course, someone would still need to find out how to keep the LINUX malloc() from being substituted for the OpenBSD malloc() at runtime when the libhugetlbfs wrapper is in use. I doubt I can contribute much to the effort, given that I don't have a LINUX system available to me. Someone is working on transparent hugepage support: http://thread.gmane.org/gmane.linux.kernel.mm/40182 I've now had time to get through that entire thread. I found it kind of frustrating reading at times. It seemed to me that in one of the very first few messages, the author described how they had long since shot themselves in the feet (i.e., by rejecting the algorithm of Navarro et al. (2002), which had already been demonstrated to work on an early FreeBSD 5 system modified by Navarro's team) on emotional grounds (i.e., we didn't feel its [Navarro's method's] heuristics were right). snipped the remainder of the analysis Thanks for your analysis of the thread and the reference to the Navarro paper. I've located the paper and will read it when time permits: http://www.usenix.org/events/osdi02/tech/full_papers/navarro/ Oh. Sorry about that. I had intended to include that at the end of what I wrote, but apparently I spaced it. I didn't mean to make anyone have to search for it. Thanks for correcting the deficiency in my message. I think you'll find their design is quite elegant and well thought out. It apparently required adding fewer than 3600 lines of code to the kernel to do it and uses a trivial amount of kernel CPU time in action. It's quite transparent and adaptive to conditions, but there are probably some conditions under which it might give less benefit than the LINUX hugepages way. However, it continually tries to promote processes that allocate enough space in a segment to fill the next larger page size. Its reservation system greatly increases the chances that promotions will occur. It's not a perfect solution to the problem, but I suspect there aren't any perfect solutions for it on the software side of things. What is really needed is for the chip manufacturers to correct the matter by increasing their TLB sizes rather dramatically. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well
Re: [or-talk] where are the exit nodes gone?
On Tue, 13 Apr 2010 08:43:21 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. the old blutmagie exit running in 2007-2009 which serves my tns pages is equipped with two Xeon cpus from the old P4 Prestonia architecture. The exit node anonymizer2.blutmagie.de has one c2d E8600 cpu. Cause tor process basically spends all cpu time within one thread, a slower clocked quad/multicore wouldn't speed up anything. Either I forgot (probable) or you didn't mention before (less probable) that you had moved it to a newer machine. Whatever you're running it on, superpages or LINUX's huge pages ought to speed tor up considerably by drastically reducing TLB misses. (I wasn't suggesting that you revert to older hardware. I was thinking that you were still running tor on the Xeon- based machine.) 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Need a full description of 'Use New Identity'
On Tue, 13 Apr 2010 12:49:33 +0530 emigrant fromwindowstoli...@gmail.com wrote: i need a full explation or a link which talks about 'Use new identity'. thanks a lot. The answer is in the documentation, but I don't remember off the top of my head where, so I don't have a URL for you. It tells your client, basically, to mark all existing circuits as being too old to use for new streams and to build three new circuits proactively. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 11:04:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett wrote: Either I forgot (probable) or you didn't mention before (less probable) that you had moved it to a newer machine. Whatever you're running it on, superpages or LINUX's huge pages ought to speed tor up considerably by drastically reducing TLB misses. (I wasn't suggesting that you revert to older hardware. I was thinking that you were still running tor on the Xeon- based machine.) I just setup hugepages (1024 pages a 2 MB) according this hint http://www.pythian.com/news/1326/performance-tuning-hugepages-in-linux/ Very interesting article. Thanks for the URL. Of course, not being a LINUX user, I have no idea what the acronyms for various LINUX kernel features mean, and I have mercifully been free of any involvement with Oracle for ~17 years, so ditto for the Oracle stuff. :-) One matter of concern, though, is the mention of a page size of 2 MB. Intel x86-style CPUs offer a 2 MB page size *only* for instruction (a.k.a. text) segments, not for data or stack segments, so I'm not sure what LINUX is doing with that. (See also the last line of the following bit of output.) anonymizer2:~# echo 1024 /proc/sys/vm/nr_hugepages anonymizer2:~# cat /proc/meminfo | grep -i hugepage HugePages_Total: 126 HugePages_Free: 126 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Does tor process automagically take advantage from hugepages after restarting the process or has tor source code to be modified? Olaf, I honestly don't know. I had not seen the page for which you provided a URL, and it is more recent than what I had read about LINUX's huge pages before. Those older articles clearly stated that a program had to reserve/designate its memory as huge pages *explicitly*, but it's possible that usage is now more automatic. However, part of the final sentence in the article's summary section stands out to me: If your database is running in LINUX *and has HugePages capability* [emphasis mine --SB], there is no reason not to use it. That suggests to me that the application (tor, in this case) must tell the LINUX kernel which page size it wants for its memory. Whether it also has to specify address ranges explicitly to be so mapped, I haven't the foggiest idea. But even if the application does have to tell the kernel something, it ought to be fairly trivial to add to tor's startup code. Start out by overestimating (assuming there is adequate real memory on the system to play with) how much tor will need at its maximum size, then decrease it, perhaps a bit at a time in successive recompilations, until it only minimally exceeds tor's high-water mark. [soapbox: on] [Unless you have other applications also using that machine, this would probably all be made so much easier by just trying out PC-BSD 8.0 because a one-line entry in /boot/loader.conf would take care of superpages for you automatically. PC-BSD is the install-and-go version for both new users who need to be able to use the system right away before learning much and casual users who have no interest in learning much about FreeBSD. This special packaging of the system is designed to allow both groups, who might otherwise find it beyond the effort they were willing or able to put into it, to get its benefits.] [soapbox: off] Now that you've had tor running for a while, what does a cat /proc/meminfo | grep -i hugepage show you? Also, 126 such pages equal 256 MB of memory. Is that really enough to hold your entire tor process when it's going full tilt? I thought I had seen you post items here in the past that said it was taking well over 1 GB and approaching 2 GB. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 05:16:33 -0500 (CDT) I wrote: On Tue, 13 Apr 2010 11:04:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett wrote: Either I forgot (probable) or you didn't mention before (less probable) that you had moved it to a newer machine. Whatever you're running it on, superpages or LINUX's huge pages ought to speed tor up considerably by drastically reducing TLB misses. (I wasn't suggesting that you revert to older hardware. I was thinking that you were still running tor on the Xeon- based machine.) I just setup hugepages (1024 pages a 2 MB) according this hint http://www.pythian.com/news/1326/performance-tuning-hugepages-in-linux/ Very interesting article. Thanks for the URL. Of course, not being a LINUX user, I have no idea what the acronyms for various LINUX kernel features mean, and I have mercifully been free of any involvement with Oracle for ~17 years, so ditto for the Oracle stuff. :-) One matter of concern, though, is the mention of a page size of 2 MB. Intel x86-style CPUs offer a 2 MB page size *only* for instruction (a.k.a. text) segments, not for data or stack segments, so I'm not sure what LINUX is doing with that. (See also the last line of the following bit of output.) anonymizer2:~# echo 1024 /proc/sys/vm/nr_hugepages anonymizer2:~# cat /proc/meminfo | grep -i hugepage HugePages_Total: 126 ^^^ Apparently, telling it reserve 1024 huge pages didn't take. I guess you'll have to dig into the LINUX documentation a bit to find out what's up with that. HugePages_Free: 126 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Does tor process automagically take advantage from hugepages after restarting the process or has tor source code to be modified? Olaf, I honestly don't know. I had not seen the page for which you provided a URL, and it is more recent than what I had read about LINUX's huge pages before. Those older articles clearly stated that a program had to reserve/designate its memory as huge pages *explicitly*, but it's possible that usage is now more automatic. However, part of the final sentence in the article's summary section stands out to me: If your database is running in LINUX *and has HugePages capability* [emphasis mine --SB], there is no reason not to use it. That suggests to me that the application (tor, in this case) must tell the LINUX kernel which page size it wants for its memory. Whether it also has to specify address ranges explicitly to be so mapped, I haven't the foggiest idea. But even if the application does have to tell the kernel something, it ought to be fairly trivial to add to tor's startup code. Start out by overestimating (assuming there is adequate real memory on the system to play with) how much tor will need at its maximum size, then decrease it, perhaps a bit at a time in successive recompilations, until it only minimally exceeds tor's high-water mark. BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. Remember that Olaf runs the highest-load-bearing tor node in our whole network, and there are at least two or four dozen others that should be considered heavyweight relays that are also on LINUX systems. It is in every LINUX+tor user's interest to help Olaf and others running tor nodes on LINUX systems here to make sure all of those systems are getting the performance benefits of smaller page tables for their tor processes (provided those systems have adequate real memory, which I would bet most of them do). I've worked with UNIX for decades, but have never used a LINUX system. Olaf shouldn't have to depend solely upon someone who doesn't really know much of what he's writing about to get his blutmagie tor node running with LINUX huge pages when there are so many LINUX system experts on this list. [soapbox: on] [Unless you have other applications also using that machine, this would probably all be made so much easier by just trying out PC-BSD 8.0 because a one-line entry in /boot/loader.conf would take care of superpages for you automatically. PC-BSD is the install-and-go version for both new users who need to be able to use the system right away before learning much and casual users who have no interest in learning much about FreeBSD. This special packaging of the system is designed to allow both groups, who might otherwise find it beyond the effort they were willing or able to put into it, to get its benefits.] [soapbox: off] Now that you've had tor running for a while, what does a cat /proc/meminfo | grep -i hugepage show you? Also, 126 such pages equal 256 MB of memory. Is that really enough to hold your entire tor ^^^ [*252* MB:-] Oops. I guess I
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 18:15:18 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett wrote: Now that you've had tor running for a while, what does a cat /proc/meminfo | grep -i hugepage show you? Also, 126 such pages equal 256 MB of memory. Is that really enough to hold your entire tor process when it's going full tilt? I thought I had seen you post items here in the past that said it was taking well over 1 GB and approaching 2 GB. tor process crashed with out of memory error ;-) Apr 13 11:06:39.419 [err] Out of memory on malloc(). Dying. Hmm. Looks like you need to raise its stack segment and/or data segment size limit(s). After restarting the tor process HugePages_Total and HugePages_Free still had a value of 126, so I assume tor didn't use them. Eventually I disabled them. Well, the first number shouldn't change. If tor had already quit, the the HugePages_Free value, even if some had been allocated/reserved, should have reverted to the HugePages_Total value anyway, so what you saw there should really be no surprise. Have you found anything yet about huge pages in the LINUX man pages or other documentation? It seems to me that the documentation kind of has to cover the use of huge pages *somewhere*. Does LINUX have anything like apropos(1) for finding things by keystring in the man page collection? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 19:10:37 +0200 Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: Scott Bennett wrote: BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. I'm not an expert, but I managed to perform some google searches. http://libhugetlbfs.ozlabs.org/ From that website: libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. That does look promising, then. Perhaps Olaf and others can use that method for now. Someone is working on transparent hugepage support: http://thread.gmane.org/gmane.linux.kernel.mm/40182 Thanks much for these URLs, Arjan. I've started going through this thread, but it's a horrendous lot to digest and full of LINUXisms that I know nothing about. I have some errands to run, and then I really *must* get some sleep. Maybe late tonight I'll continue reading. In the meantime, perhaps some adventurous relay operator using LINUX could begin experimenting with the libhugetlbfs-in-LD_PRELOAD method to see whether tor functions okay with it and then report the results back to the list. I'll be offline for at least 10 - 12 hours. Best of luck! 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 08:47:31 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Roger Dingledine schrieb: No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all the same graphs for the average observed bandwidth would be great Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Hi Olaf, On Sun, 11 Apr 2010 12:11:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic You did say observed, not advertised. purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value Remember, there are exactly two vantage points from which valid observations can be made, no more and no less. One is from inside your system's networking stack (including packet filter software). The other is inside your tor relay's process. Unless the value of about 16000 KB (/s) comes from one of those two sources, then I simply don't believe the so-called measurement, and neither should you. Such a measurement means, at best, only that it's probably a relatively big number when compared to the rest of such numbers in the consensus, and the real number is almost certainly larger than this number. is killing the cpu with the number of new conns/s. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without No, not at the present time because that is not reported by the relays. What a relay reports is the highest minimum number of bytes handled in any one second in a ten-second sliding window within the the past 24 hours. That value is then devalued considerably by the fact that the 24-hour periods are not normally consecutive, but rather are overlapped by roughly six hours at each end, so that only the middle twelve of the 24 hours are represented exclusively in a measurement reporting period. The whole reporting setup is wrong and needs to be revamped from scratch in order to get a system that works properly. As I've noted before, the very first and most critical thing to be done is the design separation of throughput capacity (which the clients need to know) from actual service rendered (which only some humans want to know). The rest cannot even be begun until that much is done. knowing about the total provided bandwidth. Probably the best data (i.e., not as bad as any of the other values reported) for that purpose would be found in the extra-info documents. Divide each field by 900 s to get the average rates in B/s. One good thing about the numbers in the extra-info documents is that both bytes read and bytes written are reported. Sorry to disappoint you, Olaf, but that's just the way things are for now. :-( FWIW, I still think it might be worth your time to take a spare machine, if you have one, and install an OS that supports superpages (e.g., FreeBSD 7.2 and later, Windows Vista and later, possibly Windows Server 2008, but I don't know about that one), and then try it long enough to see whether that relieves any of the CPU load. Or, if you're up for some coding and testing, you could try LINUX's support for huge pages, but that facility is neither automatic nor transparent to the application, as I understand it, so it does require additional code. At present, it's very likely that 30% to 45% of your tor relay's CPU time is being wasted in address translation due to TLB misses, even when the needed data or instructions are *already in some level of cache*. If the CPU is stalled because MMU has to walk a page table before it can discover that what it needs is not only already in memory, but already in a cache, the performance hit is a crying shame. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 06:12:43 -0500 (CDT) I wrote: Hi Olaf, On Sun, 11 Apr 2010 12:11:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic You did say observed, not advertised. purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value Remember, there are exactly two vantage points from which valid observations can be made, no more and no less. One is from inside your system's networking stack (including packet filter software). The other is inside your tor relay's process. Unless the value of about 16000 KB (/s) comes from one of those two sources, then I simply don't believe the so-called measurement, and neither should you. Such a measurement means, at best, only that it's probably a relatively big number when compared to the rest of such numbers in the consensus, and the real number is almost certainly larger than this number. is killing the cpu with the number of new conns/s. I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) In any case, if a consensus document volunteers any capacity exceeding the smallest of a node's BandwidthRate, RelayBandwidthRate, or MaxAdvertisedBandwidth, then I believe it should be documented and reported as a bug in the authority code. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without No, not at the present time because that is not reported by the relays. What a relay reports is the highest minimum number of bytes handled in any one second in a ten-second sliding window within the the past 24 hours. That value is then devalued considerably by the fact that the 24-hour periods are not normally consecutive, but rather are overlapped by roughly six hours at each end, so that only the middle twelve of the 24 hours are represented exclusively in a measurement reporting period. The whole reporting setup is wrong and needs to be revamped from scratch in order to get a system that works properly. As I've noted before, the very first and most critical thing to be done is the design separation of throughput capacity (which the clients need to know) from actual service rendered (which only some humans want to know). The rest cannot even be begun until that much is done. knowing about the total provided bandwidth. Probably the best data (i.e., not as bad as any of the other values reported) for that purpose would be found in the extra-info documents. Divide each field by 900 s to get the average rates in B/s. One good thing about the numbers in the extra-info documents is that both bytes read and bytes written are reported. The other things I missed in Olaf's remarks above are *exit* usage and *exit* capacity. If tor ever get proper reporting of throughput capacity, then adding up the capacities of all exit nodes in the consensus or, arguably, the current directory, would yield the total exit capacity because it matters not whether data leave a node for a true destination or just to another node. But the total exit usage question cannot be answered at present because nothing reports that information at present. Whether tor is keeping such information locally but not reporting it either locally or to some authority, I don't know. If it is, then adding a few lines to write the information to a log every so often should be fairly trivial to do. 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
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. relax, I'm not complaining. We are all volunteers not being payed for writing tor code. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. yes, I noticed that without mentioning it on this list. It appears to be a common misunderstanding in coding between 2^10 and 10^3. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) did my node stop publishing its descriptor again? Traffic has dropped about 80% within the last hours. Have a look at the attached graph. Oh, jeez. I thought that one had been fixed a while back. Sigh. Or maybe it's not just *one* bug. But the total exit usage question cannot be answered at present because nothing reports that information at present. maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. Regarding superpages: Is it possible to figure out how much cpu time being wasted in address translation with on-board means like vmstat? But I don't see how because a successful translation stays in the hardware and causes no interrupt. The kernel only sees something when the translation fails. FreeBSD has had steadily growing HWPMC support since 6.0, so I just looked through some of the HWPMC man pages. There are counters for instruction cache misses and data cache misses, but I didn't see any counters at all that involved TLB-related events. That doesn't mean that there aren't any, just that I didn't find any documentation of any. On a moment's thought, that does seem a trifle odd, given that there are counters for lots of strange things, including other performance hits that have far milder consequences per event (e.g., logical CPU cycle lockouts caused by conflict with the other logical CPU in a core, IIRC) than TLB misses have. If I had the Intel processor manuals that describe the various counters that the chips support, I'd have a better clue where to look in the FreeBSD documentation or maybe how to query the hardware itself (using a small utility that is part of the base system) to find out whether there are any TLB-related event counters available. You might dig around in your system to see whether LINUX shows support for any TLB-related event counters. Something else you might check on if you're considering adding scraps of code to tor to use LINUX's huge page support is whether huge pages get page-fixed (a.k.a. wired). FreeBSD's superpages don't. If the kernel decides it has to snatch any base page frames out of a superpage, it simply demotes a superpage to the next smaller page size supported on that processor type, then demotes one of those, etc. until it can free up individual base pages. That means it can't cause the sort of problem that tying up several hundred megabytes of page frames by fixing a large process's pages into them can create for the rest of whatever is running in the same machine because a superpage's base (i.e., underlying, smallest sized) page frames can always be freed for reuse by something else if the system really needs them. On i386 and amd64 architectures, there are only two page sizes (4 KB and 4 MB) available anyway, so there's only one step available in either the promotion direction or the demotion direction. (ia64 (i.e., Itanium) has a several more steps available, IIRC, and I think the alpha processors have about five.) In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. I'm not sure about Xeons, but the regular, non-server i386 and amd64 chips by Intel only have 64 TLB entries for instruction (i.e., text) pages and 64 TLB entries for data (i.e., data and stack) pages, so that means if an instruction working set or a data working set exceeds 256 KB, then the process running with base (4 KB) pages will end up thrashing the relevant TLB(s), stalling the processor every time while the MMU walks through the page table. If you have HTT-enabled Xeons, then remember that the two logical CPUs in each core share the same MMU and L1 and L2 caches, as well as the same bus to and from main memory, which can further
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 10:05:06 -0600 Kasimir Gabert kasimi...@gmail.com wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: =A0 =A0 On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmag= ie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. =A0 =A0 You might communicate with Kasimir Gabert about that. =A0I think = he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. Thanks for responding to that so quickly, Kasimir. It should save Olaf some time. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Did you just use a boxcar average? If so, it will have significant (I'd guess a peak of about 2% of true amplitude) Gibbs ringing in the result, but given the erratic quality of the source data (i.e., the mix of varying lengths of records, times of day, and so forth) and given how the results will be used, it's probably no big deal, and no one is likely to realize the ringing is present when they look at a graph of it anyway. How many 15-minute periods wide is the window? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Cannot Download Bridges
On Tue, 6 Apr 2010 11:29:57 +0200 Mitar mmi...@gmail.com wrote: On Tue, Apr 6, 2010 at 10:58 AM, Scott Bennett benn...@cs.niu.edu wrote: It wouldn't be airtight, to be sure, but it would greatly shrink the window of opportunity for censors to cut bridge users off from the tor network. Of course censors could also just connect to the Tor and use this hidden service to learn about other bridges. Even again and again request new bridges (pretending the previous ones are unreachable) and thus gain the knowledge of all bridges. And that would be different from our current situation exactly how? Besides, hidden services are **S--L--O--W**, which discourages that sort of thing anyway. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: vps
On Thu, 8 Apr 2010 04:16:38 +0800 DC newsw...@gmail.com top-posted: it's up and running now. i followed this https://www.torproject.org/docs/rpms.html.en but my problem is it never got the EXIT status. what could be the problem? i used the same torrc config at home and my home node read as both VALID and EXIT i also noticed in the logs this DNS hijacking warning. If tor finds that your provider is hijacking name server queries, then it is likely to refuse to operate as an exit and will publish discriptors containing a rejection of all ports as an exit policy. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: vps
On Mon, 5 Apr 2010 11:34:24 +0800 DC newsw...@gmail.com wrote: thanks for the replies, that's totally true it's certain that they will give me that bait and switch treatment. the reason im getting that cheap vps is some sort of a learning environment. im totally starting from scratch here, knowing nothing from vps to unix. so im not losing that much with a cheap vps if every thing goes down every now and then. but as soon as i successfully install and run exit node and specially how to secure those datas/logs out from the reach of everyone then i will move immediately to a more expensive vps. hoping while im still learning somehow someone have the patience to guide me. If you're looking for a truly easy way to get started, I'd like to recommend you take a look at PC-BSD 8.0 (see www.pcbsd.org). It seems to take most people, beginners included, about 20 minutes to install and get running. A couple of days ago, a new book by Dru Lavigne was announced on the freebsd-announce list. I'll try to forward you a copy of the announcement off this list. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: a problem about run tor bridge
On Wed, 24 Mar 2010 10:35:05 +0800 wang.wang.test wang.wang.t...@gmail.com wrote: ÓÚ 2010-3-24 10:19, torsecurity дµÀ: Hi, everyone! My computer is behind a NAT and I can connect to the Tor network directly ( not using Tor bridges although I am in China). Now I want to configure my tor as a bridge to let my friend connect to the Tor network. His IP is 172.18.12.xxx. My configuration file looks like: BridgeRelay 1 ContactInfo hegaofeng at seu dot edu dot cn ControlPort 9051 ExitPolicy reject *:* Log notice stdout Nickname ORhgf ORPort 443 PublishServerDescriptor 0 RelayBandwidthBurst 10485760 RelayBandwidthRate 5242880 And my bridge information is: 172.18.12.161:443 But this dosen't work. The Vidalia is always stopping at Loading relay information I use Wireshark and find the TLS handshake is normal. Can anyone tell me why? Thanks a lot! 2010-03-24 Gaofeng He first, you can't run any tor service behind NAT unless you can configure your firewall/NAT in order to enable port forwarding. By the way, what Actually, I think you've overstated that a little bit. Hidden services can be offered by client-only systems and therefore can do so behind a NATing router without any port forwarding beyond what the NAT is already doing. the hell is 172.18.12.161? Who can connect to that thing? Well, one would certainly hope that it's not his real address, now that he's publicized it as being supposedly a bridge address. As far as your second question is concerned, let us hope that the answer is no one. second, I do not think Loding relay information... has anything to do with your recent bridge configuration. In this, you are most likely correct. To offer a relay of any type behind a NATing router, one does have to configure the router with the appropriate RDR for port forwarding, although I confess I've never played with BINAT and therefore have no idea whether there might be a way to make it work for tor. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Full bandwidth is not used.
On Sat, 13 Mar 2010 09:05:03 +0100 Paul Menzel
paulepan...@users.sourceforge.net wrote:
My apologies for letting this sit unanswered for so long. I was tied
up in reconfiguring several disk drives where free work space was cramped
and inconveniently located for some of the moves. Now I'm just starting to
go through nearly two weeks' accumulation of email. Agghhh...
Am Freitag, den 12.03.2010, 19:31 -0600 schrieb Scott Bennett:
Well, as I've pointed out in the past, the values in cached-consensu=
s=20
do *not* accurately reflect either the traffic load that your relay has
carried or the traffic capacity of your relay. They are bogus a priori a=
nd
should be ignored in attempting to ascertain your relay's actual loads.
The sad thing is that recent versions of tor clients now use the consensu=
s
values for designing routes for circuits they will build, so the bogus
values produce load distortions throughout the tor network. However, tha=
t
fact has no bearing upon the numbers you're looking for.
If you want to know the loads that your relay has carried, you shoul=
d
look at the byte counts for reads and writes in the extrainfo documents o=
r,
alternatively, the state file. (The difficulty with using the state file
is that it gets updated everytime construction of a new circuit succeeds,
so the values for the most recent time periods change frequently and at
rather unpredictable intervals. If you always ignore the most recent tim=
e
period for read and for writes, then the state file becomes more usable
for this purpose.) If, OTOH, you want to know the peak 10-second burst
rate, then the value to trust is the one in your relay's descriptors that
appear in the cached-descriptors{,.new} files.
Thank you for your response. I kept that in mind and compared it to the
values in `/var/lib/tor/state` and they are around the same and maybe
even lower. I also use tools like `nload` to verify the network load.
You can also see bandwidth graphs at [2].
I am a little confused why you are responding nitpicking at the values I
give although I think it was confirmed in the whole thread that the full
bandwidth is not used at all.
I'm sorry that my point wasn't made clearly enough. IIRC, you were
wondering why the consensus values didn't match what you were seeing your
router do. (You've deleted the pertinent portion of the message, so I'm
just going by memory here.) The point I was attempting to make is that
there is no good reason to expect to see any close relationship between
the consensus value and what your router does.
Your router may very well have also had some real problem, but the
consensus is not a useful tool for diagnosing throughput capacity problems.
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 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Full bandwidth is not used.
produce load distortions throughout the tor network. However, that
fact has no bearing upon the numbers you're looking for.
If you want to know the loads that your relay has carried, you should
look at the byte counts for reads and writes in the extrainfo documents or,
alternatively, the state file. (The difficulty with using the state file
is that it gets updated everytime construction of a new circuit succeeds,
so the values for the most recent time periods change frequently and at
rather unpredictable intervals. If you always ignore the most recent time
period for read and for writes, then the state file becomes more usable
for this purpose.) If, OTOH, you want to know the peak 10-second burst
rate, then the value to trust is the one in your relay's descriptors that
appear in the cached-descriptors{,.new} files.
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 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [RFC] Campaign »Buy/Sponsor a relay.«
On Wed, 10 Mar 2010 11:41:00 -0500 Andrew Lewman and...@torproject.org wrote: On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel paulepan...@users.sourceforge.net wrote: :on the Tor start page [1] there is a message »Help us reach 5,000 : relays in 2010!« :»I guess for people caring about privacy but not wanting/able to set up :a server themselves can now be told, you can pay 90 pounds a month [for :10 Mbps] and you will improve the connectivity of the Tor network.« [me :on IRC] We turn down funding when organizations ask us to run relays on their behalf. They have the money, but not the technical skills to run relays. The risk to The Tor Project, the non-profit entity, is that we become a target as we could potentially see a large percentage of Tor network traffic. This traffic becomes interesting to law enforcement, criminal organizations, marketers, and others wanting to enumerate Tor users. This same concern is true for the funding organization. A human rights organization wanted to run either hundreds of relays or to see their relay names as the top 10 relays in the Vidalia network map for a year. They almost looked at the network map/relay list as a branding opportunity. However, controlling relays with that much traffic, even if the relays are dispersed around the world, would turn them into a data collection target. I encourage a peer to peer model of getting more relays. Having individuals run a relay and contribute the bandwidth that makes sense seems to be a less risky model. As the risk is spread out amongst hundreds or thousands of individuals. This is a more difficult path than turning lots of money into relays. Ultimately, I believe this path is more sustainable in the long-term. As committed relay operators run them for their own reasons, not for a paycheck. Active areas of research are around everyone as a bridge and everyone as a relay if the tor client finds itself reachable by the outside world. Getting these options correct without screwing users is difficult. However, we are making progress. The everyone as a relay thing has been discussed here in the past ad nauseam and has ended up opposed every time for very good reasons. The everyone as a bridge idea ought to fail for the same reasons, but would have the additional complication of requiring that tor *not* run as a bridge if it is already running as a relay with a published descriptor. One possibility that I don't recall seeing discussed would be to have all *relays* provide directory service on internal circuits, even if no DirPort is open. I'm not at all sure that this would provide any noticeable improvement in the tor network's performance, but it might also be a fairly easy change to make. I would oppose, however, any attempt to require that clients provide directory or other services. In the meanwhile, we need more relays, in particular exit relays, to help speed up Tor for everyone. In the U.S., at least, that effort would be furthered, I think, by a publicity campaign identifying ISPs that provide *full* Internet access to residential accounts, as opposed to ISPs that provide only *partial* Internet access to residential accounts (e.g., Comcast). That would help to provide a marketing advantage to ISPs offering full service over ISPs that don't. It might also be worthwhile to start a complaint-to-the-FCC campaign to report misleading advertising by ISPs that offer only partial access but market it as Internet access as if it were full access. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
repetitive address change message
Something happened to my Internet connection this evening while I was away. When I came back, I called the ISP, and they got it working again. However, once reconnected, my computer got a brand-new IP address assigned on a net I didn't know belonged to them. Shortly afterward, inadyn noticed the change and updated the A RR at dyndns.org to reflect the new address. Soon after that update, tor noticed the change and issued the following pair of messages: Mar 01 23:29:57.619 [notice] Your IP address seems to have changed to 24.1.225.89. Updating. Mar 01 23:29:57.619 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). However, the second message has been repeated quite a few times since then: Mar 01 23:45:12.450 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 00:00:27.402 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 00:15:42.344 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 00:30:57.322 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 00:46:12.357 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 01:01:27.246 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 01:16:42.212 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 01:31:57.256 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 01:47:12.219 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 02:02:27.582 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 02:17:42.971 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 02:32:57.140 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 02:48:12.095 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 03:03:27.027 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). Mar 02 03:18:42.113 [notice] Our IP Address has changed from 98.228.176.208 to 24.1.225.89; rebuilding descriptor (source: resolve). These messages appear to be issued a tad over 15 min. apart. I'm running 0.2.2.7-alpha on FreeBSD 7.3-PRELEASE. Although it was operating as a relay over the weekend, I've swapped torrc files and SIGHUPped tor, so that it closed the ORPort and is now running just as a client. Does anyone have any clue why these messages are being issued? Should I just shut it down and restart it? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
