Re: tor trying to pop mail from random IPs on win32
On 8/20/06, Tor question [EMAIL PROTECTED] wrote: Is there a reason why tor would try and POP mail from random IPs while running in Windows? I have a log from AVG Antivirus that shows tor is trying to POP mail. The process number is tor's process id number at the time that it happens. Also, I do not have any mail client installed on that machine that might be trying to POP mail Your machine may be configured as TOR exit-node, allowing POP3 exit. Have you ever changed your tor config files manually ? Greetings, Nils -- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
Unable to start Tor in Cygwin
Hi, I complied Tor in Cygwin successfully, but when trying to start Tor, I got the following messages and Tor exits. Aug 21 20:23:55.890 [notice] Tor v0.1.2.0-alpha-cvs. This is experimental software. Do not rely on it for strong anonymity. Aug 21 20:23:55.905 [notice] Initialized libevent version 1.1b using method poll. Good. Aug 21 20:23:55.905 [warn] set_max_file_descriptors(): Could not set maximum number of file descriptors: Too many open files Aug 21 20:23:55.905 [warn] Failed to parse/validate config: Problem with ConnLimit value. See logs for details. Aug 21 20:23:55.905 [err] tor_init(): Reading config failed--see warnings above. I also tried to start Tor with the option ConnLimit, such as tor ConnLimit 100, but still failed... Dos anybody here know where the problem is? Any hint? Thanks in advance. Hanru
Re: Exit Node sniffing solution...an idea...
4. A couple dozen _fast_ 24x7 exit nodes are run by trusted operators (read: known personally by Nick or Roger) on a local machine the operators control. The $3_letter_agency would just *love* to have a dozen places (or 2 people) they already know about to serve the subpoenas. 7. All Tor traffic exits from these .EXIT.onion nodes. Again .. you've just defined where to wiretap. The beauty of TOR is that anybody, anywhere can setup an exit node. The design of the network allows an operator to sniff the exit, but still can't tell where it came from. If you're using TOR, you shouldn't be using your name in the first place (what's the point of *anonymously* identifying yourself?). I know there are other arguments for TOR like defeating geolocation, but if that's all you're after, there are easier ways to do it (like just rent a shell account somewhere and use SSH redirection). /mike.
Re: Exit Node sniffing solution...an idea...
On Fri, Aug 18, 2006 at 08:49:07PM -0700, Anothony Georgeo wrote: Hi, I have been thinking about the issue of exit node operators and/or adversaries sniffing clear-text ingress/egress traffic locally and/or remotly on an exit node. I have a possible solution but I would like the Tor devs. and experts here to weigh-in. If this won't work feel free to ignore this thread...or just belittle me ;-) Erk. I hope I'm not *that* rude. :) [...] -- Possible Solution: 4. A couple dozen _fast_ 24x7 exit nodes are run by trusted operators (read: known personally by Nick or Roger) on a local machine the operators control. This would pretty much restrict exit nodes to a few places in the US and Europe, since that's where the exit node operators we know are. It would limit the scalability of the network pretty badly, and that's a problem, since we need to accommodate more users, not less. Also, A local machine the operators control would be insufficient and troublesome. If we want to lower the likelihood of eavesdropping, we'd need to make sure it wasn't on an easily eavesdropped network (like, say, a university net). Local would mean no collocated hosts, and no hosts at your place of work. So we'd basically be limited to people that Roger and I know personally who have very fast network connections to their homes and who want to run an exit node. That is not a big list... and because it's not a big list, it would make us more vulnerable to certain attacks: - End-to-end correlation attacks get easier, since fewer exits means fewer points that a roving adversary would need to eavesdrop on in order to see all traffic leaving the network. - Legal/social/online DOS attacks get easier, since fewer exits means fewer people you need to sue/intimidate/flood in order to take down the network. 5. These trusted exit nodes would be setup as Hidden Services (ex. www.6sxoyfb3h2nvok2d.EXIT.onion). 6. Tor would be updated to use these .EXIT.onion nodes randomly as it now randomly chooses regular exit nodes. 7. All Tor traffic exits from these .EXIT.onion nodes. Technically speaking, hidden exit nodes are a pretty cool idea -- but I don't think they achieve what you want. If nobody knows where the exit nodes are, it's _harder_ to tell whether they're trustworthy, rather than easier. Now, perhaps you meant that only Roger and I should know where the exits were. But that would create problems: - It would turn Roger and me into a single failure point with respect to the network. For obvious reasons, I'd like to *minimize* the number of viable attacks on the network that start with Send thugs to threaten Nick; this would create a new one. ;) - It would require us to operate in secret, without oversight. This would reduce confidence in the network. - It wouldn't work so well, since an attacker could easily enumerate the exit nodes by just making a series of connections via Tor to a website they control, and looking at which IPs those connections come from. Still, technically, it's a very cool notion. I don't think it's useful *here*, but I kinda hope we eventually come up with something it's good for, so I have an excuse to implement it. ;) [...] 10b. Not associating IP's with .EXIT.onion operators on the 'closed' list should offer an extra layer of anonymity for the operators. 10c. Due to the fact an .EXIT.onion node operator can not be associated to any perticular .EXIT.onion node there may be less liability for the operator. Again, if you want to know who's running [X].exit.onion, you could just make a connection to your own website via [X].exit.onion, and see whose IP it comes from. Also, if it's not easy to prove that you're running a Tor exit node, you will IMO have a _harder_ time defending yourself if somebody tries to accuse you of originating traffic that your exit node delivers. 11. ISP's, websites, etc may not be able to block these servers as the IP's of the .EXIT.onion nodes are not associated to the nodes. (is this correct?). Being hard to block at the exit side is not a goal of Tor. We want it to be _easy_ for websites that don't want anonymous traffic to block us. Being blockable discourages administrators from taking an adversarial stance to our software, and has in several cases actually encouraged people to improve their authorization systems to not rely on IP blocking for security. See http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#WhyBlockable for more rationale. [...] yrs, -- Nick Mathewson pgpveR29DzdlM.pgp Description: PGP signature
Re: Exit Node sniffing solution...an idea...
On 8/21/06, Michael Holstein [EMAIL PROTECTED] wrote: If you're using TOR, you shouldn't be using your name in the first place (what's the point of *anonymously* identifying yourself?). I know there are other arguments for TOR like defeating geolocation, but if that's all you're after, there are easier ways to do it (like just rent a shell account somewhere and use SSH redirection). /mike. It's not just defeating geolocation. It's about not having your IP address tied to your identity (at least, not without collusion with your ISP). I suppose renting a shell account somewhere and using SSH redirection, only when identifying yourself and for no other purpose, would solve approximately the same purpose. But that's a lot more complicated (and a little more expensive) than just using Tor and making sure you clear your cookies before logging in and after logging out of any services where your identity is revealed. Plus you'd have to have a different SSH account for every single pseudonym you use. Anthony
Re: following on from today's discussion
(moving back to or-talk) On 2006.08.21, at 13:06, Robert Hogan wrote: On Sunday 20 August 2006 23:19, Chris Palmer wrote: Jay Goodman Tamboli writes: Is it true that your traffic is more likely to be eavesdropped upon? We can only speculate. End-to-end encryption... It's not a matter of speculation. Using Tor expands the number of potential eavesdroppers by at least the number of exit nodes in the Tor network. While it's true the number of potential eavesdroppers across all connections increases that much, the number of potential eavesdroppers for any one connection or at any single time would seem to increase only a little. That is, without Tor you have your ISP and whatever computers are between it and your destination, and with Tor you have the exit node operator, his ISP, and whatever computers are between it and your destination. Whether the exit node operator is likely to eavesdrop is, I think, speculation. /jgt -- http://tamboli.cx/ PGP Key ID: 0x7F2AC862B511029F
Re: following on from today's discussion
Thus spake Matej Kovacic ([EMAIL PROTECTED]): Hi, A handful of hosts could run this thing and publish their results, perhaps along with some other manually created list of undesirable exits. Great, that could be an interesting research. However, if someone is doing this (injection/modifying) not all the time, it would be harder to detect him. Yeah, thats why we need a few people running it continuously over a long period of time. It serves as a deterrent that the network is actually monitoring for this behavior, since nodes doing this will eventually be noticed. Though for botnet operators who presumably are able to sign up their botnet hosts as tor nodes anonymously via their own relay network, they may not care if the individual nodes are caught or not.. Scary thought. I've managed to keep myself sufficiently insulated from shiny things, and have finished a script that uses Tor to md5sum a list of URLs and also track the SSL certs of a list of https hosts. This script saves corrupted files, so if we catch infected exes, it's possible we can use these samples to go after botnet command and control. That ability may also be a sufficient deterrent to keep teh snakes off teh Tor. I also have a seperate script that parses the Tor directory and choses nodes based on exit port policy and bandwidth. I'm working to make this one operate with the tor control port to actually build and attach circuits and inform the first script which exit node it is choosing via a named pipe. This way we can experiment with different strategies for choosing exit nodes to scan, short path lengths, and so on easily. I'd guestimate about 2 days before I have a prototype that works fully with a fixed list of URLs. Possibly end of next weekend before I have something that picks docs exes randomly off google. P.S. Does anyone know a clean way to do line-buffered select()able socket IO via perl? From looking at IO::Socket it seems like the timeout is only used for accept/connect... I may have to restort to multithreaded perl.. *shudder*. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Re: following on from today's discussion
On Monday 21 August 2006 18:20, Jay Goodman Tamboli wrote: (moving back to or-talk) On 2006.08.21, at 13:06, Robert Hogan wrote: On Sunday 20 August 2006 23:19, Chris Palmer wrote: Jay Goodman Tamboli writes: Is it true that your traffic is more likely to be eavesdropped upon? We can only speculate. End-to-end encryption... It's not a matter of speculation. Using Tor expands the number of potential eavesdroppers by at least the number of exit nodes in the Tor network. While it's true the number of potential eavesdroppers across all connections increases that much, the number of potential eavesdroppers for any one connection or at any single time would seem to increase only a little. That is, without Tor you have your ISP and whatever computers are between it and your destination, and with Tor you have the exit node operator, his ISP, and whatever computers are between it and your destination. Whether the exit node operator is likely to eavesdrop is, I think, speculation. /jgt That's correct - the activities of individual exit node operators is purely in the realms of speculation. But what is not speculation is that some of them are eavesdropping. 'Among other things, Tor is a handy tool for harvesting random username/password pairs.' I believe that's a true statement. And that's why I think Tor traffic is more likely to be eavesdropped upon: because it is as much a hacking tool for scriptkiddies as it is an anonymity network client for everyone else. That's my only point really. Tor has a specific layer of exposure that is easily accessible to anyone who is interested in it. That is not true of non-Tor traffic. -- KlamAV - An Anti-Virus Manager for KDE - http://www.klamav.net TorK - A Tor Controller For KDE - http://tork.sf.net
Re: following on from today's discussion
On Monday 21 August 2006 19:05, Chris Palmer wrote: Robert Hogan writes: It's not a matter of speculation. Using Tor expands the number of potential eavesdroppers by at least the number of exit nodes in the Tor network. I understood the question to be something like, Are Tor operators more likely to be eavesdroppers than regular IP-layer router operators, layer 2 snoopers, spyware authors, and other meanies? Maybe I misunderstood. My point was that it's easier to run a tor exit node than do any of the above. That makes it more likely to happen. There are so many opportunities for eavesdropping, and they are so often taken (on small and global scales), that worrying about Tor operators is relatively minor -- especially since if you really want security, you're already using end-to-end encryption anyway. It's moot. I don't think the law is much consolation for someone who wants to remain anonymous! Again, I'm not saying -- I never even sort of said -- that people who want anonymity should pin their hopes on Tor operators knowing and observing US law. Sorry, I was being a smartarse. -- KlamAV - An Anti-Virus Manager for KDE - http://www.klamav.net TorK - A Tor Controller For KDE - http://tork.sf.net
Info: Eepsite that chains I2P and Tor
Hi,I thought someone might be interested in an Eepsite that routes traffic as so:Broswer I2P Privoxy Tor InternetHere is the post about this Eepsite: http://forum.i2p.net/viewtopic.php?t=1548Please note I'm not endorsing this Eepsite or the chaining of Tor at all. I havn't used this and I don't plan to as I think it is unnecessary and can reduce anonymity (like Jap Tor Interent). Besides the fact browsing must slow to a crawl.Another issue is that the Eepsite seems to be using Privoxy as MITM. I would however suggest this to filter data from I2P:Broswer Privoxy I2P Privoxy Tor InterentAnogeorgeo __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
