Re: Traffic question
On 2010-09-16 14:41, Michael Gomboc wrote: Hi! I'm wondering why the traffic of my Tor node topped significant this month. Only Tor is running on the server and I did not change any settings. It goes down every day! ... A part of my torrc: *RelayBandwidthRate 150 KBytes RelayBandwidthBurst 200 KBytes AccountingStart day 00:00 AccountingMax 20 GB* Thanx a lot! On my relays, traffic started to drop about 5 months ago. It the years before they were usually relaying at the full RelayBandwidthRate. Maybe there's too much relay bandwidth available? See the relay bandwidth graph at the bottom of the page: http://metrics.torproject.org/graphs.html *** 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?
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/ Getting the wrapper to work with (or like) the OpenBSD version will probably be easier. 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/ *** 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?
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. Someone is working on transparent hugepage support: http://thread.gmane.org/gmane.linux.kernel.mm/40182 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: More important: Bridges or ORs
Gregory Maxwell wrote: On Wed, Sep 2, 2009 at 3:47 PM, Arjann6bc23cpc...@list.nospam.xutrox.com wrote: Maybe the FAQ should advise people with a static IP address to run a relay instead of a bridge? If the IP address of your bridge is static, an ISP or government that filters Tor will eventually find the address and block it. Hm? but if it's dynamic the people who need to use your bridge will be unable to find it. If the address changes once a day or once a month, that's dynamic for me. According to my ISP, my IP address is dynamic too, but it hasn't changed once since I got my ADSL connection almost two years ago. Therefore, my IP address would be of little use for running a bridge.
Re: More important: Bridges or ORs
Roger Dingledine wrote: On Tue, Sep 01, 2009 at 10:47:45PM -0400, Andrew Del Vecchio wrote: I'm currently running my tor node as a bridge, and have been for a couple of months now. Haven't seen much traffic, which I guess makes sense. Which does the community think is more important right now, running as a bridge or as a OR? I'm located geographically in the Northeastern portion of the USA, if that makes any kind of difference. Fortunately, I wrote this up as a faq entry during the June Iran events. :) https://www.torproject.org/faq#RelayOrBridge Maybe the FAQ should advise people with a static IP address to run a relay instead of a bridge? If the IP address of your bridge is static, an ISP or government that filters Tor will eventually find the address and block it.
Re: what is best - speed or stability?
monitor wrote: I run my relay on a VPS with limited bandwidth, so have set it to hibernate every day after 1Gb usage. When I set my RelayBandwithRate to 50kb, this means my relay is running for 12-16 hours per day. It's running longer longer than I would have expected. That may be because it takes a while for the clients to find out that your relay got out of hibernation. If I set it to 25kb, it runs all day - and switching off hibernation becomes possible. When the relay is available all day, it's likely that it will permanently run at the set RelayBandwithRate (that's what happens with my relays). If you're not running a directory mirror, your relay will send and receive about 2 GiB each day (4 GiB total). Which is the most useful option? Longer availability at a slower rate, or limited availability at a higher rate? Someone else may have the answer to that.
Re: Hidden Service Weirdness
Ringo wrote: unfortunately you must run qemu as root to bind to privileged ports like 80, which negates some of the protections you're hoping to provide. Is there a system list that can be edited and have port 80 removed from it? Maybe POSIX Capabilities are an option: http://www.friedhoff.org/posixfilecaps.html
Re: 25 tbreg relays in directory
Jim McClanahan wrote: [...] Certainly, protecting the network is a priority. Protecting uninformed or unsuspecting users gets trickier IMHO. I'll admit this is a bit of a hot-button issue for me and I may have overreacted. But I think care needs to be taken before cavalierly shutting something down to protect uninformed or unsuspecting users. I agree with Ringo 2600den...@gmail.com when he wrote (at Tue, 30 Jun 2009 00:06:01 -0400) Remotely disabling Tor nodes is a slippery slope. In my humble opinion, protecting uninformed or unsuspecting users / relay operators should be a priority. Numbers of relays running a particular Tor version (extracted from the current consensus): 1 0.1.1.19-rc 2 0.1.1.23 2 0.1.1.25 2 0.1.1.26 1 0.1.2.13 2 0.1.2.14 7 0.1.2.16 20 0.1.2.17 11 0.1.2.18 73 0.1.2.19 1 0.1.2.3-alpha 1 0.1.2.9-rc 3 0.2.0.30 (r15956) 32 0.2.0.31 (r16744) 23 0.2.0.32 (r17346) 39 0.2.0.33 (r18212) 1048 0.2.0.34 (r18423) 411 0.2.0.35 1 0.2.0.4-alpha 2 0.2.0.7-alpha (r11572) 1 0.2.1.10-alpha (r17969) 9 0.2.1.11-alpha (r18192) 10 0.2.1.12-alpha (r18423) 1 0.2.1.13-alpha-dev (r19091) 2 0.2.1.13-alpha-dev (r19200) 1 0.2.1.13-alpha-dev (r19220) 11 0.2.1.13-alpha (r18828) 29 0.2.1.14-rc (r19307) 1 0.2.1.14-rc (r19364) 1 0.2.1.14-rc (r19715) 1 0.2.1.14-rc (r19870) 40 0.2.1.15-rc 100 0.2.1.16-rc 8 0.2.1.2-alpha (r15383) 2 0.2.1.7-alpha (r17216) 17 0.2.2.0-alpha-dev Just remove all relays from the directory that are running old versions and only keep 0.2.0.34, 0.2.0.35, 0.2.1.15-rc, 0.2.1.16-rc and maybe 0.2.2.0 listed. You'll only lose about 300 relays, so no big loss. A relay operator should be able to keep his Tor updated. If he doesn't, chances are that his machine will be compromised. That's bad for him. It's also bad for the Tor users (and their anonymity), because some entity might be able to compromise a large number of Tor relays. Relays that are running without the PC owner knowing about it should also be removed. The PC owner might get into trouble with his ISP or government and the relay also has a higher risk of being compromised.
Re: 25 tbreg relays in directory
Niels Elgaard Larsen wrote: [...] I run an TOR-access-point. Users have no way of upgrading TOR on it. They probably do not even know that they are using TOR. If I fail to upgrade the access-point at we lock it out, the users loose the internet connection. And the users are not that anonymous anyway. The wireless traffic is not through TOR. I don't think that redirecting traffic of unsuspecting users through Tor is wise. Using TOR will make things less secure / anonymous for the people using your wireless AP. People using an open, unencrypted, AP can have their traffic sniffed by: - other people nearby - AP owner - ISP of the AP owner - government - ... (depends on the destination) When sending the traffic over TOR, it can also be monitored by: - exit node operators (some owned by crackers / government agencies) - ISPs of exit node operators - governments of exit node operators Since the AP user doesn't know he's using TOR, he will probably transmit information that shows his identity. He may end up on a government watch list, because they know that all TOR users are potential child pornographers / terrorists.
Re: 25 tbreg relays in directory
Martin Fick wrote: --- On Thu, 7/2/09, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: He may end up on a government watch list, because they know that all TOR users are potential child pornographers / terrorists. Give me a break, so are all internet users, so are all people of the world. This kind of silly slurring of tor users is really unnecessary, isn't it? I omitted the ;-) in that example, because I thought it was obvious. I'll rephrase what I meant to say: People who choose to use Tor will think about the consequences. They will encrypt their traffic, hide their identity or simply refrain from transmitting things via Tor that can get them into trouble somewhere on this planet. People who are using Tor without them knowing it, may not be so careful.
Re: Tor bridge not generating any traffic
Scott Bennett wrote: [...] Now that you've published your tor bridge's IP address on this list-- assuming the one you've shown us is accurate, rather than an appropriate substitution for purposes of sending it to this list--you ought to consider contacting your host company in the U.S. to get them to change the IP address and restart tor using the new IP address. The IP address shown above, if correct, will probably be useless anywhere that access via bridges is needed. It doesn't matter much. All bridges with static IP address will probably end up on block lists eventually.
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
Roger Dingledine wrote: [...] But yes, there is definitely a tradeoff here. I'm not sure where the right point in the tradeoff is. But my intuition is that cutting 0.1.2.x relays out of the network would hurt more than help at this point. But for the few remaining 0.1.1.x relays? Hm. You should cut off all insecure relays, because some people might rely on Tor for providing strong anonymity. Security and anonymity should be more important than speed.
Re: Version checking (was Re: 25 tbreg relays in directory)
Nils Vogels wrote: IMHO, just adding a list of allowed versions in the consensus will accomplish just that, without the need of all that extra traffic and CRC complexity. Use as much donated network capacity as possible without reducing anonymity by treating exit nodes and other nodes differently: - Old exit nodes: Use them, but increase the circuit length by 1 - Other old nodes: Don't use them at all Old versions that are remotely exploitable should be automatically shutdown. Maybe the directory authorities could instruct them to do that?. If that's not possible, they should not be listed in the directory to reduce the risk of them getting compromised. That won't help for existing nodes with static IP, but it will help in other cases.
Re: aes performance
Olaf Selke wrote: hello there, as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node. For the sake of better performance I'm thinking about replacing my tor node's hardware. If you're going to replace hardware, hardware assisted encryption may be an option. Recent VIA CPUs like the C7 and the Nano can do that. Their clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. Resuls for VIA Nano (with 32-bit openssl): VIA Nano 1.6 GHz with padlock engine type 16 bytes64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 69796.09k 275407.68k 585574.57k 815018.33k 920136.36k aes-192-cbc 52670.82k 208539.14k 472485.55k 691277.82k 798340.44k aes-256-cbc 50984.77k 201934.27k 439964.25k 623764.14k 709612.89k VIA Nano 1.6 GHz without padlock engine type 16 bytes64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 41429.86k 55836.29k 60886.87k 62508.03k 62974.63k aes-192-cbc 35838.02k 47521.62k 51671.72k 52854.10k 53177.00k aes-256-cbc 33208.77k 41789.16k 45009.83k 45891.24k 46153.73k Performance for 16-byte blocks is pretty poor, but for bigger blocks it's much faster. A VIA C7 running at the same clock frequency should produce similar results.
Re: aes performance
John Brooks wrote: You're mistaken here. [...] My point was that the '16 bytes' column was showing significantly worse results than the other columns. It's because of overhead for more function calls, setting up keys, setting up initialization vectors, ... All of that aside, the encryption speed is a non-issue here. Unless you're using a large portion of a gigabit connection, AES will work far faster than your line speed on a modern processor. Additionally, just measuring the speed of that algorithm is very far from the entire story; there are MACs involved and tor has its own things that need to be applied, including layers of encryption. Still, I don't see encryption being a large issue for any but low-powered machines with high bandwidth connections. Encryption speed is indeed only part of the problem, but on my LAN (with a few years old hardware), the VIA Nano is by far the fastest when doing SFTP file transfers or disk encryption.
Re: aes performance
coderman wrote: On Mon, Feb 23, 2009 at 8:23 AM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: ... It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. i think you mean buffers (or at least multiples of 16 byte blocks); and yes the 4096 byte or larger buffers would be nice to get the most of the rep style XCRYPT instruction chaining. Yes, that's what I meant. ... clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. it is also worthwhile to accelerate the public key ops with MONTMULT on the padlock core. there is assembly optimized code for this in openssl 0.9.9 (work in progress). the bottleneck for Tor on these CPU's becomes the libz compression/decompression overhead with padlock enabled. My upload speed is much too slow to run into this problem, but could the compression be (partially) disabled for middle nodes? I'm assuming that the data they are relaying has already been compressed + encrypted, so it wouldn't compress much anyway.
Re: Avoiding HTTPS pitfalls [was: Re: Moxie Marlinspike]
coderman wrote: On Thu, Feb 19, 2009 at 4:17 AM, Erilenz eril...@gmail.com wrote: ... [...] I wonder if something could/should be built into TorButton to force a list of commonly used services to go entirely over https? Eg any request for ^http://mail\.google\.com/.*$ a plugin to enforce secure cookies and https only operation for some domains would be useful. i don't know of any that do this kind of thing yet... Noscript has some options (Options, Advanced, HTTPS) that may help. Disclaimer: I've not used these options and I don't know if it's secure.
Re: tor over ipv6
Udo van den Heuvel wrote: Just a thought: With the previous tor experiences in mind w.r.t. services blocking me, I thought about IPv6. I could run a somewhat open relay on an IPv6 number via a IPv6 in IPV4 tunnel if I (ever) get that to work. My isp (xs4all) offers such a tunnel for free and a (small?) IPv6 subnet to go. The subnet (/48) isn't exactly small. It's 2^80 addresses ;-) Try setting one up. Their Service Centre page can even create example configuration files for you. Note to other readers: The XS4ALL tunnels are for customers only. I wouldn't recommend running an exit from XS4ALL IP space. The last time I tried, it only took a few hours before they disconnected me. a) does tor work well with IPv6? As Nick said, unfortunately it does not work at all. The three-year development roadmap didn't mention IPv6 plans either (the roadmap document only briefly pointed to the proposals). b) how is the added value for the tor network? (IPv6 vs IPv4?) IPv4 addresses are running out: http://www.potaroo.net/tools/ipv4/index.html This means that IPv6 usage will go up. It has gotten much better in the past year. Check the yearly graph for the Amsterdam Internet Exchange (bottom graph): http://www.ams-ix.net/technical/stats/sflow/?type=ipv6 IPv6 has the added advantage that there's no NAT. More people will be able to run Tor relays. c) how well would the IPv6 setup work w.r.t. my IPv4 number(s) being blocked by whatver server/service/etc. When using 6to4 or Teredo, your IPv6 addresses are derived from your IPv4 address. This means that when one is known, the other is known (and can be blocked) too. When using native IPv6 or a tunnel from a tunnel broker, the IPv6 and IPv4 addresses aren't related. d) any actual operational experiences here? IPv6: Yes Tor: Yes And I'm willing to try IPv6 + Tor Anyone? For anyone who wants to try IPv6: - You can get a free tunnel from a tunnel broker: Hurricane Electric: Easy to sign up and they have IPv6 certification tests to let you demonstrate your IPv6 skills: http://tunnelbroker.net/ SixXS: Signing up takes a little more effort. Privacy is a bit of a concern, but very recently it got better because they now allow you to hide your user details in the whois database: http://www.sixxs.net/ - Or use 6to4 http://en.wikipedia.org/wiki/6to4 - Or use Teredo http://en.wikipedia.org/wiki/Teredo_tunneling SixXS (aiccu) and Teredo are easy to setup. It should work with practically any IPv4 NAT setup. Hurricane Electric, 6to4 and XS4ALL use protocol 41 IPv6 in IPv4 tunnels and may be more difficult/impossible to setup, depending on your modem/router/firewall.
Re: User tor issue
Udo van den Heuvel wrote: pho...@rootme.org wrote: On Tue, Dec 30, 2008 at 03:48:10PM +0100, udo...@xs4all.nl wrote 1.0K bytes in 32 lines about: - Low traffic According to http://torstatus.blutmagie.de/router_detail.php?FP=5c7fc21ea828d2c2451bb1f5da191d59db1dd5cb, you're using the defined bandwidth now. Thanks but... Bandwidth it is configured at 2 bytes. So that would be 160 kbit/s. I am nowhere near that, not even in peaks. Or am I misunderstanding/misreading? You're correct. It should be about 100 times higher. Compare your graph and bandwidth settings with that of this randomly picked router: http://torstatus.blutmagie.de/router_detail.php?FP=611a96764577d2a2ff490666ba732382bae08bbc
Re: User tor issue
Udo van den Heuvel wrote: People, I noticed that my tor process was running as a user '_tor' but that torrc specified 'tor' as user. (possibly a migration issue) Once I corrected this my tor traffic because 'much' higher: http://pindarots.xs4all.nl/mrtg/tor.html Even with the 'much' higher traffic, it looks extremely slow to me with an average of 100 - 200 bytes per second. Why doesn't traffic get anywhere near the tor bandwidth limit settings?
Re: User tor issue
pho...@rootme.org wrote: On Mon, Dec 29, 2008 at 06:51:13PM +0100, n6bc23cpc...@list.nospam.xutrox.com wrote 0.5K bytes in 11 lines about: : Even with the 'much' higher traffic, it looks extremely slow to me with : an average of 100 - 200 bytes per second. Why doesn't traffic get : anywhere near the tor bandwidth limit settings? If you've just started the server, it will take a while for clients to start using it as a relay. Don't worry, Tor will consume all bandwidth you give it. According to the yearly mrtg graph it never gets much higher: http://pindarots.xs4all.nl/mrtg/tor.html The torstatus graph agrees with mrtg: http://torstatus.blutmagie.de/router_detail.php?FP=5c7fc21ea828d2c2451bb1f5da191d59db1dd5cb
Firewall update (if you're filtering bogons)
The list of IPv4 Global Unicast Address Assignments got updated yesterday: http://iana.org/assignments/ipv4-address-space/ The previously unallocated prefixes 110/8 and 111/8 have been allocated. Please remove them from your firewall filter if you're filtering bogons.
Re: Questions about bogon filtering [Was: Re: Firewall update (if you're filtering bogons)]
F. Fox wrote: Arjan wrote: The list of IPv4 Global Unicast Address Assignments got updated yesterday: http://iana.org/assignments/ipv4-address-space/ The previously unallocated prefix 197/8 has been allocated. Please remove it from your firewall filter if you're filtering bogons. A question: Does filtering bogons really help security all that much? I would think that about all it'd be good for would be dropping packets with spoofed IDs - but in the case of a DDoS, where such a thing is likely, they've accomplished their goal simply by having the packet get across your uplink and bounce off your firewall. I suppose it could help spare load on a server in the case of a SYN flood directed towards one, but I would think it wouldn't be all that hard to adjust the RNG algorithm (or counter, or whatever) to have the spoofed IPs on the packets generated only in non-bogon space. You're right that it doesn't help security, but I prefer to filter all traffic that's not supposed to come from / go to the internet. Filtering invalid outgoing traffic should help me stay out of trouble with my ISP.
Attempting to connect to nodes in bogon space
My tor middle node (0.2.0.31) tries to connect to some bogon IP addresses and I was wondering why it does that. Bogons in my firewall log: 1.50.130.65:9001 5.33.91.234:9001 5.66.101.27:9001 5.72.245.97:9001 5.96.52.246:9001 5.207.116.85:443 5.224.51.41:443 5.255.213.66:443 23.215.10.223:9001 36.234.6.234:9001 37.8.13.163:443 103.3.4.204:443 According to the IANA, the IP addresses above are all bogons: http://www.iana.org/assignments/ipv4-address-space/ Prefix Designation Status - -- -- 001/8 IANA UNALLOCATED 005/8 IANA UNALLOCATED 023/8 IANA UNALLOCATED 036/8 IANA UNALLOCATED 037/8 IANA UNALLOCATED 103/8 IANA UNALLOCATED (note that bogon space is much bigger than the few lines I did put here) Lots of entries from bogon space are listed in the directory. Maybe the directory should be cleaned up? Here's an IP address that's also in my firewall log: r Unnamed H6J0l5pqLdXGRF3TRtwObv58BQ8 UThYzaccGtpl3tnbfiAkqwZeLXA 2008-09-22 10:15:32 36.234.6.234 9001 0 s Valid opt v Tor 0.1.2.14 The other IP addresses in the firewall log aren't listed in the current directory, but maybe they were recently removed?
Re: OnionCat -- An IP-Transparent TOR Hidden Service Connector
Bernhard Fischer wrote: OnionCat creates a transparent IPv6 layer on top of TOR's hidden services. It transmits any kind of IP-based data transparently through the TOR network on a location hidden basis. You can think of it as a point-to-multipoint VPN between hidden services. Although I don't have a practical use for it right now, I just had to try this, because it's something with IPv6 in it ;-) Installation is easy (but because of the root requirement for creating the tun device, I had to run it in a virtual machine). I tried your ping and http examples and it works fine for me.
Re: Tor security advisory: Debian flaw causes weak identity keys
Roger Dingledine wrote: SUMMARY: This is a critical security announcement. A bug in the Debian GNU/Linux distribution's OpenSSL package was announced today. This bug would allow an attacker to figure out private keys generated by these buggy versions of the OpenSSL library. Thus, all private keys generated by affected versions of OpenSSL must be considered to be compromised. One of my tor nodes was affected. I've upgraded openssl and changed keys. Two questions: Do I have to do something to get the old key blacklisted to make sure that someone can't impersonate it? (Old fingerprint: $C33ABC15B69DA274588CA1869CC1EE7B1DC11DAD) Should I rename my node? It doesn't show up as named anymore because of the key change.
Re: Tor relay shutted down by ISP
Tom Hek wrote: This morning is a friend of mine also was disconnected from the internet because XS4ALL thinks there is a Trojan running on his system. He also runs Tor on his system.. I'll keep you guys posted. This also happened to me and at least one other person. In my case it was because of trojan activity on IRC. I was using the default Tor exit policy at that time, which, as it turns out, isn't restrictive enough. XS4ALL told me that it's OK to run a non-exit node, which I'm running now. There's a number of other non-exit nodes in XS4LL IP space, including the node of one of the XS4ALL founders, so running a non-exit node seems to be fine.
Re: Tor relay shutted down by ISP
Tom Hek wrote: This also happened to me and at least one other person. In my case it was because of trojan activity on IRC. I was using the default Tor exit policy at that time, which, as it turns out, isn't restrictive enough. XS4ALL told me that it's OK to run a non-exit node, which I'm running now. There's a number of other non-exit nodes in XS4LL IP space, including the node of one of the XS4ALL founders, so running a non-exit node seems to be fine. Yep, I'm going to run a non-exit node too.. But I really want to run an exit node and I really don't like it that XS4ALL is filtering me because of that.. They aren't filtering Tor exit nodes, but they check for bad traffic coming from their IP space (spam, trojans, viruses, cracking, ...). With a Tor exit node, that will happen sooner or later.
Re: funneling a wireless net's outbound connections through tor
Scott Bennett wrote: [...] Governments are incomparably more dangerous than any 13-year-old or even ISPs. Also, given the number of teenagers who have cracked well funded web servers, I'd say that said teenager is still not out of the loop without tor. [...] Not using tor at all is far more dangerous in my view. In this case, using TOR will make things less secure / anonymous for the people using your wireless AP. People using an open, unencrypted, AP can have their traffic sniffed by: - other people nearby - AP owner - ISP of the AP owner - government - ... (depends on the destination) When sending the traffic over TOR, (part of) it can also be watched by: - all exit node operators (some owned by crackers / government agencies) - their ISPs - their governments Since the AP user doesn't know he's using TOR, he will probably transmit information that shows his identity. He may end up on a government watch list, because they know that all TOR users are child pornographers / terrorists. Take a look at this too (it was mentioned on this list before): http://www.derangedsecurity.com/time-to-reveal%e2%80%a6/ You should inform the users about TOR, before letting them use it. It's less convenient, but it's much more secure for them. Not using TOR at all would be even more secure for them, but then your IP would show up when your users do bad things. Some ideas: Manual proxy setup - redirect non-proxy http / https traffic to a page with setup information for your proxy - allow traffic to your proxy - block all other traffic VPN, using PPTP or something like that - redirect non-VPN http / https traffic to a page with setup information - redirect all VPN traffic through TOR - block all other traffic I prefer a VPN solution, because of the wireless link encryption. It should also work for any application that doesn't know about proxies. Arjan
