April 2011 - tor-relays - lists.torproject.org

Relay behind firewall
by tagnaq 28 Apr '11

28 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, is there a way to properly configure a relay (ORPort reachable) that has full internet access beside outgoing destination port 80 that will properly work? Problems: publishing descriptor to authorities that use that port, clients are not aware of this restriction of a relay and will try to build circuits where $nextrelay uses ORPort 80 -> circuit will fail (currently 28 relays use ORPort 80) I guess one should simply not bother trying to run a relay in such a scenario. Is my assumption correct? thanks, tagnaq ps: FascistFirewall is for clients only -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk25Zg4ACgkQyM26BSNOM7YjMQEAlldmzhXeGbaar0tT0Qvyh3b+ b4cOSdVU3+x1iBPujqcA/0UiLBmGloriq5DJNOqXWQdO9dKIjOxW2zdewiTyNRm/ =sxNK -----END PGP SIGNATURE-----

2 1

DMCA notices in Canada?
by anarcat 26 Apr '11

26 Apr '11

Hi, Have any other tor operator *in Canada* been targeted with DMCA takedown notices? We have received a bunch from our upstream provider and so far have refused legal responsability because (a) we're not in the US and (b) there's nothing to takedown, we're just a transit provider... But now our upstream is threatening us to completely disconnect us if we do not take action within 30 days. We're running a full exit node, so it's likely getting used by people for bittorrent downloads... Ideas? Suggestions? Legal support? United organised legal front? A. -- Imagination is more important than knowledge - Albert Einstein

2 3

Persistent XSS vulnerability in TorStatus
by tagnaq 23 Apr '11

23 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "TorStatus is a website display used to summarize metrics about the Tor Network. It's a precursor to http://metrics.torproject.org. The code repository is at https://svn.torproject.org/svn/torstatus/. Example running sites are http://torstatus.blutmagie.de/ [...]" Note: TorStatus is not a Tor Project product and is not maintained. Vulnerability - ------------- DisplayRouterRow() in index.php prints the contact information string from a server descriptor - defined via 'ContactInfo' in torrc by a node operator - into the HTML page without proper output encoding. This leads to a persistent cross-site scripting vulnerability where every Tor node operator can insert HTML/JavaScript on all vulnerable TorStatus mirrors. The contact information column is only included in the HTML page if the end-user (browsing a TorStatus mirror) adds the contact column via "Advanced Display Options" (column_set.php), the contact column is not included by default. An attacker might set the displayed columns for a victim via CSRF. A simple search in the server descriptors of the last two months did not reveal an obvious exploitation in that time period. The simple search used is not suitable to give a clear answer. [grep -hir ^contact * |egrep -i '(script|src)'] Affected Versions - ----------------- 4.0 3.6.1 3.6 3.5 3.4.2 3.4.1 and probably others Solution - -------- The attached patch was committed to the svn (revision r24666). https://svn.torproject.org/svn/torstatus/ Thanks to Robert, Andrew, Olaf, Damian and Sebastian. -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk2zBb4ACgkQyM26BSNOM7YE8gD9HzwAZ1rfUDM+GLxjFfo0o1R7 A5l2MPddbmPlr+d23oYA/1m8VI3bbG9RXvao453j2Yyqix/iJ01rJbLP63PtWShw =Ay2T -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] high cpu usage, normal ?
by Scott Bennett 20 Apr '11

20 Apr '11

