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
Re: following on from today's discussion
A simple example of modifying traffic: http://www.schneier.com/blog/archives/2006/08/stealing_free_w.html http://www.ex-parrot.com/~pete/upside-down-ternet.html Could be easily applied to Tor exit point too. However, sniffing is not a problem if you are visiting only public webistes (do not exchange any personal information), But traffic injection could be. Remember Penet remailer? They were accused to help distribute child pornography. It was not true, and it was proved so later. But Penet admin decided to shut down the service anyway because of public preasure. I am a little worried, that someone will try to destroy Tor network by sniffing, injecting, downloading child pornography/hacking through Tor and doing other nasty things... I was thinking about a solution to prevent traffic injection in non-encrypted public websites. What about having TWO conection open and do some kind of checking if the content is the same (maybe access the content from two different locations and do some MD5 check). I know the idea is hard to implement, since website can serve different content for each location or every second, and this could also mean double load of Tor network. But maybe someone will develop my idea into the usable form... If not, feel free to drop it away. bye, Matej
Re: following on from today's discussion
On Fri, Aug 18, 2006 at 07:19:58PM -0500, Mike Perry wrote: I'd like to also add that it is possible for rogue Tor servers to go beyond simply evesdropping on traffic. On one occasion I recieved a corrupt .exe file via Tor.. It appeared to be just noise, but it woke me up to the possibility that it is quite feasible that Tor exit nodes can do all sorts of things to traffic: modifiying .exes, injecting browser/media format exploits, etc etc. Correct. Woe is the day when a malicious Tor exit node also has a stolen or purchased copy of a trusted CA's key. But you're right, chaos can be had without even that extreme. This is why Tor's packages (and other security packages) come with gpg signatures. The Internet can be a scary place. And Tor users need to be even more aware of this fact than ordinary Internet users. Part of what we need to do is educate the world about all the security issues with being an ordinary user on the Internet. (I don't think Tor introduces any new attacks -- after all, here I am using my open wireless to get to my shared cablemodem in my apartment in Cambridge, and I'd better be aware of all sorts of possible attacks -- but it does change which attacks you can expect to encounter.) The next thing we need to do is continue to work on interfaces and usability for end-user applications like Firefox. What does that lock mean really? If I do (or don't) see the lock, what should I trust? How can we make use of the plethora of anti-phishing schemes currently under research? And lastly, there's the issue of advocacy for authentication, integrity, and confidentiality on the Internet in general. Translation: we need to get everybody using SSL for everything. Since the Tor client scrubbs logs, it can be difficult to tell which exit server was in fact responsible, especially if they only target a small percentage of connections. It might be nice if Vidalia had an option to retain some connection history in-memory only for a period of time on the order of 10s of minutes for the purposes of monitoring for malicious/censored exit nodes. Might be that Blossom is useful for you here (with a few tweaks). Or see http://archives.seul.org/or/talk/Jul-2006/msg00040.html for more general options. It's tricky to automate this idea and make it usable because you'd also have to remember which application connection was involved, since several different exit nodes can be active at the same time, for example if they have different exit policies. And that's not something that is simple to do and still be as safe. --Roger
Re: following on from today's discussion
Thus spake Roger Dingledine ([EMAIL PROTECTED]): Correct. Woe is the day when a malicious Tor exit node also has a stolen or purchased copy of a trusted CA's key. Eeep. The next thing we need to do is continue to work on interfaces and usability for end-user applications like Firefox. What does that lock mean really? If I do (or don't) see the lock, what should I trust? How can we make use of the plethora of anti-phishing schemes currently under research? And lastly, there's the issue of advocacy for authentication, integrity, and confidentiality on the Internet in general. Translation: we need to get everybody using SSL for everything. Time for a nice tinfoil-amplified SSL rant.. Is anyone in the world actively watching and tracking SSL certs beyond simply verifying CA key signatures? By looking at teh OCSP RFC (http://rfc.sunsite.dk/rfc/rfc2560.html) it appears as if you are hard pressed to tell if a cert is a dup or not: 'The good state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval.' I mean good goddess. So even if you are watching for revokations, you are only handling half of the SSL threat model... Some form of ssh-like fingerprint tracking really needs to be coupled with CRL-style checks so that you only accept a different cert than normal for citibank.com if a revocation has been actually issued by them. Especially when we have over 100 root certs spanning multiple countries trusted by most browsers now. To add insult to injury, the only public OCSP server I can find seems completely broken. Everything comes back with 'unknown' with bad timestamps. Yes, even their demo key. http://www.openvalidation.org/en/info/openssl.html This client seems to be somehow issuing correct queries to verisign's OCSP according to ethereal (even though it is configured to use openvalidation.org), but the UI reports the same 'unknown' status as 'openssl ocsp' did: http://www.openvalidation.org/ValWorks.html Madness. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Re: following on from today's discussion
Thus spake Matej Kovacic ([EMAIL PROTECTED]): I was thinking about a solution to prevent traffic injection in non-encrypted public websites. What about having TWO conection open and do some kind of checking if the content is the same (maybe access the content from two different locations and do some MD5 check). I know the idea is hard to implement, since website can serve different content for each location or every second, and this could also mean double load of Tor network. But maybe someone will develop my idea into the usable form... If not, feel free to drop it away. So what about a stochastic solution instead: 1. Create some listing of exe files, commonly vulnerable doc formats, and SSL sites that changes periodically, possibly scraped off google 2. Use some perl glue to go through the Tor node list and try each exit to make sure they aren't modifying this data. a. Certs can be checked byte by byte to make sure they don't differ across exit nodes. b. Images, doc files, ppt files, exes can be verified by multiple sources A handful of hosts could run this thing and publish their results, perhaps along with some other manually created list of undesirable exits. I think this is doable with perl, the Tor control port, wget, md5sum, tsocks and 'openssl s_client', and is a lot more efficient than having everyone verify everything always. The testing can be periodic, can manually associate streams with connections so exits are known, etc. If I'm not distracted by something shiny in the next couple days I'll give it a shot. I mean, we've got to get these motherfuckin snakes off this motherfuckin plane. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Re: following on from today's discussion
On Friday 18 August 2006 22:47, Roger Dingledine wrote: [Dropping the or-dev CC since this isn't related to Tor development] On Fri, Aug 18, 2006 at 10:14:29PM +0100, Robert Hogan wrote: That aside, I think it has highlighted a security risk that Tor itself may be guilty of understating to new users, namely that using Tor exposes your traffic to a much higher likelihood of being eavesdropped than normal. For example, I am not a network admin by day so I do not have access to public internet traffic through legal means. Yet I am running a Tor exit server, so I can now legally (though unethically) listen to your internet traffic and harvest any passwords that go by. Actually, look at http://tor.eff.org/eff/tor-legal-faq.html.en#ExitSnooping It is an open legal question -- that is, there's no clear precedent with respect to Tor servers -- but it's probably not wise to just assume that it's legal. Also, remember that there are many jurisdictions out there, and they all have their own complex laws. I do not think the gravity of this trade-off by the tor user (security for anonymity) is adequately represented. I agree. Somebody should write a clear introduction to Tor, what it does, and what it doesn't do. One day that somebody will be me, but I would welcome some early versions to help me along. Now that I see it for what it is, I am definitely going to introduce some sort of nag/warning to TorK so that the user is warned at least once that using plaintext protocols carrying authentication information on Tor carries a serious health warning. Am I overstating the case? Do others think that the nature of the compromise tor users make is transparent to them? The reason I haven't emphasized the issue so far is that I think you're overstating the protection ordinary users get from the Internet as it is. For example, if you're on a local network with other users (often including everybody in your neighborhood for cablemodem systems), you're not in very good shape. Tor solves this issue, and for many users it's a huge issue. Then there's the question of the Internet infrastructure itself -- your Internet packets travel over a wide variety of places on the way to their destination. Sometimes packets get mis-routed to, well, pretty much anywhere. The chance that any hop along the way is able to observe them -- for example because of a crooked employee, but also because some Russian cracker 0wns a computer nearby in the path -- is hard to estimate in general, but from studying botnets and dealing with net security for the past decade or so, I don't feel it's as low as you imply. All that said, I agree with you that most of the danger is probably at the endpoints of the communication -- on the path from you to your entry Tor node, and on the path from your exit node to your destination. Tor solves the first issue and changes the second issue -- possibly for the worse, depending on your situation. So barring any actual data about the security of the Internet as a whole, which seems hard to get, I still stick with my answer from http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ExitEavesdroppers If you're not using end-to-end encryption, then you're in bad shape, whether you use Tor (and are exposed to one set of risks) or don't use Tor (and are exposed to a different set of risks). --Roger Thank you for that very considered response. Tor definitely does change the qualtitative and quantative risk of being eavesdropped though - and i think it is this fact that is understated. The anonymity provided by tor comes at a price: the increased risk of any-old-joe (and not just the corener cases of a crooked isp employee, or a hacker listening to misrouted packets) harvesting your traffic. The exact degree of this increased risk obviously depends on your view of the risk posed by normal use of the internet, as you have pointed out. My feeling is that anything that extends the circle of risk from exposure to hackers/crooked ISP employees/ISPs themselves to exposure to the likes of me (a curious amateur with no special priveleges) represents a sea-change in the user's security 'posture'. I'm not saying that the shift is catastrophic but it is definitely a compromise that needs more emphasis. -- 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
Thus spake Roger Dingledine ([EMAIL PROTECTED]): It's certainly hard to pin down the exact risks here -- there are clearly huge risks on both sides. Somebody should write up a clear concise explanation, perhaps based on some statements from this thread. :) I'd like to also add that it is possible for rogue Tor servers to go beyond simply evesdropping on traffic. On one occasion I recieved a corrupt .exe file via Tor.. It appeared to be just noise, but it woke me up to the possibility that it is quite feasible that Tor exit nodes can do all sorts of things to traffic: modifiying .exes, injecting browser/media format exploits, etc etc. Since the Tor client scrubbs logs, it can be difficult to tell which exit server was in fact responsible, especially if they only target a small percentage of connections. It might be nice if Vidalia had an option to retain some connection history in-memory only for a period of time on the order of 10s of minutes for the purposes of monitoring for malicious/censored exit nodes. -- Mike Perry Mad Computer Scientist fscked.org evil labs
