Re: Privoxy doesn't start on booting
James Brown wrote: OS - Ubuntu 9.10 on a laptop Privoxy version 3.0.13 Tor version 0.2.1.26 I have installed tor and privoxy and now I have the next problem. When I boot my system privoxy does not start as daemon and I need to start it manually (/etc/init.d/privoxy start). I have files with privoxy skripts in my /etc/rc1.d - /etc/rc5.d (named K20privoxy), I can see through sysv-rc-conf that it must start on 1 level but it doesn't. I am not sure how startd (what Ubuntu uses for process 1) might interact with this, but on traditional SysV systems, the services you want to run in a particular runlevel should start with "S" (for start) rather than than "K" (for kill = stop). Jim *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: A few questions and potential answers:
On Mon, Sep 20, 2010 at 03:22:57AM -0500, David Bennett wrote: > Q: What is to stop operatives working for the bad guys from running > tor proxies from 3rd party locations? Granted, they would only be able > to sample a portion of the traffic, but traffic that they did sample > could lead to identification of users. Tor uses a distributed trust model, where any single relay doesn't get to learn both the user and her destination. So yes, a bad guy can run a relay, but the sample of network traffic he sees from that relay is not useful to him. He needs to own multiple relays, and get lucky enough to own the user's first hop and also her last hop. The math is a lot better in that case, though still not perfect -- for c out of n proxies run by the bad guy, the chance he wins is (c/n)^2 rather than c/n. See http://freehaven.net/anonbib/#onion-routing:pet2000 > It doesn't seem like it would > be that hard to match up the encrypted client side requests with the > un-encrypted outgoing requests. Correct, it isn't hard. > PA: The only solution I can think of here is centralized control of > the proxy network provided by a press/media sponsorship model as > opposed to the bandwidth volunteer model. It's to easy for bad guys to > infiltrate the volunteer network. If you're talking about a one-hop network (that is, a network where users route through one proxy and then to their destination), then yes, I think centralized control is a slightly better idea. But I think one-hop proxies are a horrible idea for anonymity, whether centralized or not. Aside from the "does the proxy want to learn about my browsing habits" question, you need to wonder about whether the network itself (e.g. the proxy's upstream) wants to track things. See also Section 5 of https://www.torproject.org/press/presskit/2010-09-16-circumvention-features.pdf > It would also be easier to swap in > and out new proxies as they are blocked. runtime selection of > alternative proxy networks would be a nice feature. It sounds like you're thinking of Tor as a network of one-hop proxies. Tor is more modular than that -- in a nutshell, the core Tor protocol is a protocol to build secure routes through a set of relays, and it doesn't care where it learns the relays. > Q: I have noticed lists like: http://proxy.org/tor.shtml that appears > to be a list of tor proxies. What's to stop the bad guys from blocking > the entire proxy database? My understanding is that countries like > Iran have the national ISP market under their thumb. You might like https://svn.torproject.org/svn/projects/design-paper/blocking.html and https://www.torproject.org/bridges > PA: There needs to be a way to deal out proxies to clients without the > ability to easily reveal the entire network to anyone. Perhaps even > semi-static assignments similar to DHCP. Of course, there is also the > problem of 'blocking the dealer' similar to the P2P security issues > with trackers. Ultimately, to really make this fool proof, there would > need to be a way to communicate proxy dealers offline (verbally / > off-network) in a concealable way. That's one approach. I think there other viable approaches too. > Q: How can we address bad guys blocking port 443. This actually does happen, e.g. to some people we know in a certain north African country. > PA: Proxies should be able to hide behind other services such as > 25,80,110. As Justin mentioned, Tor relays (including bridges) can listen on whatever ports they want. > Also nice would be a 'spoof greeting' feature that would > simulate a 'normal' service for that port before a magic code was > sent. Of course, the magic code would need to be changeable (possibly > dynamically by a proxy dealer). See item #10 on https://www.torproject.org/volunteer.html.en#OtherCoding which leads to http://dl.dropbox.com/u/37735/index.html which needs more work. :) > Q: What about DPI which can provide encryption protocol info to the > bad guys (if not the payload). The best known answer is to try to look enough like some other common protocol that you mostly blend in. Trying to look like SSL is the clear best choice at this point. > PA: plug-in packet obfuscation, possibly agreed upon between proxy and > dealer and embedded in a magic code given by the dealer to the client > then provided back to the proxy in the request header. This could be > implemented by means of a tiny secure VM that ran small byte-code > obfuscator programs shared between proxy and dealer and referenced by > the magic code. Even though the bad guys could run the VM > de-obfuscator, it would be challenging to implement at OSI levels 1-4 > given current technology. Sounds like a fine open problem. You should investigate it and show us that it can actually be done, and actually will make it harder to notice this traffic. Historically, people working on this topic either (at best) find that it's harder than they thought, or (at worst) overlook why it's hard and end up with an a
Re: Privoxy doesn't start on booting
On 2010-09-20 19:39, James Brown wrote: > OS - Ubuntu 9.10 on a laptop > Privoxy version 3.0.13 > Tor version 0.2.1.26 > > I have installed tor and privoxy and now I have the next problem. > When I boot my system privoxy does not start as daemon and I need to > start it manually (/etc/init.d/privoxy start). Who is the owner of '/etc/privoxy/*'? It should be 'privoxy'! 'ls -l /etc/privoxy': -rw-r--r-- 1 privoxy root 2850 2010-09-15 09:37 config -rw-r--r-- 1 privoxy root 71178 2010-01-18 08:09 default.action -rw-r--r-- 1 privoxy root 37843 2010-01-18 08:09 default.filter -rw-r--r-- 1 privoxy root 734 2010-01-18 08:09 match-all.action -rw-r--r-- 1 privoxy root 3697 2010-01-18 08:09 trust -rw-r--r-- 1 privoxy root 3644 2010-09-15 08:13 user.action -rw-r--r-- 1 privoxy root 515 2010-06-13 11:34 user.filter *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Privoxy doesn't start on booting
OS - Ubuntu 9.10 on a laptop Privoxy version 3.0.13 Tor version 0.2.1.26 I have installed tor and privoxy and now I have the next problem. When I boot my system privoxy does not start as daemon and I need to start it manually (/etc/init.d/privoxy start). I have files with privoxy skripts in my /etc/rc1.d - /etc/rc5.d (named K20privoxy), I can see through sysv-rc-conf that it must start on 1 level but it doesn't. How can I fix it?! I have has privoxy+tor on my old laptop under Ubuntu 9.10 and I have them on my several laptops under Debian lenny and Debian testing and I have no such problem only on my that laptop. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The best way to run a hidden service: one or two computers?
On Mon, 20 Sep 2010 09:58:14 -0400 hi...@safe-mail.net wrote: > Robert Ransom: > > > If your web server and all of the interpreters and programs it runs are > > competently written, there is no way for an attacker to get root > > access, or even run a shell command. Web applications and the > > special-purpose interpreters they run on are often incompetently > > written. > > I've noticed that on most Linux distributions, Apache 2 (just an example) > runs as a non-privileged user on the system. Though one Apache 2 process > does run as Root, but it spawns unprivileged process children. So if it > was to be a flaw in Apache 2, or PHP, that an attacker knew about, would he > then be able to gain Root access if the software runs as a non-Root user? Maybe. Most Linux distributions do not put much effort into protecting a system against a malicious user with shell access. Even if you have no local privilege-escalation holes, there are usually scary side-channel attacks (e.g. cache-related leakage of AES keys), and you may have already given the compromised UID permission to send arbitrary network packets (if it can run VirtualBox, for example, the attacker can set up a VM with a bridged network device, log in as root in the VM, and send evil packets at will). Also, if you haven't bothered to change your MAC address, an attacker with any UID can read it using ifconfig; your hardware manufacturers may have kept records of where the device(s) with that MAC address were shipped. > > I select the message I want to reply to, and then I click the âReplyâ > > button in my mail client's toolbar. > > The same as I do. It must be my mail provider that sucks. :) If you have a Linux system with persistent storage, try Claws Mail. If you have a Windows system, gpg4win includes Claws Mail for Windows. (Unfortunately, it leaks its version number, your GTK version number, and its build target (including processor architecture) in an X-Mailer header.) Robert Ransom signature.asc Description: PGP signature
Re: The best way to run a hidden service: one or two computers?
On Fri, Sep 17, 2010 at 10:41 PM, Robert Ransom wrote: > If your hidden service really needs to be annoying to find, run it: > > * using only well-written, secure software, > * in a VM with no access to physical network hardware, > * on a (physical) computer with no non-hidden services of any kind > running on it (so that an attacker can't use Dr. Murdoch's ‘Hot or > Not’ clock-skew detection attack), > * and over a fast enough Internet connection that the adversary cannot > easily determine your connection's speed. I think you've missed some points. * The (Virtual) machine running the hidden service should probably also have no _outbound_ network connectivity except via tor. This is because it can be even easier to trick a software on a server into making a network connection than it is to remotely compromise the server. E.g. your GNU/Linux distribution may have installed some extra CGIs in your webserver that you are unaware of... And here is a potentially controversial suggestion, lets see what others say about it: * You should run your hidden service behind tor bridges rather than directly connecting to the tor network. The rationale for this suggestion is that it may make it more difficult for a network observer to enumerate a list of tor clients in order to apply things like the clock-skew attack or subject them to additional network surveillance. [snip] > The above precautions are probably enough, unless a three-letter agency > (or four-letter association) knows about your hidden service and wants > to find and ‘neutralize’ its operator. In that case, you have to worry > about the near-global passive adversary and other threats that Tor > can't afford to defeat. I fear that you're overstating the security provided. For example, I think that if you managed to piss off the ISP community vigilantes that go after spammers and botnets that they would have a decent chance of tracking you down in spite of your efforts to stay hidden. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The best way to run a hidden service: one or two computers?
Robert Ransom: > If your web server and all of the interpreters and programs it runs are > competently written, there is no way for an attacker to get root > access, or even run a shell command. Web applications and the > special-purpose interpreters they run on are often incompetently > written. I've noticed that on most Linux distributions, Apache 2 (just an example) runs as a non-privileged user on the system. Though one Apache 2 process does run as Root, but it spawns unprivileged process children. So if it was to be a flaw in Apache 2, or PHP, that an attacker knew about, would he then be able to gain Root access if the software runs as a non-Root user? > I select the message I want to reply to, and then I click the âReplyâ > button in my mail client's toolbar. The same as I do. It must be my mail provider that sucks. :) Thanks for all your help BTW! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: A few questions and potential answers:
On 9/20/2010 4:22 AM, David Bennett wrote: Bad Guys == Anyone blocking or monitoring a persons access to knowledge Granted. Q: What is to stop operatives working for the bad guys from running tor proxies from 3rd party locations? Granted, they would only be able to sample a portion of the traffic, but traffic that they did sample could lead to identification of users. It doesn't seem like it would be that hard to match up the encrypted client side requests with the un-encrypted outgoing requests. Perhaps I don't understand what you're going for here. If a user is using https (or another client-server encryption protocol), then a "bad guy" viewing traffic without the onion-layer encryption would simply see more encrypted traffic. Even if the user does not (or cannot) use https-like protocols, because each node does not know where along the circuit it lies, this is no more useful than passively monitoring an exit-node's traffic for information. That said, there are plenty of warnings on the project website about this: tor is not magic, and users need to be careful that any unencrypted traffic does not contain any personally identifiable information. PA: The only solution I can think of here is centralized control of the proxy network provided by a press/media sponsorship model as opposed to the bandwidth volunteer model. It's to easy for bad guys to infiltrate the volunteer network. It would also be easier to swap in and out new proxies as they are blocked. runtime selection of alternative proxy networks would be a nice feature. The volunteer model is exactly what keeps tor afloat: nodes appear and disappear all the time, and traffic to many of them looks innocuous, as if they were connecting to any other computer on the net. See below. Q: I have noticed lists like: http://proxy.org/tor.shtml that appears to be a list of tor proxies. What's to stop the bad guys from blocking the entire proxy database? My understanding is that countries like Iran have the national ISP market under their thumb. There are many bridges that are only distributed on request via https://bridges.torproject.org and via email to brid...@torproject.org. These change dynamically enough to keep most users connected. Where access is blocked, mirrors and relays can be found with a little fenangling about search engines. PA: There needs to be a way to deal out proxies to clients without the ability to easily reveal the entire network to anyone. Perhaps even semi-static assignments similar to DHCP. Of course, there is also the problem of 'blocking the dealer' similar to the P2P security issues with trackers. Ultimately, to really make this fool proof, there would need to be a way to communicate proxy dealers offline (verbally / off-network) in a concealable way. See above. As I understand it, as soon as a client can connect to a single bridge, they can then obtain enough information to build circuits without needing to refer to any central authority. Q: How can we address bad guys blocking port 443. PA: Proxies should be able to hide behind other services such as 25,80,110. Also nice would be a 'spoof greeting' feature that would simulate a 'normal' service for that port before a magic code was sent. Of course, the magic code would need to be changeable (possibly dynamically by a proxy dealer). Tor bridges and exits are in no way limited to port 443. My exits currently use port 9001, with directory mirrors on port 9050; this is the purpose of the orport and dirport lines in the torrc. I'm not qualified to comment on why the rest of your proposal would or would not be a good idea. Q: What about DPI which can provide encryption protocol info to the bad guys (if not the payload). PA: plug-in packet obfuscation, possibly agreed upon between proxy and dealer and embedded in a magic code given by the dealer to the client then provided back to the proxy in the request header. This could be implemented by means of a tiny secure VM that ran small byte-code obfuscator programs shared between proxy and dealer and referenced by the magic code. Even though the bad guys could run the VM de-obfuscator, it would be challenging to implement at OSI levels 1-4 given current technology. The ultimate idea would be to keep the Bad Guys busy chasing their tails and break them through over investment in competence. As they attempt to keep up with the changing methodologies they become victims of their own system of control, meanwhile they have less time to do their normal bad guy stuff. Basically, the circumvention tool itself becomes an agent provocateur. Again, not qualified. I hope someone will provide a better answer to this. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The best way to run a hidden service: one or two computers?
On Sun, 19 Sep 2010 07:11:21 -0400 hi...@safe-mail.net wrote: > Robert Ransom: > > > The VM is optional *if* and *only if* an attacker cannot possibly get > > root on your hidden service. > > How do external attackers get root access on a Linux system, and how do they > then communicate with the system as root, like listing directories and > changing configuration files as you would have done in a shell, when they're > basically limited to a hidden website with the browsers address bar and > maybe a few input forms? It gets more sensible when we're talking about > default and open websites with the server's true IP addresses and ports out > in the public, and exploitation of SSH servers. I'm just curious about that. If your web server and all of the interpreters and programs it runs are competently written, there is no way for an attacker to get root access, or even run a shell command. Web applications and the special-purpose interpreters they run on are often incompetently written. > BTW how do you reply to specific posts? All I'm doing here is replying to > my own original post. Thanks. I select the message I want to reply to, and then I click the “Reply” button in my mail client's toolbar. Robert Ransom signature.asc Description: PGP signature
A few questions and potential answers:
Bad Guys == Anyone blocking or monitoring a persons access to knowledge Q: What is to stop operatives working for the bad guys from running tor proxies from 3rd party locations? Granted, they would only be able to sample a portion of the traffic, but traffic that they did sample could lead to identification of users. It doesn't seem like it would be that hard to match up the encrypted client side requests with the un-encrypted outgoing requests. PA: The only solution I can think of here is centralized control of the proxy network provided by a press/media sponsorship model as opposed to the bandwidth volunteer model. It's to easy for bad guys to infiltrate the volunteer network. It would also be easier to swap in and out new proxies as they are blocked. runtime selection of alternative proxy networks would be a nice feature. Q: I have noticed lists like: http://proxy.org/tor.shtml that appears to be a list of tor proxies. What's to stop the bad guys from blocking the entire proxy database? My understanding is that countries like Iran have the national ISP market under their thumb. PA: There needs to be a way to deal out proxies to clients without the ability to easily reveal the entire network to anyone. Perhaps even semi-static assignments similar to DHCP. Of course, there is also the problem of 'blocking the dealer' similar to the P2P security issues with trackers. Ultimately, to really make this fool proof, there would need to be a way to communicate proxy dealers offline (verbally / off-network) in a concealable way. Q: How can we address bad guys blocking port 443. PA: Proxies should be able to hide behind other services such as 25,80,110. Also nice would be a 'spoof greeting' feature that would simulate a 'normal' service for that port before a magic code was sent. Of course, the magic code would need to be changeable (possibly dynamically by a proxy dealer). Q: What about DPI which can provide encryption protocol info to the bad guys (if not the payload). PA: plug-in packet obfuscation, possibly agreed upon between proxy and dealer and embedded in a magic code given by the dealer to the client then provided back to the proxy in the request header. This could be implemented by means of a tiny secure VM that ran small byte-code obfuscator programs shared between proxy and dealer and referenced by the magic code. Even though the bad guys could run the VM de-obfuscator, it would be challenging to implement at OSI levels 1-4 given current technology. The ultimate idea would be to keep the Bad Guys busy chasing their tails and break them through over investment in competence. As they attempt to keep up with the changing methodologies they become victims of their own system of control, meanwhile they have less time to do their normal bad guy stuff. Basically, the circumvention tool itself becomes an agent provocateur. --dbenn...@bensoft.com *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
