Re: invitation to directory server operators
On Sat, Sep 13, 2008 at 06:18:51AM -0500, Scott Bennett wrote: > On Sat, 13 Sep 2008 12:31:34 +0200 Hans Schnehl <[EMAIL PROTECTED]> > wrote: > >On Sat, Sep 13, 2008 at 04:46:14AM -0500, Scott Bennett wrote: > >> On: Sat, 13 Sep 2008 09:01:34 +0200 Gitano <[EMAIL PROTECTED]> > >> wrote: > >> >Scott Bennett wrote: > >> > > >> >>> This entry doesn't work on my server (Picolo) even though the flag > >> >>> 'Directory (v2)' is set. > >> >> > >> >> Why do you believe it doesn't work? > >> > > >> >My server is not listed as a HSDir server. > >> > > >> >> There is, however, the requirement that your > >> >> server be up for at least 24 hours before the authorities will list a > >> >> new > >> >> HSDir server with the HSDir flag set in the consensus and status > >> >> documents. > >> >> If it hasn't been that long yet, please give it enough time. > >> > > >> >Ok - so a server, getting a new IP every 24 hours (ADSL), will never > >> >become a HSDir server? > >> > > > [...snip...] > >So the idea of running a HSDir server is probably limited to those with more > >permanent > >IPs, unless the 24 hour waiting period for HSDir servers to become active is > >changed to > >something shorter. > > Oh, well. However, I do notice that German HSDir servers outnumber > those of all other countries at present, so *somebody* there is getting > better service. They do either run a rented server or pay a rather expensive price for that. For a private person who wishes to run a Tor-node with higher bandwidth and undisrupted connectivity I assume it to be best to rent a server somewhere. Prices have become quite moderate by now. Last not least this would contribute more bandwidth, nodes and anonymity, and that's what it's all about, isn't it? > >0.5c > > > That must be before adjusting for inflation, right? ;-) In this > country, the U.S. Mint has not produced 0.5c coins since the mid-19th > century or perhaps earlier. Now 1.0c coins are not worth picking up off > the ground, though if you good get 5 or 10 kg of them, you could sell > them for the copper, because the face value has dropped significantly > below the metal value. Reading about precious metals coinage is like > reading something from Anderson's fairy tales nowadays. Numismatic evaluation but back to topic ;)
Re: invitation to directory server operators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, the quoting approach doesn't work here any more, so that I try to address the main questions directly; if I should have overlooked something important, please let me know: One question was why we didn't announce the feature of configuring a node as v2 hidden service directories (HSDir in the folling) earlier: This feature was introduced in one of the alphas of the 0.2.0.x series. Back then I asked some people I knew to configure their node as HSDir to have a number of 3--6 HSDirs as a basis to get it running. Unfortunately, there was a major bug in one of the alphas (I don't recall if it was in the HSDir code or not, but anyway, it's fixed long ago, so no worries). The result was that the one of the more high-bandwidth nodes crashed and the node administrator downgraded to 0.1.2.x. At that time I refrained from asking more people to be beta testers before being more sure that it works more stable. Now that the HSDir code runs for quite some time without making trouble, I would say it is stable; which doesn't rule out the possibility of bugs completely, though. It was also on my TODO list to make an announcement, but not on top position, so that Scott got ahead of me with his announcement. It wasn't urgent, though, because the v0 directory is still running in parallel. Scott asked whether enough people turned on this option now: Not if we want the distributed directory be as stable and reliable as it was planned in its design. It is really awesome that so many people followed the announcement here, but we need as many HSDirs as possible. The concept depends on distributing descriptors among hundreds of nodes in the long term. This is required for higher reliability in face of single failing and corrupt nodes. Plus, it even gains more importance for hidden services with client authorization (see proposal 121) where you have separate hidden service descriptors for different clients that should not be linked together. With only a few HSDirs we need to rely on delaying descriptor publication for different descriptors from the same hidden service going to the same HSDir. With hundreds of HSDirs we can make this significantly faster. But this whole thing is not even completely implemented in trunk, so give us some time before announcing it here. (See proposal 121 for more details if you are interested in that.) Andrew found out that it is not required to open the DirPort in addition to setting the HSDir configuration. While this could on the one hand be considered a bug, it shows on the other hand that this requirement is really redundant and can be dropped. Originally, this requirement stems from a time when it was not clear that we can tunnel directory requests over the OR port. This works by extending a circuit to the OR port of a relay and sending a so-called BEGIN_DIR cell that contains a directory request and can be answered directly instead of a command to open a connection to another server or something like that. Then there was a question why nodes need to have an uptime of 24 hours or more: As was discussed earlier on this list, this is a means to ensure high availability of HSDirs. If one looks at the number of nodes over time and removes nodes with lower uptime than 24 hours, one gets a very smooth graph with low variations. Unfortunately this excludes people on daily disconnected DSL lines. Sorry for that, but if we want a reliable distributed hidden service directory, we really need reliable nodes that don't change their IP address. Hidden service clients shall be able to find a hidden service descriptor even when it was published a few hours ago. Finally, there were some questions about legal issues when configuring a relay as hidden service directory. I can't answer those, sorry. Please consult your lawyer, or turn off this option. We will add a remark in the sample torrc (and maybe other places) that this option can be turned off when 0.2.1.x goes stable (at the latest). - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIy6W70M+WPffBEmURAn6nAKDLAeBjtuGEFeE4erWE1Ce8CLYPPQCgl/km Adgs1qh0en59PyJ/caR1d8E= =Oz3x -END PGP SIGNATURE-
Re: invitation to directory server operators
On Sat, 13 Sep 2008 12:31:34 +0200 Hans Schnehl <[EMAIL PROTECTED]> wrote: >On Sat, Sep 13, 2008 at 04:46:14AM -0500, Scott Bennett wrote: >> On: Sat, 13 Sep 2008 09:01:34 +0200 Gitano <[EMAIL PROTECTED]> >> wrote: >> >Scott Bennett wrote: >> > >> >>> This entry doesn't work on my server (Picolo) even though the flag >> >>> 'Directory (v2)' is set. >> >> >> >> Why do you believe it doesn't work? >> > >> >My server is not listed as a HSDir server. >> > >> >> There is, however, the requirement that your >> >> server be up for at least 24 hours before the authorities will list a new >> >> HSDir server with the HSDir flag set in the consensus and status >> >> documents. >> >> If it hasn't been that long yet, please give it enough time. >> > >> >Ok - so a server, getting a new IP every 24 hours (ADSL), will never >> >become a HSDir server? >> > > >[...snip...] > >> they forced a disconnection of the PPPoE session *at least* every 24 hours, >> usually assigning a different IP address. That meant any login sessions I >> had open to other locations got broken without notification to either end, >> and all open tor connections got broken without warning or notification to >> either end (i.e., all TCP connections to anywhere else) > >[...snip}... > >Just for clarification for Germans: Isps of various countries, even in Europe, > >do _NOT_ force a 24 hour dis/reconnect with dialup adsl lines. >Even if the line is disconnected, they _may_ just give away the same IP that >was used before to the same machine. They do not have to, but in practice they >often do. (see below) And some clarification for non-gringos: in the U.S. the ADSL connections are not dialup, but rather continuous connections usually provided directly or indirectly by the telephone company monopolizing the local geographical area. Cable connections are also supposed to be continuous here. The only normal reason for outages is supposed to be hardware trouble. The catches are 1) that some ISPs, like the lousy one I used to pay (TBC Net, Inc. -- tbc.net), buy large packages of ADSL service from another provider, which may be the telephone company or it may be yet another service repackager, and then they turn around and sell the service for individual lines at a cheaper rate than the underlying physical service provider, and 2) any level of this setup that requires authentication can use whatever method it chooses. My old ISP chose to use PPPoE session authentication logs as some sort of input to its accounting system, and the accounting system needed a record for every day or some such nonsense, so they forced new accounting data to be logged at least every 24 hours by cancelling the PPPoE session and requiring reauthentication upon reconnection. Basically, it was one of those setups designed by amateurs, maybe junior high school kids similar to the way Microsoft appears to handle software design. > >>Also, it appears that >>even when the signal is lost or erratic enough to cause the modem to reset >>itself and then reconnect, it seems to get the same IP address every time, so >^^^ >>there may be a pause of 60 - 75 seconds or so, but then everything seems to >>resume with few, if any, broken connections. > >> If you can find an ISP that doesn't force a disconnection and >> reconnection >> every day, life will be much less unpleasant. > >For Non-Germans: >In Germany and some neighboring states it's standard of isp's providing adsl >dialups to >disconnect _every_ line after 24 hours and reconnect with giving away a new IP. >AFAIK there is no exeption to the rule with dialup lines. Sounds awful. Is there a cable-based ISP there? You might have better results that way. Sorry to hear, as well, that the ADSL lines are dial-up connections. Bummer. > >So the idea of running a HSDir server is probably limited to those with more >permanent >IPs, unless the 24 hour waiting period for HSDir servers to become active is >changed to >something shorter. Oh, well. However, I do notice that German HSDir servers outnumber those of all other countries at present, so *somebody* there is getting better service. > >0.5c > That must be before adjusting for inflation, right? ;-) In this country, the U.S. Mint has not produced 0.5c coins since the mid-19th century or perhaps earlier. Now 1.0c coins are not worth picking up off the ground, though if you good get 5 or 10 kg of them, you could sell them for the copper, because the face value has dropped significantly below the metal value. Reading about precious metals coinage is like reading something from Anderson's fairy tales nowadays. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * *--
Re: invitation to directory server operators
On Sat, Sep 13, 2008 at 04:46:14AM -0500, Scott Bennett wrote: > On: Sat, 13 Sep 2008 09:01:34 +0200 Gitano <[EMAIL PROTECTED]> > wrote: > >Scott Bennett wrote: > > > >>> This entry doesn't work on my server (Picolo) even though the flag > >>> 'Directory (v2)' is set. > >> > >> Why do you believe it doesn't work? > > > >My server is not listed as a HSDir server. > > > >> There is, however, the requirement that your > >> server be up for at least 24 hours before the authorities will list a new > >> HSDir server with the HSDir flag set in the consensus and status documents. > >> If it hasn't been that long yet, please give it enough time. > > > >Ok - so a server, getting a new IP every 24 hours (ADSL), will never > >become a HSDir server? > > [...snip...] > they forced a disconnection of the PPPoE session *at least* every 24 hours, > usually assigning a different IP address. That meant any login sessions I > had open to other locations got broken without notification to either end, > and all open tor connections got broken without warning or notification to > either end (i.e., all TCP connections to anywhere else) [...snip}... Just for clarification for Germans: Isps of various countries, even in Europe, do _NOT_ force a 24 hour dis/reconnect with dialup adsl lines. Even if the line is disconnected, they _may_ just give away the same IP that was used before to the same machine. They do not have to, but in practice they often do. (see below) >Also, it appears that >even when the signal is lost or erratic enough to cause the modem to reset >itself and then reconnect, it seems to get the same IP address every time, so ^^^ >there may be a pause of 60 - 75 seconds or so, but then everything seems to >resume with few, if any, broken connections. > If you can find an ISP that doesn't force a disconnection and > reconnection > every day, life will be much less unpleasant. For Non-Germans: In Germany and some neighboring states it's standard of isp's providing adsl dialups to disconnect _every_ line after 24 hours and reconnect with giving away a new IP. AFAIK there is no exeption to the rule with dialup lines. So the idea of running a HSDir server is probably limited to those with more permanent IPs, unless the 24 hour waiting period for HSDir servers to become active is changed to something shorter. 0.5c Regards Hans
Re: invitation to directory server operators
On: Sat, 13 Sep 2008 09:01:34 +0200 Gitano <[EMAIL PROTECTED]> wrote: >Scott Bennett wrote: > >>> This entry doesn't work on my server (Picolo) even though the flag >>> 'Directory (v2)' is set. >> >> Why do you believe it doesn't work? > >My server is not listed as a HSDir server. > >> There is, however, the requirement that your >> server be up for at least 24 hours before the authorities will list a new >> HSDir server with the HSDir flag set in the consensus and status documents. >> If it hasn't been that long yet, please give it enough time. > >Ok - so a server, getting a new IP every 24 hours (ADSL), will never >become a HSDir server? > Probably not. And even if it did, it would have to be something requiring exactly the right timing. And then it would all go to waste a short time later when your system got disconnected and readdressed again. It is now nearly a month since I dumped an ISP that had proven to be nearly unusable by mid April. But the first complaint that I had was that they forced a disconnection of the PPPoE session *at least* every 24 hours, usually assigning a different IP address. That meant any login sessions I had open to other locations got broken without notification to either end, and all open tor connections got broken without warning or notification to either end (i.e., all TCP connections to anywhere else). The ISP's employees insisted that that was by deliberate design and intent, a totally intolerable approach to customer service. Unfortunately, I had signed a one-year contract without having been informed that there would be one or more outages each and every day of that contract. The new ISP is cheaper for the first six months, then somewhat more expensive than the old ISP. But, although there appear to be a few lingering signal quality issues that cause trouble only very infrequently, the stress and irritation of bad service is mostly gone. The new ISP also is giving me higher data rates than I had before, which is great. Also, it appears that even when the signal is lost or erratic enough to cause the modem to reset itself and then reconnect, it seems to get the same IP address every time, so there may be a pause of 60 - 75 seconds or so, but then everything seems to resume with few, if any, broken connections. If you can find an ISP that doesn't force a disconnection and reconnection every day, life will be much less unpleasant. 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: invitation to directory server operators
Scott Bennett wrote: >> This entry doesn't work on my server (Picolo) even though the flag >> 'Directory (v2)' is set. > > Why do you believe it doesn't work? My server is not listed as a HSDir server. > There is, however, the requirement that your > server be up for at least 24 hours before the authorities will list a new > HSDir server with the HSDir flag set in the consensus and status documents. > If it hasn't been that long yet, please give it enough time. Ok - so a server, getting a new IP every 24 hours (ADSL), will never become a HSDir server?
Re: invitation to directory server operators
On Sat, 13 Sep 2008 07:39:39 +0200 Gitano <[EMAIL PROTECTED]> wrote: >Scott Bennett wrote: > >> ## The following line enables hidden service directory mirroring. >> HidServDirectoryV2 1 >> >> (Or skip the comment line, and just add the second line, as you please.) >> Then tell your tor server to reload its torrc file. Within 24 - 25 hours >> your server will begin operating as a tor hidden services directory server. >> You probably won't even notice the difference in traffic loads on your tor >> server. > >This entry doesn't work on my server (Picolo) even though the flag >'Directory (v2)' is set. Are there any dependencies, for example minimum Why do you believe it doesn't work? >bandwidth? > Not that I am aware of. There is, however, the requirement that your server be up for at least 24 hours before the authorities will list a new HSDir server with the HSDir flag set in the consensus and status documents. If it hasn't been that long yet, please give it enough time. 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: invitation to directory server operators
Scott Bennett wrote: > ## The following line enables hidden service directory mirroring. > HidServDirectoryV2 1 > > (Or skip the comment line, and just add the second line, as you please.) > Then tell your tor server to reload its torrc file. Within 24 - 25 hours > your server will begin operating as a tor hidden services directory server. > You probably won't even notice the difference in traffic loads on your tor > server. This entry doesn't work on my server (Picolo) even though the flag 'Directory (v2)' is set. Are there any dependencies, for example minimum bandwidth?
Re: invitation to directory server operators
On Fri, Sep 12, 2008 at 11:39:48PM -0500, Scott Bennett wrote: > A note to Karsten Loesing: what to do you think about the response > so far? Is it enough yet to get you to call off your dogs for a while > on that proposal until we see how many more directory server operators > will volunteer to offer hidden service directory services? We are already > well above the six-server danger zone. I think you're confused about the role of defaults, Scott. Anything that we want to have enabled throughout most of the network should be on by default. We should assume that the vast majority of people who run relays don't follow or-talk. The reason "hsdir" hadn't been on by defauly yet was because we were still (slowly) working on stability and edge cases like the one Andrew produced. Now that it's on by default, I expect to see the numbers slowly climbing, especially first among the folks who update from svn nightly. I should also clarify that the hsdir flag is only for Karsten's v2 hidden service design (see e.g. proposal 114). All hidden services still publish the old v0 way too, and all clients still fetch the old v0 way too. On a much more theoretical note, this "choose a good default" discussion reminds me of Section 4 of http://freehaven.net/anonbib/#usability:weis2006 --Roger
Re: invitation to directory server operators
I just checked the tortatus page, and it now lists 31 hidden service directory servers or 2.55% of all currently listed tor servers! That's more than double the number listed at the time I first posted a call for additional participation as HSDir-enabled directory servers. We still need another 80 - 90 HSDir servers to hit the target I [rather arbitrarily] suggested the other night, but we are definitely off to a good start. A note to Karsten Loesing: what to do you think about the response so far? Is it enough yet to get you to call off your dogs for a while on that proposal until we see how many more directory server operators will volunteer to offer hidden service directory services? We are already well above the six-server danger zone. 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: invitation to directory server operators
Am 12.09.2008 um 17:50 schrieb John Brooks: Also, if this is enabled by default, it will still only be respected if you are already serving the normal tor directory - in countries with laws restrictive enough to prevent mirroring the hidden service directory, it seems that you'd have issues with the standard directory as well, not to mention actual tor traffic. I think the legal risks of the hidden service directory are minimal beside the risks of normal tor traffic, so I doubt it'd be a problem for many node operators (and if it were, they could disable this option again). I don't agree. Normal Tor directories list _routers_, HS directories list _servers_ and therefore _content_ in most cases. And I don't have a good feeling with mixing these two things. To make a graphic example: I don't have a bad conscience if somebody anonymously accesses child pornography sites over my tor node, which is accessible anyways. The site can still be tracked down and removed by the local authorities. And as a node operator I even have the possibility to block such sites with according exit policies if I like to. With HS there is a new service space created. And therefore more responsibility. With running a Tor node supporting HS I also make arbitrary services available, which otherwise might not exist. I really like the idea of HS in general, and there are some great applications for it. But on the other hand there are services which I can not accept to support (to create) with my resources. Accordingly, it would be much more cleaner to separate HS as much as possible from Tor and to see it as an application _on_top_ of Tor. So I don't like the idea to make every Tor node a HS node by default. They are two different things. To promote hidden services by foisting them to all Tor node operators is not fair, I think, and can even become dangerous for the Tor project. They should be promoted separately. As a Tor node operator in the case of HS I'm much more in the need for fine grained access policies due to the higher responsibility. As I wrote in a mail before, at the moment the opposite is true. I can control access of general exit node traffic in exit policies. But I have no control if and for what HS my node becomes an entry point. Similar is true for the HS directory, which I can only switch on or off in general. If for example the public in Germany will find out, that there are HS for sharing child pornography and nobody can do something about it, the whole Tor project and especially the HS directories and entry points (but the public will not be able to discriminate) will get under heavy fire here (don't know how sensitive this issue is in other countries). If Tor will support the blocking of certain HS for node operators at that moment, the attack might be a bit milder and can be "rerouted" to the HS to some extent. Regards, Sven -- http://sven.anderson.de"Believe those who are seeking the truth. tel:+49-551-9969285 Doubt those who find it." mobile: +49-179-4939223 (André Gide)
Re: invitation to directory server operators
On Fri, Sep 12, 2008 at 4:02 AM, Scott Bennett <[EMAIL PROTECTED]> wrote: > Oh. Part of my reason for the call to service for people already > running directory servers was to *avoid* the need for such a change. Not > all countries' laws and jurisprudences adhere to the "common carrier" concept, > as you know. I'd much rather take care of the fragility problem through > voluntary contributions than to slide it with little fanfare into the defaults > for DirPort operations. > You might better invest time in making the information about hidden > service directory service and how to enable it more prominent in the tor > documentation. I don't believe the common carrier concept applies to hidden services at all, or at least less than traditional tor does. Consider - all hidden service traffic is encrypted for its entire path through the network. The *only* people capable of decrypting this traffic are the client and the service, which means anyone in between (such as your server) is entirely in the dark. Serving the directory is similar - you are mirroring the published services, not endorsing them, hosting them, or looking into their content in any way. There is nothing in place that would allow you to moderate the content of hidden services via the directory, so it would be unreasonable for that to be expected. Given that it is an entirely automated process mirroring descriptors published by other parts of the network (which you have no direct relationship with), and that you have no feasible way of moderating the content, I think even a country without common carrier laws would find this to be not problematic. Also, if this is enabled by default, it will still only be respected if you are already serving the normal tor directory - in countries with laws restrictive enough to prevent mirroring the hidden service directory, it seems that you'd have issues with the standard directory as well, not to mention actual tor traffic. I think the legal risks of the hidden service directory are minimal beside the risks of normal tor traffic, so I doubt it'd be a problem for many node operators (and if it were, they could disable this option again). But, i'm not a lawyer, and certainly not a lawyer in any foreign countries, so this is all just my assumptions. - John Brooks
Re: invitation to directory server operators
On Thu, 11 Sep 2008 23:11:53 +0200 Lucky Green <[EMAIL PROTECTED]> wrote: >On Thu, Sep 11, 2008 at 08:17:53AM -0500, Scott Bennett wrote: >> Anyway, for those directory server operators who are willing to add >> hidden services directory service to their ordinary tor directory server's >> offerings, here's how to do it. Note that your server must be configured >> as a directory server. Just add the following lines to your server's torrc >> file. >> >> ## The following line enables hidden service directory mirroring. >> HidServDirectoryV2 1 > >I too didn't even know the option existed. I must have missed the >announcement in the release notes that we should enable this feature >back when it was added. Anyway, added now. I never saw it either, but it may predate my first dabblings with tor (ca. 0.1.1.13, I think). But I saw this HSDir item on the torstatus page for selecting servers to be listed, so I tried it to see what it would show. A few servers came up, few enough, in fact, that I was a bit startled. Then I looked at their entries in the consensus and status documents, where I saw the HSDir flag on each, which prompted me to look at their descriptors. After a few moments of browsing I saw the "opt hidden-service-dir" line in each one, which I had never spotted in descriptors before. By this point, I was definitely intrigued. After a bit of searching, I think I found the option in the tor man page. But no, I don't remember ever having been aware of it either before going through that little treasure hunt. > >Wonder what other features have been added to Tor that I should enable. > Exactly my thought as well. 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: invitation to directory server operators
On Thu, 11 Sep 2008 22:20:01 +0200 Karsten Loesing <[EMAIL PROTECTED]> wrote: >Scott Bennett wrote: >> There is already a proposal in the works to make hidden services >> directory service the default for directory servers, which would probably >> radically increase the number of HSDir servers, providing a solution to the >> current vulnerability. > >Good that you bring this up, Scott! Most of the proposal you refer to is >implemented, but it takes a while for the code to make it into trunk. One of the reasons I waited as long as I did was to see whether I could find any reason that none of the developers had posted a call for directory server operators to enable it. Eventually, after thinking and exploring for quite a while, I decided that it was probably just an oversight, or perhaps deferred to limbo because the proposal was in progress. But if the developers had posted a long time ago the suggestion that I posted a day or so ago, then there would probably never have been a reason to write the proposal in the first place. It looks to me like time and effort expended unnecessarily that might instead have gone toward something more important. >This one was now assigned a higher priority. :) Oh. Part of my reason for the call to service for people already running directory servers was to *avoid* the need for such a change. Not all countries' laws and jurisprudences adhere to the "common carrier" concept, as you know. I'd much rather take care of the fragility problem through voluntary contributions than to slide it with little fanfare into the defaults for DirPort operations. You might better invest time in making the information about hidden service directory service and how to enable it more prominent in the tor documentation. > >The new default value for storing and serving v2 hidden service >descriptors is now implemented in trunk and will be part of 0.2.1.6-alpha. I really wish you would just cancel that. I think the response in only the first day since my message has been great, and it looks like changing the default is very quickly becoming superfluous. Because it also represents a possible danger to server operators who will continue to be unaware of the option, not to mention a change to its default operation, it seems unwise to proceed with the change to the default in the code. Please reconsider. I want to thank everyone who has turned on HSDir service since I posted my message. There are now 17 HSDir servers listed on the torstatus page, so we are off to a good start toward eliminating the hidden service subsystem fragility of too few HSDir servers for safety, and my expectation is that more will continue to appear in the near future. > >This does not, however, mean that it will be backported to 0.2.0.x >anytime soon (or at all). People who run a 0.2.0.x relay still need to Well, that much is good, IMHO. But eventually the stable branch will move beyond that, potentially creating additional risk for some server operators around the world. >set the option manually as described by Scott: > >> ## The following line enables hidden service directory mirroring. >> HidServDirectoryV2 1 Yes, please do, those of you who haven't already. My proposed target currently translates to ~130 HSDir-enabled directory servers, so we need about another 110-115 to get there. If hidden services become more popular, then we might someday need more than one out of every ten tor servers to provide HSDir service for performance reasons. But one out of ten, if well enough distributed around the world, ought to be adequate to eliminate the fragility problem. And as I hinted before, the extra load on my server, even at times when it was one of only 7 running, was trivial. If I hadn't been following an info-level log for other reasons, I never would have been aware that it was doing anything more than it had been before I enabled the HSDir 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: invitation to directory server operators
On Thu, Sep 11, 2008 at 08:17:53AM -0500, Scott Bennett wrote: > Anyway, for those directory server operators who are willing to add > hidden services directory service to their ordinary tor directory server's > offerings, here's how to do it. Note that your server must be configured > as a directory server. Just add the following lines to your server's torrc > file. > > ## The following line enables hidden service directory mirroring. > HidServDirectoryV2 1 I too didn't even know the option existed. I must have missed the announcement in the release notes that we should enable this feature back when it was added. Anyway, added now. Wonder what other features have been added to Tor that I should enable. --Lucky
Re: invitation to directory server operators
I just enabled it on my Tor nodes :)
Re: invitation to directory server operators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Bennett wrote: > There is already a proposal in the works to make hidden services > directory service the default for directory servers, which would probably > radically increase the number of HSDir servers, providing a solution to the > current vulnerability. Good that you bring this up, Scott! Most of the proposal you refer to is implemented, but it takes a while for the code to make it into trunk. This one was now assigned a higher priority. :) The new default value for storing and serving v2 hidden service descriptors is now implemented in trunk and will be part of 0.2.1.6-alpha. This does not, however, mean that it will be backported to 0.2.0.x anytime soon (or at all). People who run a 0.2.0.x relay still need to set the option manually as described by Scott: > ## The following line enables hidden service directory mirroring. > HidServDirectoryV2 1 Thanks! - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIyX1x0M+WPffBEmURAsp8AJ9itADFxjWWjjxrKo3freGZgVEdfgCcDNnx fFT9e6b/XvwmjdwvkAWz/eE= =HpIg -END PGP SIGNATURE-
Re: invitation to directory server operators
Added this to my high bandwidth node - I would've done so far sooner if I had known it wasn't default behavior. I'd say this should be enabled by default or at least get a line in the example torrc so people know it exists. - John Brooks On Thu, Sep 11, 2008 at 7:17 AM, Scott Bennett <[EMAIL PROTECTED]> wrote: > To all tor server operators (except those who run hidden service directory > servers already): > > The torstatus page as of a few minutes ago says that there are > currently > 1292 tor servers, of which 596 are also v2 directory servers (46.13%). If > a > few directory servers comes on line or goes down, it's not likely to make > much > difference to the tor network as a whole. However, only 10 of those > directory > servers are also hidden service directory (HSDir) servers (0.77% of total > tor > servers). Fortunately, the hidden services subsystem traffic is still > relatively low, so the load on hidden service directory servers is also > still > low. > The problem here is one of reliability. In the weeks since I began > paying attention, I have seen the count of hidden service directory servers > range from as high as 13 to as low as 6 or 7. With only these few servers > involved, it would not be too difficult for hidden services to be shut > down, > either by computer or network failures or by an attacker with large > resources. > More people running hidden services directory servers would strengthen the > reliability of the hidden services feature of tor. > For a long time, I was unaware that basic directory servers did not > automatically provide hidden services directories, too, but rather the > hidden > service directory service was an optional service that could be provided at > the directory server operator's discretion. Then it took a short time to > track down the means of activating hidden services directory service, which > turned out to be very easy, of course. > Anyway, for those directory server operators who are willing to add > hidden services directory service to their ordinary tor directory server's > offerings, here's how to do it. Note that your server must be configured > as a directory server. Just add the following lines to your server's torrc > file. > > ## The following line enables hidden service directory mirroring. > HidServDirectoryV2 1 > > (Or skip the comment line, and just add the second line, as you please.) > Then tell your tor server to reload its torrc file. Within 24 - 25 hours > your server will begin operating as a tor hidden services directory server. > You probably won't even notice the difference in traffic loads on your tor > server. > There is already a proposal in the works to make hidden services > directory service the default for directory servers, which would probably > radically increase the number of HSDir servers, providing a solution to the > current vulnerability. Maybe you can help render that change unnecessary, > freeing up some time for the developers to do other things. I propose an > initial goal of raising that (frequently fluctuating) 0.77% to around 10%. > How about it, folks? > > > 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: invitation to directory server operators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a work-around for the default AccountingMax behavior, which is to disable dirport advertising? I have AccountingMax enabled so I know exactly how much tor bandwidth I'm donating per day, but it would be nice if there was a way to put limits on OR and Dir separately, so I could serve both until bandwidth runs out. I think the ideal situation would be a way to both set hard limits, or relative limits (ie, 90% OR/10% Dir or 9GB OR/1GB Dir). ~Andrew Scott Bennett wrote: | | file. | | ## The following line enables hidden service directory mirroring. | HidServDirectoryV2 1 | | (Or skip the comment line, and just add the second line, as you please.) | Then tell your tor server to reload its torrc file. Within 24 - 25 hours | your server will begin operating as a tor hidden services directory server. | You probably won't even notice the difference in traffic loads on your tor | server. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIyTh3bmNAhmEANTwRAjOpAJ9pxRftHabCLoTktb/BCGml7LARzACdGNW1 dc53Q/3X+od6ZAg9HMAAifs= =M71O -END PGP SIGNATURE-
invitation to directory server operators
To all tor server operators (except those who run hidden service directory servers already): The torstatus page as of a few minutes ago says that there are currently 1292 tor servers, of which 596 are also v2 directory servers (46.13%). If a few directory servers comes on line or goes down, it's not likely to make much difference to the tor network as a whole. However, only 10 of those directory servers are also hidden service directory (HSDir) servers (0.77% of total tor servers). Fortunately, the hidden services subsystem traffic is still relatively low, so the load on hidden service directory servers is also still low. The problem here is one of reliability. In the weeks since I began paying attention, I have seen the count of hidden service directory servers range from as high as 13 to as low as 6 or 7. With only these few servers involved, it would not be too difficult for hidden services to be shut down, either by computer or network failures or by an attacker with large resources. More people running hidden services directory servers would strengthen the reliability of the hidden services feature of tor. For a long time, I was unaware that basic directory servers did not automatically provide hidden services directories, too, but rather the hidden service directory service was an optional service that could be provided at the directory server operator's discretion. Then it took a short time to track down the means of activating hidden services directory service, which turned out to be very easy, of course. Anyway, for those directory server operators who are willing to add hidden services directory service to their ordinary tor directory server's offerings, here's how to do it. Note that your server must be configured as a directory server. Just add the following lines to your server's torrc file. ## The following line enables hidden service directory mirroring. HidServDirectoryV2 1 (Or skip the comment line, and just add the second line, as you please.) Then tell your tor server to reload its torrc file. Within 24 - 25 hours your server will begin operating as a tor hidden services directory server. You probably won't even notice the difference in traffic loads on your tor server. There is already a proposal in the works to make hidden services directory service the default for directory servers, which would probably radically increase the number of HSDir servers, providing a solution to the current vulnerability. Maybe you can help render that change unnecessary, freeing up some time for the developers to do other things. I propose an initial goal of raising that (frequently fluctuating) 0.77% to around 10%. How about it, folks? 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 * **