On Tue, 5 Apr 2011 14:56:42 +0200 Gijs Peskens <gpeskens85(a)gmail.com> wrote: >I'm running an exit relay configured to give up to 6,4MB/s on an Athlon64 >3000+ Freebsd box, and I'm seeing cpu usage between 30-60% is this >considered normal ? Any means of getting it down? (except getting a faster For such a high-throughput node on such an old CPU, yes, that is not only normal, but actually quite low CPU usage. >cpu or hardware crypto) I don't remember whether the 3000+ is a K10-type CPU or later. If it is, then make sure you have superpages support enabled in your kernel at boot time. If the 3000+ is pre-K10, then enabling superpages support is as likely to hurt performance as it is to help it, which basically would leave you the option of trying it both ways to see which worked better for you. On a K10 or later style of CPU, running a high-throughput node with superpages enabled should shave 10% to 30% from whatever tor's current usage. IOW, if you're seeing 30% - 60% now, then what you see with superpages enabled would probably fall into the 21% - 54% range. The problem with AMD's pre-K10 CPUs is that the size of the TLB shrinks when 4 MB pages are used, so that instead of having 64 entries for text pages and 64 entries for data/stack pages, there are only two (maybe just one--I don't recall for sure) entries for each. Because tor is a much larger process than would fit into one 4 MB page of each kind, using the 4 MB page size instead of the 4 KB page size is very likely to drastically increase the frequency of full address translations, rather than reducing it as on later CPUs in which the TLB retains the capacity for both page sizes. To enable the use of superpages, your system must be at 7.2-RELEASE or later of FreeBSD. Just add the following to /boot/loader.conf, and then reboot. # enable superpages (4 MB) for large processes vm.pmap.pg_ps_enabled=1 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 * **********************************************************************

1 0

Tor and Viruses
by Porcelain Mouse 17 Apr '11

17 Apr '11

Greetings All, I've been running an exit for about 5 months, but had to stop due to virus abuses. In the last two weeks, my ISP has partially blocked my Internet access twice due to suspected virus infections. I'll spare you the long story, but I was able to get a copy of their "evidence" and I'm fairly certain it was connections made through my Tor relay. 1) How common is it that Tor is abused by viruses? What is the trend? 2) Is this just standard virus-kit material, these days? I guess I was a little surprised. Obviously, this is a great idea for hiding the infection site, so I'm sure it's being done. But still, I've been fighting viruses for quite a while and I don't think I've read a single virus description that mentioned Tor. I'm sure it's happening, but I've never heard a single statistic about it, so I thought I would ask. Also, this type of abuse is *not* mentioned on the Tor wiki's Abuse FAQ under "What should I expect if I run an exit relay?" I read that section carefully and was prepared for most of the things mentioned. Again, I'm not completely shocked. I'm just saying it didn't seem likely, according to the FAQ. It would be nice to know how likely is this kind of abuse, and what is the trend. (And, maybe someone can add the results to the FAQ when we have an answer.) Thanks, PMouse

7 7

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 15 Apr '11

15 Apr '11

On Sat, 02 Apr 2011 20:08:16 -0700 Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >On 03/29/2011 02:10 AM, Scott Bennett wrote: >> On Thu, 10 Mar 2011 10:27:50 -0800 Chris Palmer <chris(a)eff.org> wrote: >>> On 03/10/2011 09:10 AM, mick wrote: >>> >>>> Using Tor to scan the internet is a good way to see how the internet >>>> looks from different perspectives at once, which can be quite valuable." >>>> >>>> Which says to me that you are using Tor to do this research. >>> >>> No, it says to you that using Tor to scan the internet is a good way to >>> see how the internet looks from different perspectives at once, which >>> can be quite valuable. >>> >>>> So which is it? >>> >>> The Observatory work was not done through Tor. >> >> Good. > >I think we need a scan of the SSLiverse through Tor. > >>> >>> However, using Tor to scan the internet is a good way to see how the >>> internet looks from different perspectives at once, which can be quite >>> valuable, so I vociferously defend the idea of doing so. >>> >> Ah. "The ends justify the means." How enlightened. :-( >> > >I don't think Chris is making "The ends justify the means" as his >ethical model. Tor relays with exit policies that allow exiting to *:443 Whether he is or is not using that as his "ethical model", that is indeed the form (see above) of his reasoning for defending the activity in spite of the harmful effects it has upon the tor network. >intend to allow exiting to *:443. You have to go to quite a bit of >effort to become a relay, so I'll trust that this counts as consent for >exiting the Tor network on port 443. I hope we don't disagree about this? Use != abuse. If I run sendmail with it configured to accept mail from outside, that does not mean I agree to receive massmail, malware, or other bad stuff via TCP port 25. Because various idiots with access to the Internet insist upon attempting to abuse my ability to receive mail does not militate against my defending my system from such malicious activity in any way I see fit. Do you suppose, for example, that the operators of the root name servers would hesitate for a minute to filter out packets from any address that were obviously attempting a DoS attack upon their root servers? And would they be wrong to do so? Consider that, in doing so, they would not only be defending their own services, but also the proper functioning of the entire Internet. The same reasoning applies to operators of exit nodes wishing to defend the continued existence of their nodes and thereby defend also the proper functioning of the tor network. > >Now, if your ethical issue surrounds the fact that they then connect to >a computer without asking permission, I'd make the argument that this is >reasonable. Even if I was mistaken in your desire to have me connect to >your system, I believe your placement of a computer system on the public >internet requires handling a little bit of expectation setting. > >What do I mean? I mean to say - if you configure PF to block me, I'm >still burning some amount of CPU time on your machine. Is that an >unethical action on my part? To ask your computer a question and for >your computer to reply (with say, a RST) is a normal part of the >networking protocols. The internet is inherently chatty and some amount >of that chatter is the cost of connecting to the public internet. >Obviously 1,000,000 connections at once isn't polite but is polite >really zero connections? Is one connection really so impolite or unethical? Your analogy is not valid. The activity in question can and does result in termination of services to exit nodes by their ISPs. > >Now - if we assume that it's reasonable to send a single SYN and then >complete the handshake when the policy allows, what is the next >boundary? I'd argue that common HTTPS ports probably run HTTPS software >- to better understand that software, you'll need to negotiate some or >all of that protocol. Is sending a TLS ClientHello a reasonable and >ethical next step? I'd say so. It also seems to make sense that when the >server replies, you might log the ServerHello. You might even log all of >the data that the server intended you to have. Is that impolite or >unethical? Is there something wrong with what has been done by this >point in the protocol? I don't think so. As noted above, the activity under consideration results in the general depletion of exit nodes from the tor network. Therefore it must be thought of as an attack upon the tor network itself. Further, an activity that can be used by one party to cause termination of another, innocent party's Internet connection is an intolerable assault upon the latter party's paid access to the Internet for all purposes, not just to offer additional capacity to the tor network, and upon a private agreement between the latter party and his/her ISP. Defense against such offenses is completely appropriate and in order. The activity in question also is not easily distinguishable from that of a lot of actual malware that scans for open ports to find a way in. Using an efficient packet filter (e.g., pf) is a way to provide a defense at minimal cost. Consider it similar to keeping one's household appropriately armed against intruders. Yes, security costs a bit, but TANSTAAFL, and like insurance, it's cheaper than not being prepared when an attack comes. In the case of using a packet filter to prevent responses to miscreants on a permanent basis, it has the additional benefit of proactively defending all other present or future services offered, while denying said miscreants any information. This is even more the case when the filter is combined with something like FreeBSD's black hole option for incoming packets for closed ports because the sender doesn't get a response even in the first attempt. That means that the delay in adding the sender's IP address to the filter does not allow the sender to receive any information at all in response, even once, except in the case that the sender happens to connect to a port that actually *is* open before the sender's address gets added to the table. > >Now the client will reasonably tear down the connection as described in >the relevant protocols. Is that wrong? I don't think so - the protocols >specifically indicate how systems should signal their intentions. You're >free to tell me to stop connecting and I'm free to connect - that's how >these things generally work. Let's apply that argument to telephones. There is a procedure for making a telephone call that has several steps: dialing, waiting for the switching system to establish a circuit, ringing the phone at the other end (a connection attempt), possibly several times, then either getting an answer or giving up on the connection attempt with no answer or because the response was a busy signal or notification that the number is no longer assigned. If the call is answered, then information may be transmitted in both directions, and eventually the connection is closed (hung up). So there is a protocol for making a phone call. The existence of the protocol can hardly be a justification for abuse. Is it okay to dial phone numbers, either at random or according to some desired pattern, just to find out whether a human answers, a modem answers, or there is no answer, only to disconnect immediately upon an answer or after an error indication or else upon a configured timeout? > >Now - as it happens, the EFF SSL observatory client does not actually >implement the entire set of SSL/TLS protocols - just as some software >does not implement TLS 1.1 or 1.2 - is it somehow wrong to run a client >that isn't completely implemented for all specs that it might encounter? >That seems doubtful. Again, pf's "synproxy" is an appropriate, preconfigured response of the target. It's kind of a simple version of a honeypot. > >Google seems to have this data from crawling the web and simply caching >it as a matter of crawling everything - they get the data from lots of >sources such as other urls, toolbars, etc. Google recently published >the Google Certificate Catalog: >http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-… > >So is Google's method the only ethical way to collect this certificate >data? Or is there no method for collecting this data without users >manually submitting each certificate they encounter by hand? > >Even if we pretend that the EFF or the Google methods weren't to be used >- do you think that the EFF model is actually burning more CPU time on >each system? AFAIK, Google does not use the tor network for its web (or other) crawling activities. For Google's purposes, the tor network would be unusably slow. AFAIK, Google does not use any method that uses someone else's computer(s) to make its connections to a destination. An EFF employee, OTOH, has confessed to doing so on this list. The latter, then, is burning CPU time, as well as network connection throughput capacity, on not just one system, but on routelen + 1 systems for each scanned system times the number of ports scanned on that system. > >Do you accept that there is some amount of CPU time you're going to have >to burn when you connect to the internet as a server? If so, what's the >limit or the edge of reasonable CPU time that a single client may cause >for a public server? Are you asking about reasonable time for service requests from legitimate clients? Or, instead, about reasonable time for ignoring "excommunicated" miscreants? > >In any case, the idea of using Tor for perspective routing is not >particularly new - Geoffrey Goodell's work on the topic is well over >half a decade old at this point. It makes a lot of sense to use Tor as a >perspective-routing system of sorts and there's nothing wrong with that >at all. > The problem has now been identified and publicized. If EFF can find some non-damaging alternative method to gather the information it desires, then more power to it. In the meantime, it should cease any and all activities that can damage the tor network or that can adversely affect innocent parties elsewhere. Ethics do matter. Another point, though irrelevant due to the ethical considerations that we've been discussing so far, is that there is no particular reason to use tor rather than some other proxy to look at the Internet from different locations. Anonymity is not necessary to achieve that end. BTW, I was offended to read a day or two ago that you had been subjected to still more harassment by the federal crime syndicate when returning to the U.S. from points south recently. You certainly have my sympathy over such injustices. The best hope at present is, I think, that the empire will soon bring on its own collapse under the weight of its theft of wealth by inflation when the largest buyers of T-bonds stop buying them. Keep your chin up and your eyes on that day. :-) 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 * **********************************************************************

3 2

Re: [tor-relays] tor-relays Digest, Vol 3, Issue 11
by Gijs Peskens 14 Apr '11

14 Apr '11

My ISP also send me a message about abuse (virusses) ,and after I send them a reply that I'm running a tor node and that if they receive further abuse complaints they should just forward them to my mail for me to handle myself I didn't receive any abuse mail again :) I think my ISP is actually running some IDS with sinkholethinghies (I don't know anything about IDS'es yet, will research into it) and I can access a page with info on my IP wich shows some activity: 2011-04-05 21:56:55,85.223.49.156,29272,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,DE,,1,,,Windows,2000 SP2+, XP SP1+ (seldom 98) 2011-04-05 22:26:35,85.223.49.156,45924,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,US,,1,,,Windows,2000 SP4, XP SP1+ 2011-04-04 21:04:06,85.223.49.156,20507,NL,GET /search?q=0 HTTP/1.1,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .N... 2011-04-05 02:29:02,85.223.49.156,20507,NL,GET /?REMOVED HTTP/1.0,sality,KUKU v5.02c =REMOVED,,30184,Windows,2000 SP4, XP SP1+,,80,www.REMOVED.info,,,,REMOVED,8560,... 2011-04-05 22:02:01,85.223.49.156,20507,NL,GET /search?q=0 HTTP/1.1,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .N... 2011-04-06 01:13:53,85.223.49.156,20507,NL,.,downadup,,,21901,,,,80,,,,,REMOVED,US 2011-04-07 20:08:37,85.223.49.156,20507,NL,GET /tatoshko.biz?data=REMOVED== HTTP/1.0,machbot,MachBot,,10988,Windows,2000 SP4, XP SP1+,,80,853c9e57.biz,,,,87.10... 2011-04-11 16:46:41,85.223.49.156,47015,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,US,,1,,,Linux,2.6 (newer, 2) 2011-04-11 15:31:23,85.223.49.156,20507,NL,GET /search?q=15 HTTP/1.0,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727),,45931,Windows,2000 SP... 2011-04-12 04:08:30,85.223.49.156,44022,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,DE,,1,,,Windows,XP/2000 REMOVED= ip adresses (destination), dns names or things that look like http session specific things. I see one port number (destination) somewhat more (all cases of tcp,sinkhole except 1): 8560 might be a virus/trojan/worm specific port ? Might be a good idea to remove this port from your exit if you get a lot of complaints (and it's not used for anything usefull) The idea of setting up a local smtp out server with spam detection and clamav seems like a very good idea, maybe together with some tarpitting (if possible and easy) it would help a lot of users in need of smtp access and deter spammers (as they would spend hours and hours in tarpits at random when using tor) anyone can provide some good advice on how to set it up properly (I'm running FreeBSD)? Would also be _really_ nice to maybe somehow add some header that says it was send using a tor relay with admin details so my ISP (as I would probably need to set it to relay to their smtp) will not start bitching and moaning about that to me, is it possible ? Yes? How ? ;) What are the dangers of running an IDS myself ? Privacy wise I mean, could it be set up so that it knows about bad stuff hapening and in no way log other stuff ? 2011/4/13 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Tor and Viruses (Porcelain Mouse) > 2. Re: Tor and Viruses (grarpamp) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Apr 2011 20:46:21 -0700 (PDT) > From: Porcelain Mouse <porcelain_mouse(a)q.com> > Subject: [tor-relays] Tor and Viruses > To: Tor-Relays <tor-relays(a)lists.torproject.org> > Message-ID: <alpine.LFD.2.02.1104122018100.5770(a)localhost.localdomain> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > Greetings All, > > I've been running an exit for about 5 months, but had to stop due > to virus abuses. In the last two weeks, my ISP has partially blocked my > Internet access twice due to suspected virus infections. I'll spare you > the long story, but I was able to get a copy of their "evidence" and I'm > fairly certain it was connections made through my Tor relay. > > 1) How common is it that Tor is abused by viruses? What is the trend? > 2) Is this just standard virus-kit material, these days? > > I guess I was a little surprised. Obviously, this is a great idea for > hiding the infection site, so I'm sure it's being done. But still, I've > been fighting viruses for quite a while and I don't think I've read a > single virus description that mentioned Tor. I'm sure it's happening, but > I've never heard a single statistic about it, so I thought I would ask. > > Also, this type of abuse is *not* mentioned on the Tor wiki's Abuse FAQ > under "What should I expect if I run an exit relay?" I read that section > carefully and was prepared for most of the things mentioned. Again, I'm > not completely shocked. I'm just saying it didn't seem likely, according > to the FAQ. It would be nice to know how likely is this kind of abuse, > and what is the trend. (And, maybe someone can add the results to the FAQ > when we have an answer.) > > Thanks, > PMouse > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Apr 2011 03:19:27 -0400 > From: grarpamp <grarpamp(a)gmail.com> > Subject: Re: [tor-relays] Tor and Viruses > To: tor-relays(a)lists.torproject.org > Message-ID: <BANLkTikwPS6JDqKMvaxxWhgq2dUoGELKKA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > my ISP has partially blocked my Internet access twice > > due to suspected virus infections. > > Virus is likely not the right word for things. Anyways... > > There's really no reason an operator cannot run something > like bro-ids.org and sink known bad traffic in real time. Yeah, > sure, everyone will bitch at me. But it is operator fiat, and > they're not sinking specific users, so well within common > carrier exceptions on that aspect. No different than operators > who block 'torrent' ports, smtp, etc. > > Speaking of smtp, one could even redirect that into their > system despam/clamav it and send it on its way. Better > than nothing. Especially for the legit senders. > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 3, Issue 11 > ***************************************** >

