Re: Bug: improperly bound listen addresses?
On Tue, 5 Aug 2008 15:07:27 -0400 grarpamp <[EMAIL PROTECTED]> wrote: Yes. And it should have the facility to bind to whatever address I tell it to use for that purpose. Not the primary address on any given interface, the '*' address, etc. Tor already has facilities for its OR and DIR 'listeners' and the 'outboundbindaddress'. It needs one one for DNS resolution as well. I don't want it using .1 for that. Create a -dnssrcport and -dnsbindaddress. -dnssrcport should allow >=1024 for non-root and anything for root, particularly 53. > >>> On 8/1/08, Scott Bennett <[EMAIL PROTECTED]> wrote: >>>Perhaps you would explain to us why you wish to be able to use >>>secured ports as client ports rather than server ports. Your example, >>>port 53, is the port to which named binds. The routines in resolv.conf, ^^^ Sigh. I see that once again I've written garbage while fading in and out due to lack of sleep. That should have said, "libresolv" (i.e., the resolver library), of course. >>>of course, use whatever port the kernel assigns to them because they >>>are client routines, not the DNS server routines. It's not at all >>>clear what you have in mind. > >>Ahh, yes. Ok, Tor is not likely to be a named anytime soon :) I'll >>fire up a named, bind it as desired and point Tor at it. > > >Hi :) Finished testing... > >It is still necessary for Tor to have a -dnsclientaddress option. > >If I point resolv.conf to 127.0.0.1, Tor binds as follows: >tor tor 736139 udp4 127.0.0.1:2884 127.0.0.1:53 >tor tor 735529 udp4 127.0.0.1:2884 127.0.0.1:53 > >This is perfectly fine. > >If I point resolv.conf to w.x.y.z on the internet Tor binds as >follows: > >tor tor 73613 10 udp4 10.0.0.1:2885 w.x.y.z:53 >tor tor 73552 10 udp4 10.0.0.1:2885 w.x.y.z:53 If you have named running, then putting 127.0.0.1 into resolv.conf as a server should cause all queries to go to your named. It should only be necessary to specify a remote name server as a backup in case your named crashes or becomes otherwise unresponsive. > >This is not desirable. Because as before, I'm trying to move all >of Tor's activities off of my primary interface address [10.0.0.1] >and onto the secondary [10.0.0.2]. I've been able to use the following >to move everything but this DNS binding to the secondary [10.0.0.2]: > >-orlistenaddress 10.0.0.2 >-dirlistenaddress 10.0.0.2 >-address 10.0.0.2 <-- workaround for bug: Tor not making note > internally of the above two options and failing to run. >-outboundbindaddress 10.0.0.2 > I think you're barking up the wrong tree here. I don't know of any way to tell the resolver routines to bind only to a particular network interface for sending their queries. If you really need to do that, you need to have the source for the resolver library, so you can build it with your own modifications. AFAIK, tor uses the resolver library, so adding a command line/torrc option like you're asking for would have no effect. 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: questions about MinUptimeHidServDirectoryV2 in 0.2.1.2-alpha
On Tue, 05 Aug 2008 15:01:06 +0200 Karsten Loesing <[EMAIL PROTECTED]> wrote: >| The tor man page says, >| >| "MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks >| Minimum uptime of a v2 hidden service directory to be accepted >| as such by authoritative directories. (Default: 24 hours)" >| >| My questions are, what is the justification for the default of 24 >hours? And >| why have this particular option at all? Why not instead have a "no longer >| fresh/up to date" indicator somewhere, much like the fresh-until line for >| consensus/status documents, so that a server that beomes disconnected >or goes >| down for only a brief time will remain available to provide hidden service >| directory service as much of the time as possible? Or, better yet, >why not >| simply handle this issue the same way that it is handled for normal >directory >| (mirror) service? > >The default of 24 hours ensures that hidden service directories are >available for the next few hours with a certain probability. The idea is >that there are hundreds of hidden service directories at some point >which are not authoritative any more, but provide a more scalable and >robust storage than the three authoritative ones can. Hidden services >and clients need to have a view as consistent as possible of which >hidden service directories are out there, so that clients can find >previously stored hidden service descriptors. The 24 hours have turned How is that different from the situation of normal directory mirrors? >out to be a characteristic that allows distinguishing highly available >relays from others. The rationale behind it is that a certain number of >relay operators turn their relays off over night. The following diagram In other words, it is already covered by the "Guard" and "Stable" flags from the authorities, right? >shows the variation of relays with different minimum uptimes over an >interval of 2+ months. You can see the difference between minimum >uptimes of 16 hours and lower and those of 20 hours and higher. That is >the reason for the default of 24 hours. > >http://freehaven.net/~karsten/dirnodesminuptime.pdf It's very pretty, but, given the legend, which I assume denotes uptimes in hours, the axis labels are not helpful. What exactly do "Directory Size" and "Time Index" refer to? > >The option MinUptimeHidServDirectoryV2 is mainly there to perform tests >with the distributed hidden service directory without having to wait for >24 hours. It is not required to set it in the public Tor network. (It >only has an effect on directory authorities anyway.) I understand that, though it is also useful for the operators of the current authorities should the policy change. What I still don't see is the need for a 24-hour delay before a server stops being only potentially useful and becomes actually useful. Earlier today the HSDir count was down to only *4*. How is it thus helpful to keep other servers from being available for use? > >I should probably make the design paper of the distributed hidden >service directory available rather soon. It answers questions like yours. > >Hope that helps! Not particularly at present, but I'll revisit your graph after I find out what your labels mean. 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 * **
Incognito 2008.1-r1 out (was: Incognito LiveCD 2008.1 released)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, Due to bad (read: non-existent) QA procedure there was a minor issue in the QEMU script for Windows which broke it in QEMU 0.9.1. Therefore I've released a revision fixing this. More details: http://anonymityanywhere.com/incognito/ Sorry for the inconvenience. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiY55wACgkQp8EswdDmSVgWMwCfVPa0q9XQlvgXceb1rsxHi4uU BMMAnRWtUz3Fpk2gUfFZ2rzVVWQw6J3/ =kYKU -END PGP SIGNATURE-
Re: Bug: improperly bound listen addresses?
>>>Yes. And it should have the facility to bind to whatever address I >>>tell it to use for that purpose. Not the primary address on any >>>given interface, the '*' address, etc. Tor already has facilities >>>for its OR and DIR 'listeners' and the 'outboundbindaddress'. It >>>needs one one for DNS resolution as well. I don't want it using .1 >>>for that. Create a -dnssrcport and -dnsbindaddress. -dnssrcport >>>should allow >=1024 for non-root and anything for root, particularly >>>53. >> On 8/1/08, Scott Bennett <[EMAIL PROTECTED]> wrote: >>Perhaps you would explain to us why you wish to be able to use >>secured ports as client ports rather than server ports. Your example, >>port 53, is the port to which named binds. The routines in resolv.conf, >>of course, use whatever port the kernel assigns to them because they >>are client routines, not the DNS server routines. It's not at all >>clear what you have in mind. >Ahh, yes. Ok, Tor is not likely to be a named anytime soon :) I'll >fire up a named, bind it as desired and point Tor at it. Hi :) Finished testing... It is still necessary for Tor to have a -dnsclientaddress option. If I point resolv.conf to 127.0.0.1, Tor binds as follows: tor tor 736139 udp4 127.0.0.1:2884 127.0.0.1:53 tor tor 735529 udp4 127.0.0.1:2884 127.0.0.1:53 This is perfectly fine. If I point resolv.conf to w.x.y.z on the internet Tor binds as follows: tor tor 73613 10 udp4 10.0.0.1:2885 w.x.y.z:53 tor tor 73552 10 udp4 10.0.0.1:2885 w.x.y.z:53 This is not desirable. Because as before, I'm trying to move all of Tor's activities off of my primary interface address [10.0.0.1] and onto the secondary [10.0.0.2]. I've been able to use the following to move everything but this DNS binding to the secondary [10.0.0.2]: -orlistenaddress 10.0.0.2 -dirlistenaddress 10.0.0.2 -address 10.0.0.2 <-- workaround for bug: Tor not making note internally of the above two options and failing to run. -outboundbindaddress 10.0.0.2 Thanks.
Abuse statistics
Hi, I extended my statistics a bit: http://ob44yuhbyysk5xft.onion Now you can also see, how many connections are used to search for profiles via an email-address. The detection is done by the following regular expression: /GET .*se?a?rch.*=[^%& ]+%40[^%& ]+/ No data beside the host name is saved, especially not the email addresses. It shows that at the moment between 4 and 20 % of the connections are used for these requests, mainly at flickr, what explains their high ranking in the general connections. It can be assumed that most of searches are done automatically by profilers, that scan "web 2.0" sites for existing profiles with their email-address-databases, in order to build up a relation database. (Examples: http://www.rapleaf.com/ , http://www.spock.com/, http://www.peekyou.com/) By using unencrypted connections over Tor they violate their privacy policies, I guess. Also it shows how interesting it is for email-address harvesters to run an exit node on their own. Each 100'000 connections you will have collected at least 5'000 email addresses! So the profilers feed the spammers? :-)
Re: questions about MinUptimeHidServDirectoryV2 in 0.2.1.2-alpha
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | The tor man page says, | | "MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks | Minimum uptime of a v2 hidden service directory to be accepted | as such by authoritative directories. (Default: 24 hours)" | | My questions are, what is the justification for the default of 24 hours? And | why have this particular option at all? Why not instead have a "no longer | fresh/up to date" indicator somewhere, much like the fresh-until line for | consensus/status documents, so that a server that beomes disconnected or goes | down for only a brief time will remain available to provide hidden service | directory service as much of the time as possible? Or, better yet, why not | simply handle this issue the same way that it is handled for normal directory | (mirror) service? The default of 24 hours ensures that hidden service directories are available for the next few hours with a certain probability. The idea is that there are hundreds of hidden service directories at some point which are not authoritative any more, but provide a more scalable and robust storage than the three authoritative ones can. Hidden services and clients need to have a view as consistent as possible of which hidden service directories are out there, so that clients can find previously stored hidden service descriptors. The 24 hours have turned out to be a characteristic that allows distinguishing highly available relays from others. The rationale behind it is that a certain number of relay operators turn their relays off over night. The following diagram shows the variation of relays with different minimum uptimes over an interval of 2+ months. You can see the difference between minimum uptimes of 16 hours and lower and those of 20 hours and higher. That is the reason for the default of 24 hours. http://freehaven.net/~karsten/dirnodesminuptime.pdf The option MinUptimeHidServDirectoryV2 is mainly there to perform tests with the distributed hidden service directory without having to wait for 24 hours. It is not required to set it in the public Tor network. (It only has an effect on directory authorities anyway.) I should probably make the design paper of the distributed hidden service directory available rather soon. It answers questions like yours. Hope that helps! - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImE8S0M+WPffBEmURAseDAJ9zbmc9Fr0u1NDSdfBZCMf3IHxAnwCghAYp ioWjbih5vuaFVbydCthSGu0= =BusG -END PGP SIGNATURE-
questions about MinUptimeHidServDirectoryV2 in 0.2.1.2-alpha
The tor man page says, "MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks Minimum uptime of a v2 hidden service directory to be accepted as such by authoritative directories. (Default: 24 hours)" My questions are, what is the justification for the default of 24 hours? And why have this particular option at all? Why not instead have a "no longer fresh/up to date" indicator somewhere, much like the fresh-until line for consensus/status documents, so that a server that beomes disconnected or goes down for only a brief time will remain available to provide hidden service directory service as much of the time as possible? Or, better yet, why not simply handle this issue the same way that it is handled for normal directory (mirror) service? 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: SIGHUP without effect
Hans seems to have trimmed the following from the beginning of Karsten's message, so I'll address that part here. On Mon, 04 Aug 2008 10:35:00 +0200 Karsten Loesing <[EMAIL PROTECTED]> wrote: >this might indeed be a bug, or at least a behavior that should be >changed. However, some more information about it would be helpful in >finding out what exactly is wrong. > >The first thing is a description of what needs to be done in order to >reproduce the problem. Is it just setting up a relay and, well, waiting? AFAIK, yes. However, see Hans's suggestion that using SIGHUP may somehow result in the problem happening later on. >If so, how long does one have to wait? Can you provide your torrc files? At least eighteen hours. :-) Beyond that, I see no pattern so far. >Could you reproduce the behavior yourself after you experienced it the >first time? What was the first Tor version that had this problem, and No, I do not know how to cause it to happen. >can you confirm that previous versions didn't have it? I've never seen it happen before now (0.2.1.2-alpha). 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: SIGHUP without effect
Hmmm...I see Hans has already followed up to Karsten, so I'll respond by following up to Hans's message. On Tue, 5 Aug 2008 10:47:43 +0200 Hans Schnehl <[EMAIL PROTECTED]> wrote: >On Mon, Aug 04, 2008 at 10:35:00AM +0200, Karsten Loesing wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > > > >Hi > >As this was started on this list, I continue here for now. > > >[snip] >> At some time, preferably when we have more information about what's >> going on, someone should open a flyspray task for this bug. or-talk is >> not the best place to discuss bugs. :) Bugs are both reported and discussed on or-talk all the time. That's one of the more useful things about the list, IMO, and helps serve as an early warning system. >> >> | On Thu, Jul 24, 2008 at 06:53:36AM -0500, Scott Bennett wrote: >> |> I'm running 0.2.1.2-alpha and have noticed a recurring problem. It >> |> appears that tor is sometimes not uploading a new descriptor on schedule. >> >> How did you figure that out? Could you paste the log statements? I first noticed that traffic had dropped to only a few, occasional packets per second (not even every second). I then checked the most recent consensus and status documents and found that MYCROFTsOtherChild was missing from them. What log statements did you have in mind? Perhaps something like "Oops! I forgot to upload an updated descriptor, so I'm going into hiding"? It forgot to do it, so it had nothing to log. That was the next thing I checked. If left unmolested, tor normally uploads a new descriptor to the authorities about every eighteen hours, but if it forgets to do that, then that's pretty much the death knell of its usefulness until it has been restarted. Giving it a SIGHUP at this point does not then cause a new descriptor to be uploaded, apparently regardless of ExitPolicy changes. >> >> |> Once this happens, it appears that it will *never* upload a descriptor >> |> update on its own, though it can be tricked into doing so by making some >> |> significant change in torrc, then giving it a SIGHUP. I've been trying >> |> to keep an eye on it and forcing it to update when the authorities stop >> |> listing it in the consensus documents by commenting/uncommenting an >> |> ExitPolicy line and giving it SIGHUP. >> >> The explanation might be that the authorities don't store router >> descriptors when changes are considered cosmetic. However, after 12 >> hours time difference between storing two descriptors, changes should >> never be considered cosmetic, regardless of how subtle they are. >> I suppose, but I thought there was a provision also for an update if a considerable increase in bandwidth usage over the previously reported value had happened. >> >> Hans Schnehl wrote: >> | Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what >> | it is supposed to. >> >> Okay, so what is SIGHUP supposed to do here? From the manpage: >> >> "SIGHUP The signal instructs Tor to reload its configuration (including >> closing and reopening logs), fetch a new directory, and kill and restart >> its helper processes if applicable." >> >> I might be wrong, but as far as I understand this, sending a HUP signal >> does not necessarily include uploading a new descriptor that is then >> accepted by the authorities. Why should this happen if the currently >> stored descriptor is fine? > >By rereading a modified torrc, this signal causes tor also to upload >these modifications to the authorities. >What I tried to achieve is getting closer to the servers upper limits >in bandwidth/performance, therefore publishing descriptors with different >bandwidths, sometimes within relatively short times. What I did not know >is the authorities' not accepting so called 'cosmetic' changes within a >certain timeframe. This is perfectly logic and makes sense, explains >most my observations, though not all. And that, I confess, is something I have sometimes done as well. I do not know whether that activity is at all correlated with tor's occasional forgetfulness. > >> | Trying to publish new descriptors (bandwidth) lead to quite unexpected >> | results. The authorities (cached-consensus) simply stopped listing the >> | node and cached-descriptors(.new) were not updated any more. >> | This though did not have an immediate effect as there were enough >> machines >> | using the node because of the previously downloaded descriptors and >> | consensus. It simply died away slowly when more and more machines >> 'forgot' >> | the node to exist. >> | Some 12 hours later Tor had to be restartet when it was finally running >> | on some 30% of its previous capacity, but then uploading the new >> | descriptors then accepted (or recognized) correctly by the authorities. >> >> Well, this behavior is not intended. It would be quite interesting to >> figure out when this situation occurs. Please provide more information >> (as stated at the top of this mail). > >Unfortun
Re: SIGHUP without effect
On Mon, Aug 04, 2008 at 10:35:00AM +0200, Karsten Loesing wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 Hi As this was started on this list, I continue here for now. [snip] > At some time, preferably when we have more information about what's > going on, someone should open a flyspray task for this bug. or-talk is > not the best place to discuss bugs. :) > > | On Thu, Jul 24, 2008 at 06:53:36AM -0500, Scott Bennett wrote: > |> I'm running 0.2.1.2-alpha and have noticed a recurring problem. It > |> appears that tor is sometimes not uploading a new descriptor on schedule. > > How did you figure that out? Could you paste the log statements? > > |> Once this happens, it appears that it will *never* upload a descriptor > |> update on its own, though it can be tricked into doing so by making some > |> significant change in torrc, then giving it a SIGHUP. I've been trying > |> to keep an eye on it and forcing it to update when the authorities stop > |> listing it in the consensus documents by commenting/uncommenting an > |> ExitPolicy line and giving it SIGHUP. > > The explanation might be that the authorities don't store router > descriptors when changes are considered cosmetic. However, after 12 > hours time difference between storing two descriptors, changes should > never be considered cosmetic, regardless of how subtle they are. > > > Hans Schnehl wrote: > | Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what > | it is supposed to. > > Okay, so what is SIGHUP supposed to do here? From the manpage: > > "SIGHUP The signal instructs Tor to reload its configuration (including > closing and reopening logs), fetch a new directory, and kill and restart > its helper processes if applicable." > > I might be wrong, but as far as I understand this, sending a HUP signal > does not necessarily include uploading a new descriptor that is then > accepted by the authorities. Why should this happen if the currently > stored descriptor is fine? By rereading a modified torrc, this signal causes tor also to upload these modifications to the authorities. What I tried to achieve is getting closer to the servers upper limits in bandwidth/performance, therefore publishing descriptors with different bandwidths, sometimes within relatively short times. What I did not know is the authorities' not accepting so called 'cosmetic' changes within a certain timeframe. This is perfectly logic and makes sense, explains most my observations, though not all. > | Trying to publish new descriptors (bandwidth) lead to quite unexpected > | results. The authorities (cached-consensus) simply stopped listing the > | node and cached-descriptors(.new) were not updated any more. > | This though did not have an immediate effect as there were enough > machines > | using the node because of the previously downloaded descriptors and > | consensus. It simply died away slowly when more and more machines > 'forgot' > | the node to exist. > | Some 12 hours later Tor had to be restartet when it was finally running > | on some 30% of its previous capacity, but then uploading the new > | descriptors then accepted (or recognized) correctly by the authorities. > > Well, this behavior is not intended. It would be quite interesting to > figure out when this situation occurs. Please provide more information > (as stated at the top of this mail). Unfortunately there isn't even a log of the incident, nor did it happen again, but that may be due to not using SIGHUP that often anymore now. I did not (want to) try to reproduce the latter behaviour again yet, so presently there is nothing 'solid' to be filed. As soon as there are recurrences or any other noticable events I will try to deliver more appropriate information in the right place. Regards Hans
