bandwidth graph ok with 0.1.2.14-dev only
Hello, my OR still periodically shows up a 24 hours sawtooth bandwidth utilization using 0.1.2.15. Regarding the dropping bandwidth every night GMT+2 it behaves exactly like 0.1.2.14. I supposed this issue to be fixed with 0.1.2.14-dev since the bandwidth utilization with 0.1.2.14-dev doesn't change very much over the day. Tuesday to Sunday last week running 0.1.2.15 clearly shows a sawtooth bandwidth. Starting with Sunday evening when I downgraded to 0.1.2.14-dev the bandwidth graph looks ok again. Attached you'll find my snmp network interface based traffic stats for the last seven days. Is there any special code introduced in 0.1.2.14-dev fixing this issue and has been removed again in 0.1.2.15? For the time being I think I'll stick to 0.1.2.14-dev. regards, Olaf inline: anonymizer.blutmagie.de_2-week.png
Re: bandwidth graph ok with 0.1.2.14-dev only
On Wednesday 01 August 2007 09:19:46 Olaf Selke wrote: Hello, my OR still periodically shows up a 24 hours sawtooth bandwidth utilization using 0.1.2.15. Regarding the dropping bandwidth every night GMT+2 it behaves exactly like 0.1.2.14. I supposed this issue to be fixed with 0.1.2.14-dev since the bandwidth utilization with 0.1.2.14-dev doesn't change very much over the day. I've done some light research on this issue and suspect (on the basis of fairly slender analysis) that the problem may not be entirely down to just the version of Tor you're using. The only way to see if it is a factor is to run 0.1.2.14-dev for a while and see if the problem re-appears after a week or two. Would you mind doing that? Is there any special code introduced in 0.1.2.14-dev fixing this issue and has been removed again in 0.1.2.15? For the time being I think I'll stick to 0.1.2.14-dev. Could you state the exact svn revision you're using at the moment? There's no exact release called 0.1.2.14-dev, svn stable branch was given this version name on the 13th July so I'm assuming you're using a particular svn revision from r10822 onwards, sometime between 13th July and 17th July. You can find out the revision by doing an 'svn info' in the tor svn dir. -- Browse Anonymously Anywhere - http://anonymityanywhere.com TorK- KDE Anonymity Manager - http://tork.sf.net KlamAV - KDE Anti-Virus- http://www.klamav.net
Re: What are Tor guards?
you either add anyone who comes up (in which case, someone with a lot of resources can flood the network with compromised ORs) Yep. Known issue. For roughly $50K startup, and $30K/year, someone could reliably determine most or all source and endpoint pairs, and also act as exit node for a large portion of conversations. They would also speed up the Tor network significantly. (100 nodes, high speed dedicated colo lines purchased in bulk.) Tor is nice against industrial espionage, but not against NSA or Firewall of china level attacks.
Re: bandwidth graph ok with 0.1.2.14-dev only
Robert Hogan wrote: I've done some light research on this issue and suspect (on the basis of fairly slender analysis) that the problem may not be entirely down to just the version of Tor you're using. The only way to see if it is a factor is to run 0.1.2.14-dev for a while and see if the problem re-appears after a week or two. Would you mind doing that? sure :-) Could you state the exact svn revision you're using at the moment? I don't think so cause I downloaded this archive at 07/13/07 from http://freehaven.net/~arma/tor-0.1.2.14-dev.tar.gz instead of checking it out with subversion. I just moved it to http://torstatus.blutmagie.de/data/tor-0.1.2.14-dev.tar.gz. Maybe one can take a look what makes it so special compared with 0.1.2.14 and 0.1.2.15. regards, Olaf
Re: Remote Vulnerability in Firefox Extensions
coderman @ 2007/06/21 11:33: On 6/21/07, scar [EMAIL PROTECTED] wrote: ... it seems to me that many addons which are downloaded from https://addons.mozilla.org/ use different, non-https, addresses to check for and download updates. the problem exists when non https is used for updates. any plugins getting updates via http port 80 would be vulnerable. would this vulnerability exist with all of those addons as well? how to find out what address each addon uses to download updates? i haven't tested the various plugins myself. a sniffer should tell you quickly if updates are performed insecurely, though you may need trial and error to determine which one is making the requests if it isn't obvious in the data. this would be a good subject to document on the wiki if you pursue it :) best regards, well, it's clear that noscript uses nonsecure http to download it's update. i think many of us use that add-on. so, how can we safely receive noscript and other add-ons that use nonsecure http updates? do we need to tell firefox to not download the updates, and just notify us? then, we go to https://addons.mozilla.org and manually install the update? or, is there an easier way? signature.asc Description: OpenPGP digital signature
Re: What are Tor guards?
On Wed, Aug 01, 2007 at 12:12:16PM -0700, [EMAIL PROTECTED] wrote 0.5K bytes in 13 lines about: : Tor is nice against industrial espionage, but not against NSA or : Firewall of china level attacks. It's not supposed to be resistant to global adversaries. http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#RemainingAttacks -- Andrew
Re: Torbutton 1.1.6-alpha
Thus spake Kees Vonk ([EMAIL PROTECTED]): I just installed torbutton 1.1.6, restarted firefox (2.0.0.5 on Kubuntu). Clicked on 'Tor Disabled', which changed to 'Tor Enabled'. Then went to janusvm.peertech.org (which told me I was not using Tor), then hit the back button and got a dialogue box with said: False doc hooking. Please report bug+website! (my initial page was: file:///usr/share/ubuntu-artwork/home/index.html). After that I seem to get that error on every page, even when just switching tabs (just opened the above URL in a second tab). Just closed firefox and clicked on the above URL to restart firefox, it restarts with 'Tor Enabled', but no error. Then opened an new empty tab, and then switch back to the initial one and straight away get the error again. (Toggling Tor to disabled stops this behaviour, enabling it again starts it again.) Is this bug reproducible? Does it happen every time for this website even after successive restarts of the browser? I am having difficulties reproducing this... Also when I look at my extensions they don't seem to be disabled. I am using the following extensions: Adblock Filterset.G Updater - 0.3.1.0 Adblock Plus - 0.7.5.1 CookieSafe - 2.0.6 Fasterfox - 2.0.0 Forecastfox - 0.9.5.2 FoxyProxy - 2.5.3 Konquefox - 1.3 NoScript - 1.1.5 Tab Mix Plus - 0.3.6 Torbutton - 1.1.6-alpha View Cookies CS - 1.0.7 At a glance, I would suspect NoScript may be the culprit. If you disable that thing, does the issue persist? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpqk7rWHODfS.pgp Description: PGP signature
