Re: concerning tor bug report #1026
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Scott, On Jul 7, 2009, at 8:24 AM, Scott Bennett wrote: I submitted tor bug report #1026 via Jon scr...@nonvocalscream.com , who volunteered to post it to bugs.torproject.org for me because that web site refuses to log me in. (Should I write up a bug report on that, too?) The report has since accumulated two comments, one on Saturday by Karsten Loesing and one on Monday by Roger Dingledine. I address their comments here because I am unable to do so on the web site. I assume by Karsten you mean Sebastian :-) Karsten and Roger, there seems to be some confusion over the way the bug report is listed in its indexed information. I do not know why it is listed as a tor client bug when it clearly should be listed as a tor relay (a.k.a. server) bug (likewise for #996). I cannot account either for the severity and priority rankings for either #1026 or #996. The version in the title of #1026 (0.2.1.15-rc) is the correct version for which the symptoms are being reported, not 0.2.0.35 as shown in the indexed information as the Reported Version. Yes, the bug was reported using different settings than what you have reported, however, I was fully aware that this is a relay bug and that the version is 0.2.1.15-rc. I would like to reiterate that the bug is not a bug in the authority functions of tor, but rather a bug in the relay descriptor-updating functions of tor. Nothing but the date+timestamp was changed in the new descriptor update sent to the authorities, but it was sent much earlier than the normal time for the ~18-hourly update, so the relay *SHOULD NOT* have sent the update in the first place. That is the whole point. This is more curious, and explains how I misread the first version of the bugreport. I see the problem now, see explanation in the bugreport once I get around to updating it. Please feel free to copy the above information into the comments area for bug report #1026. Thank you. Scott Bennett, Comm. ASMELG, CFIAG Thanks for reporting, Sebastian -BEGIN PGP SIGNATURE- iEYEARECAAYFAkpTNtoACgkQCADWu989zuYf1wCePDuA2Yca6NxrQ1NZi5wKRiHj H/cAn0V9jT/GDVCvMITeuqO83wPTsAKz =NwMV -END PGP SIGNATURE-
Re: concerning tor bug report #1026
On Tue, 7 Jul 2009 13:51:53 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Jul 7, 2009, at 8:24 AM, Scott Bennett wrote: I submitted tor bug report #1026 via Jon = scr...@nonvocalscream.com=20 , who volunteered to post it to bugs.torproject.org for me because =20 that web site refuses to log me in. (Should I write up a bug report on that, =20= too?) The report has since accumulated two comments, one on Saturday by =20 Karsten Loesing and one on Monday by Roger Dingledine. I address their =20 comments here because I am unable to do so on the web site. I assume by Karsten you mean Sebastian :-) Yes, I see the mistake now. My apologies. I was still thinking about the Last edited by field at the top of the report. :-( Karsten and Roger, there seems to be some confusion over the way =20= the bug report is listed in its indexed information. I do not know why =20= it is listed as a tor client bug when it clearly should be listed as a tor relay (a.k.a. server) bug (likewise for #996). I cannot account =20 either for the severity and priority rankings for either #1026 or #996. The version in the title of #1026 (0.2.1.15-rc) is the correct version for which the symptoms are being reported, not 0.2.0.35 as shown in the indexed information as the Reported Version. Yes, the bug was reported using different settings than what you have =20= reported, however, I was fully aware that this is a relay bug and that =20= the version is 0.2.1.15-rc. Okay. From Roger's comment, I wasn't sure. In any case, it is *not* an old report. This happened late last week, Thursday, IIRC. I would like to reiterate that the bug is not a bug in the =20 authority functions of tor, but rather a bug in the relay descriptor-updating functions of tor. Nothing but the date+timestamp was changed in the =20= new descriptor update sent to the authorities, but it was sent much =20 earlier than the normal time for the ~18-hourly update, so the relay *SHOULD =20= NOT* have sent the update in the first place. That is the whole point. This is more curious, and explains how I misread the first version of =20= the bugreport. I see the problem now, see explanation in the bugreport =20= once I get around to updating it. Yes, I see your comment. However, if the decision is to go with making the relay (not client) recognize that the authorities didn't take the update, then the ~18-hour timer should *not* be changed from its setting before the failed attempt to update. 18 hours from the previous publication time will be soon enough, at least in this situation, right? I am approaching the conclusion that there may be quite a few ways in which relays may be incorrectly dropped from the consensus and that it may take a while to pin each of them down. :-) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: concerning tor bug report #1026
On Jul 7, 2009, at 5:55 PM, Scott Bennett wrote: [snip] But *which* descriptor? The last successful one? Or the one that failed? They generate a new one, based on their current config options. BTW, thank you for looking at this so quickly. This one indeed is much less urgent than the one Nick already fixed for me, but it's good to know that it is being investigated. Sure. I have written a fix and handed it to Nick for review. Scott Bennett, Comm. ASMELG, CFIAG Best Sebastian
Re: concerning tor bug report #1026
On Tue, 7 Jul 2009 18:10:00 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Jul 7, 2009, at 5:55 PM, Scott Bennett wrote: [snip] But *which* descriptor? The last successful one? Or the one that failed? They generate a new one, based on their current config options. I think you snipped just a bit too much above. You wrote that the relay needs to recognize when its descriptor is about to expire. I asked which descriptor [is about to expire]? So your reply above is nonsensical. (Surely, a brand-new descriptor is not just about to expire?) The new descriptor is generated to replace some earlier descriptor, namely, either the descriptor that was already in effect at the time of the failed update or else the descriptor that failed the update. So which one's timer is used to ascertain that a descriptor is about to expire? I argue that, in the event of an update failure, the expiration time of the descriptor already on file at the authorities should be used to determine when a new descriptor should be sent to the authorities, not the expiration time that would have applied to the failed descriptor had it succeeded. BTW, thank you for looking at this so quickly. This one indeed is much less urgent than the one Nick already fixed for me, but it's good to know that it is being investigated. Sure. I have written a fix and handed it to Nick for review. Okay. I hope it works. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Question: Hidden Services, Virtual Machines, and iptables
Hey Tor users, My work to write a how-to manual for setting up and securing hidden services is well underway, but I've got a question that's been getting at me. Obviously, hidden services are the 'most secure' when they're run inside a virtual machine (qemu, vmware, etc. pick your poison). One could certainly run Tor inside the vm and then have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. We would only want the vm accessing the web IF it was going through Tor, but we wouldn't want to just route all vm traffic through the host's Tor client because then you could be running Tor... over Tor. One solution would be to create an iptables blacklist (on the host) and then ban connections to any computers which *aren't* Tor servers. This seems like it might be a little work to implement and an adversary could always set up a Tor server if they could hack your hidden service and remotely execute code (or cause your web server to fetch external content). Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious. You've only got one layer of encryption and any serious exploits found in Tor could be used against the host machine, revealing the true IP address of the hidden service. Also, if somebody were forced to reveal the encryption key to the hard drive, the game would be up as opposed to running a vm from a deniably-encrypted truecrypt drive that was mounted remotely via ssh. Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? Also, anybody with hidden service security tips (particularly on implementing a LAMP server) is welcome to contact me off-list for obvious reasons. My PGP key is pasted below. Thanks, Ringo -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEniUKIRBADfn8kULsRd3si+zPnVbeVp4C/cjxfOxvPURPjRMDPRZPuDuEI5 QIiMP+lZs0Y1BS/zubrwJ/R+knZW0dfkCbd0IBqhtcci4ZiDXRCNxxYow0MysweG sbZE0QY4T2u40ffOLs9m/ENiDebUxknTyAg8/Jim9aBdEDgurCc7HCX+iwCghfLh 1POMWQRkXB4zUmXQfp+u+0MD/j5SUN6ct6fH4ex3L/WeIHRA+PZXBEpQv5HCwcYO 9VAtS0KYTtrBePXuhabjmiyhWIVsPHa8A+5RW3ONkK4gQ71E7sh2nu44p0rOSVkz 9/ZQiHVCjxZJNhvCsabIFT2/G8OFo2XPnJ0+8Gfluueb5a/HKArUWHIvkws82kQ5 75RJBACJp436/Bvk/CpKDkIG8v/4dQkyNKhv5AEAbx3jNjdOAxNSK0tBaQAulgCk GFNkk+wpv6OWaawgQzFh71KvmEswSLObXk+S6WZgC+Epy4XmfzzDG/gIHD0VuBQ+ 2D8JzFT/TiDMu6wdYu4kgDg5sO4a5Yzn7xoYMF5YWzXnPKhXi7QacmluZ28gPHJp bmdvQGhhY2tibG9jLm9yZz6IZgQTEQIAJgUCSeJQogIbIwUJAeEzgAYLCQgHAwIE FQIIAwQWAgMBAh4BAheAAAoJEFUc7QiIWsvrdtkAn3KtPdxxC/qWmmIFZ4Nc4cFE as42AJoDwdk/N9I3sPvc91wTTlbsKhoHLrkEDQRJ4lCiEBAAs2JYGr1k1Dgi3DMy h0ziX+22tIWWyIJoGKWKFspA7nGeniOBodLBvR+POtqqGCh+bkm9I0X/YMF9oVcP xXBql7H6E4JSgtCk7xtohDpLlfcCpsddVxcJdXYLynTUMcmJtCER0bCNIkTmYoV7 uNXAqmUNAp4zaI70yWsidpAVHme0+sBUYNinfBdlcaMddzslbDtRV7yGKgvW3E5e hPNTJ0pWF6WJg4VsEOFoP7pldtQ4YWScskvuCk957K4t4Of3QZs13Nn9sQZleFJU E2L1bxEHuSqY/f1F/pbKmc7in8qkoBBAyhUbzCNxxELdof3uJpBy0pw0468GvSyb Z4jyh2XFvxFFAcelzc453y9GOylIC0OQczkrzOa6QrIWQSmeCzn/byjLoi+TRFve usRmJn5H9MJg+k+mG5LJM2mcyQJU2UOPDvSurKmk50vByBED6Qn5CvhXJp18H6Uk 2r+PICG4h8aN9KZpSrMAqYggyKgAxHTlCaQzGCwvJGiX6lx6iIm2GLoqeHdRHZZX 9XognVcbTwUWJkL0LR9nhm5U0GhFGM9eRdLw89C/Z/s1/Q/QLjoDh60qXcYo+vFS 5bJtiT52HnlA002opyi+Zn5mk9aXQiksOJruIdNw1rvJSe+uAIYQeBv+rinxzAyL 4f/p/+vvgnfgkEc2G1hLuGTvWMsAAwYP+gIhIgQ6UwQ0Bu1gyRN88Gs9H0fnQ74Z RmFXDgUtpn1YrFzFfTNegQh8vvgo1pXV4ZDPc0w9Cs8QHrspnkYrvSymAEmwYtGd nvnAVVROIJfN5d140Z1FJXCgFp/3m2SAX1omYyN3/5WX9ef1uaYWub48kSdqfHlr xe8Z15nXQ9E6WMgDtP5jXpfCkAnweW6/WSGRrHlRyBUevCTyRSZ4dwtim0GHsls9 VbfDYWJVxiKWdgjtjg+PfsXrdQG2KICEHXprS9/tYCheWaHP4couXVHDPUNMGK/w HSYXbr0/xA0i0JHpRzVCDweKZ32hgbYkTXp0U7ArBYLtbfpWlB8uWHFFAIS5yJQL YMwc8/qFCgl5fUGMk4ZLTgbftQo/sfcOAIPQl2nVjhnvzucj8PgBBaJgH9ORTpW6 89zIzOtfXfju0dq4LC6Xj4h6SA/duh8dEiBzewNJ1FwnlrywvaQjsVdx5+5RolAk gZKcT4hHCj+s2vCAyF5R70rfKkZkKhMuUzEWc4R4AzbkmI1eTtEl/FJVCzBsJRan HC+YMgCdf2ujTxvBltytpWrs0nvzFVY6+RyihQsqlV6KeOtDBTv38a8Q5gdARK0j 5og+X3SWHW0p29PSKk6a3NeSB08J0wlXsrNOJ/JXlYw/yIifZdgl6fO8V7rPBoQt xIQB5UKSXj8YiE8EGBECAA8FAkniUKICGwwFCQHhM4AACgkQVRztCIhay+vXkQCf beWbtPmJOWbXn+9LEaJTqcN73REAn2MmtesdDs24QjWfZeTfc8dyEZ2n =O0oE -END PGP PUBLIC KEY BLOCK-
unsubscribe or-talk
[OT] RE:unsubscribe or-talk
The unsubscribe instructions are in the headers of the list emails: you have to send to a different address Date: Tue, 7 Jul 2009 23:58:49 -0500 Subject: unsubscribe or-talk From: nervcomm...@gmail.com To: or-talk@freehaven.net _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009
Re: Question: Hidden Services, Virtual Machines, and iptables
On Tue, Jul 7, 2009 at 6:10 PM, Ringo2600den...@gmail.com wrote: ... One could.. run Tor inside the vm and have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. ... Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? in such a configuration i prefer to use two virtual machines. one vm has host-only networking to serve hidden service content. second vm hosts Tor router with hidden service pointed at vm host. host uses iptables redirect and/or tcp proxy to connect hidden service connections from Tor VM to hidden service VM port at host-only endpoint. (there are variations on this theme...) best regards,
Re: Question: Hidden Services, Virtual Machines, and iptables
That's a good solution, but it sounds like it would take lots of memory/cpu, especially if you're running both of these VMs from an encrypted partition. If a serious exploit was found in Tor (or implemented in Tor), it would still be able to break out of the main VM, but at least it still wouldn't have a real IP address. I still feel like there's got to be a simpler way to do this. Ringo coderman wrote: On Tue, Jul 7, 2009 at 6:10 PM, Ringo2600den...@gmail.com wrote: ... One could.. run Tor inside the vm and have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. ... Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? in such a configuration i prefer to use two virtual machines. one vm has host-only networking to serve hidden service content. second vm hosts Tor router with hidden service pointed at vm host. host uses iptables redirect and/or tcp proxy to connect hidden service connections from Tor VM to hidden service VM port at host-only endpoint. (there are variations on this theme...) best regards,
Running a Tor Server as a Tax Deduction?
Hey, I was thinking about how to get more companies/organizations to run Tor servers and then it hit me that maybe the expenses associated with doing so could be taken as a tax exemption. It's hard to convince a company to run a Tor server, but if it's in their financial interest, you might have a little more leveragee. Do people think that running a Tor server could be seen as a donation to the Tor Project (which is a 501(c)(3) charity IIRC)? Or is this kind of like deducting mojitos as business drinks? Obviously I'm not looking for advice from a CPA/accountant (although that would be great), just wondering based on people's personal knowledge of tax law. If people think it's worth looking into (or maybe possible), I'd be happy to hire a CPA/tax expert and talk with them about it. I just thought I'd ask here before throwing my money away ; ) Ringo