2 1

Re: [tor-relays] tor-relays Digest, Vol 3, Issue 9
by Ray Waren 12 Apr '11

12 Apr '11

I have problems connecting to the tor network always stuck at "Authenticating to Tor". I ask for assistance in what I should try to get in touch with tor again. Thank you. 2011/4/11 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: two relays serving same hidden service (prafull moulekhi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Apr 2011 23:59:08 +0530 > From: prafull moulekhi <prafullmoulekhi90(a)gmail.com> > Subject: Re: [tor-relays] two relays serving same hidden service > To: tor-relays(a)lists.torproject.org > Message-ID: <BANLkTi=G8-OyQsz0rr38=PJWHNb7bgwCOA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hi > my tor is not working.It's logs show "No certificate available" > > please help > > Prafull >

2 1

two relays serving same hidden service
by cmeclax-sazri 10 Apr '11

10 Apr '11

Suppose I have this setup: Dhole, Dingo, and Fennec are three computers on a LAN. Dhole and Dingo both have external IP addresses and both run Tor relays. Fennec runs a hidden service. Both Dhole and Dingo have the same hidden service address, paxamifrabolerfu.onion, pointing to Fennec's LAN address. Alice tries to connect to paxamifrabolerfu.onion. What happens? cmeclax

3 2

avoiding frequent MyFamily syncing on a dynamic Tor instance group
by tagnaq 07 Apr '11

07 Apr '11

Hi, I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes: To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones. >From a security point of view this is probably quite a bad thing, but does someone already do that?

4 4