SIGNAL NEWNYM and firefox browser settings
if you are having problems with SIGNAL NEWNYM having no effect it may be firefox browser settings that are keeping a cached tcp session to the target host (and/or proxy). verify that the following are disabled in about:config network.http.keep-alive = FALSE network.http.max-persistent-connections-per-proxy = 0 network.http.max-persistent-connections-per-server = 0 pipelining is OK. it does not matter if the following are on or off: network.http.pipelining network.http.proxy.pipelining it is suggested that these be enabled for better performance. best regards,
Re: Sampled Traffic Analysis by Internet-Exchange-Level Adversaries
Thus spake Paul Syverson ([EMAIL PROTECTED]): Anyway, the main reason I'm writing is that my objection was not just that the GPA was too strong but that it was too weak. Thinking you could have an adversary powerful enough to monitor all the links necessary to watch your whole large network but not able to do any active traffic shaping at all anywhere seems obviously nuts. This is one reason why padding on an open low-latency (lossless) network is problematic: an adversary with any active capability at all can induce a timing channel easily. Actually, I'm going to disagree slightly because I don't feel like sleeping yet :). It would take far less resources to passively tap the traffic and filter out say Tor IPs and do analysis on just that data offline. Trying to actively do that filter in-path PLUS arbitrarily delay (ie queue in memory) that traffic in real time, all without signficantly affecting pass-through traffic seems like it would be a lot more expensive. Also, not to mention there is a limited number of bits that can be reliably encoded in this manner, and the purturbations of padding that shares the same TLS connection will lower this effectiveness. The adversary needs enough bits to get through to be able to track all the parties it is interested in. If padding is in place, it will have to spend considerable effort in redundancy to make sure that the timestamp remains present in the exit stream.. Which again means more queueing and more expense. Of course, it also means more expense on the part of the anonymity network in wasted bandwidth.. If padding slows down the network to the point where users start to leave, other, more dangerous effects take over. Finally, going on what has been disclosed so far in the EFF v ATT case, it would seem that global adversary-style mass surveilance is in fact ocurring passively, out of path. At least the illegal domestic stuff, anyways. I suppose it's anyone's guess what they do when it's less blatantly illegal.. Maybe Echelon is the reason my bbc is so slow! :) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp0Pyj2XtyR3.pgp Description: PGP signature
Re: Ideas on increasing the significance of tor
Michael_google gmail_Gersten wrote: The best I can conclude, from limited observations, is that CPU overhead is critical. yep, at about 4500 KB/s the cpu running the tor main thread is loaded with 100%. The other three cpus are left almost idle. Mrtg motoring of my box clearly shows what's going on with throughput and cpu load. Thus I'm bothering this mailing list with more enhanced multithread capabilities, taking better advantage from multiple cores. regards, Olaf
RE: Wanted feature / option
Spammers use other peoples hacked PCs to send messages and the 'reply to' addresses are faked. So all in all, rather pointless... Regards, Tony. From: [EMAIL PROTECTED] on behalf of Kyle Williams Sent: Wed 30/05/2007 04:54 To: or-talk@freehaven.net Subject: Re: Wanted feature / option I was testing a spam-reply script and or-talk@freehaven.net got into it somehow. My bad, sorry. On 5/29/07, Kyle Williams [EMAIL PROTECTED] wrote: FIRST AND FINAL WARNING You have 48 hours to remove me from your mailing list. If you do NOT remove me, I will DDOS (Distributed Denial of Service) your server until you are broke. Try me, I got 10 OC192's, 15 OC48's, and 8 OC12's just waiting for shit like this...and I'm getting pissed. If you are working for yourself or some spam king, either way the customer who is paying you to advertise will NOT be happy when they spent their money to be only be attacked in return. Remove me or else I remove your source of revenue. Again, FIRST AND FINAL WARNING Have a nice day and get a real fucking job. On 5/26/07, Michael_google gmail_Gersten [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I finally realized what feature I'd like to see. CircuitMinimumBandwidth. Have a config option to tell Tor how much CPU time it can expect to give to processing onions (which will tell it how many active connections it can handle) (Or tell it directly how many active ones it can handle). Tor knows the total bandwidth it has to use. There's good heuristics for telling how much bandwidth a connection will need. (Most will need a high initial push, and then occasional, intermittent spikes; if a connection needs a lot for more than N seconds, it's likely to need a lot for a while longer. Etc.) There's a way to tell when the CPU limit will prevent any more data transmission. Combined, this would allow a node to refuse non-specific node requests (normal circuits would be blocked if the tor server is busy, but a .node.exit would still be allowed). This would also eliminate any perceived slowness of tor -- no longer would I see 22 MB nodes in my path, yet dialup users could still use them. If I have a 1300 MB node in my path, I know it can handle my 150 request, and not be either so swamped that I'm only seeing 15, or so overloaded that it's past it's CPU limit. Equally, I know that I can tell tor (without having to use nice) not to steal all my CPU while I'm using my computer. Potential problems? What would we do if we could not find a viable circuit? What if every node is asked and reports Busy -- how do we tell the user that Tor is full, or should a lowspeed connection be made anyways? winmail.dat
Re: Ideas on increasing the significance of tor
Mrtg motoring of my box clearly shows what's going on with throughput and cpu load. Thus I'm bothering this mailing list with more enhanced multithread capabilities, taking better advantage from multiple cores. Two ideas : run multiple instances (and use family option), and let each instance handle ($X) amount of traffic. Since TOR doesn't thread itself very well, that's one way to do it (sort of like what you've got to do with Snort). (or) run tor using hardware crypto acceleration (it's sort-of supported, usually via patches to OpenSSL) Side note to developers .. why not create one parent thread and ($n) worker threads (like Apache, etc. does) to solve this?
Bandwith donation for some days ?
Hi, There will be the chaos-communication-camp in August in Germany (http://events.ccc.de/camp/2007/intro) with a 10G uplink. And since this is never really used, I thought it would be a nice Idea to set up some tor-servers there. They will be online only for 4 days but will have quite some bandwidth. My question is: Does this make sense ? Will the directory-Servers update fast enough to promote these servers ? Shall I do anything in advance (e.g. register nicknames) ? Does this help in any way ? Cheers, Christoph -- GPG-Fingerprint: 88DA B106 D973 B2AF 7CCB 725A F76C 803C 758F 71C0 GPG-Key: http://www.kluenter.de/chris.gpg
Re: Bandwith donation for some days ?
On Wed, May 30, 2007 at 05:26:10PM +0200, Christoph wrote: There will be the chaos-communication-camp in August in Germany (http://events.ccc.de/camp/2007/intro) with a 10G uplink. And since this is never really used, I thought it would be a nice Idea to set up some tor-servers there. They will be online only for 4 days but will have quite some bandwidth. My question is: Does this make sense ? Yes. We had a lot of Tor servers running at 23C3. Will the directory-Servers update fast enough to promote these servers ? Yes. They should start seeing use a few hours after they are set up. Shall I do anything in advance (e.g. register nicknames) ? No need. Does this help in any way ? Yep. Thanks! One last note -- are they all going to be using IP addresses from the same /16 network, or will the IP addresses be more diverse than that? --Roger
Re: Bandwith donation for some days ?
On Wednesday 30 May 2007 17:32:50 Roger Dingledine wrote: One last note -- are they all going to be using IP addresses from the same /16 network, or will the IP addresses be more diverse than that? I don't know yet. Since it seems to make sense, I will contact the NOC for the camp and start planning. I will tell you as soon as I know more. Christoph -- GPG-Fingerprint: 88DA B106 D973 B2AF 7CCB 725A F76C 803C 758F 71C0 GPG-Key: http://www.kluenter.de/chris.gpg
Re: Bandwith donation for some days ?
On 5/30/07, Christoph [EMAIL PROTECTED] wrote: ... There will be the chaos-communication-camp in August in Germany (http://events.ccc.de/camp/2007/intro) with a 10G uplink. And since this is never really used, I thought it would be a nice Idea to set up some tor-servers there. if there is anyone with a VIA C7 system they could use there i would love to assist with a padlock accelerated openssl/Tor node. i do not have a link where i can test myself, and this would be a useful opportunity to see how much crypto offload improves throughput. i've listed raw openssl stats in a previous message to this list, along with a link to a patch that combines the MONTMULT acceleration for RSA/DSA with the patches for AES/SHA offload via padlock dynamic engine. [my expectation is that zlib compression of traffic will become the new bottle neck, as crypto overhead drops off. i am very interested to see a real world test though...] best regards,
