Re: understanding problem, hidden services
On 01/22/2011 07:57 AM, Bernd Kreuss wrote: Hi, Although This *might* be better asked on the dev list I am sure here are people who can answer this simple question too: You might get better answers there, but I think I have enough of a handle on this to try, I also have read the spec, and given it some thought... It does this by establishing a circuit to a randomly chosen OR does this mean Alice - OR1 - OR2 - Rend or Alice - OR1 - OR2 - OR3 - Rend I think you have two questions here, though I may be nitpicking. As far as the spec and OR protocols work, either should work. In fact, there is no reason, other than it being hard set in the default implementation, that a circuit couldn't be 1 or 1 million hops. That isn't to say that there are not practical reasons to not use many of those values, In fact, there would be no way to prevent a circuit from looping back through the same OR an arbitrary number of times. (not that this is at all recommended, I am just pointing it out for illustration) In any case, there is no real need to specify that in the spec, since, well, the details of the circuit creation are besides the point. So the real question is... what does the default client do. For exiting connections, 3 hops (entry, middle, and exit) are the default, and really a good balance between not having to trust that any one node can put the whole circuit path together, and not adding too much latency. You seem to realize where I am going with this: line 609: (Alice connecting to Bob's intro point) = Alice builds a separate circuit to one of Bob's chosen introduction points The same wording, the same interpretation? Alice - OR1 - OR2 - Intro - ORb - ORa - Bob ^^^ ^^^3 3 or are more than 5 nodes involved? More than 5 nodes would destroy the nice symmetry. It is still symmetric on each side of the middle node. However, five is a lot of hops! So, the developers were smart. 3 hops is what we need to be sure that we don't have to put too much trust in any one host, in fact, this whole switch to an introduction point is precisely to avoid having to trust the rendez-vous node too much. Now, think of a normal 3 hop connection: Alice - OR1 - OR2 - OR3 - End Service That is what we want... we can get that if: Alice-OR1 - Intro - ORb - Bob So, Alice and Bob each make half of the connection, to put together a normal, 3 hop, path. line 688: (Rendezvouz) == Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous point Here the word ending sounds clear to me. The rendezvouz is the last node in Bob's cicuit: Rend - ORb - ORa - Bob ^^ 3 Ending, not exiting. So ORb = Rend and you have one less hop. However, there is nothing to say that you couldn't implement it this way. Even if the spec forbade it, there would be no way for an OR to stop a client from doing it anyway. Now dependig on the iterpretation of line 589 mentioned in the beginning we have either: Alice - OR1 - OR2 - Rend - ORb - ORa - Bob ^^ 3^^ 3 which is nice and symmetrical and involves the same number of nodes from either side True, but as you can see from what I said above, OR2 = Rend = ORb leading to the path as I stated above. Now here on this website with the nice pictures that tries to explain it the whole problem is avoided by simply drawing a circuit as a green arrow, not mentioning how many nodes it has or whether it ends at the last node or connects to the last node: http://www.torproject.org/docs/hidden-services.html.en But in the text below the last image: In general, the complete connection between client and hidden service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the hidden service. Lets see Bob the hidden provider chooses his entry node, and his intro node. That is 2. Alice chooses her entry node, and then uses bobs intro node, so thats 1 for her, and a total of 3. Now Alice chooses an entry node for the new circuit, and she chooses the rendez-vous node. Thats 2 Bob now chooses his entry node for the new circuit, and then connects to the rv node. 1 for him, total of 3. So... between both connections, that is 6 nodes. This does not fit to *any* possible interpretation of rend-spec.txt: Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous point, This has to be either a 4-node circuit if Bob is allowed to chose 3 of its nodes or the wording in rend-spec.txt in line 688 is wrong. I am not looking at the spec now, but, somewhere there is an explanation that refers to these as half connections or half circuits since each side is moving to the middle and making half of a 3 hop circuit,
Re: understanding problem, hidden services
I'd like to second Bernd's question (see his OP, I won't quote it all here). This is a hazy area in my understanding of Tor, yet a clear understanding is important. Someone, kindly answer? -- Theodore Bagwell torus...@imap.cc On Sat, 22 Jan 2011 13:57 +0100, Bernd Kreuss prof7...@googlemail.com wrote: Hi, SNIP How does it really work? -- http://www.fastmail.fm - Does exactly what it says on the tin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: understanding problem, hidden services
On 23.01.2011 03:05, grarpamp wrote: Each endpoint must always be in control of three nodes. The Server uses the IP as its third. The Client uses the RP as its third. So for each step in the process it seems like this: # S inits 3 IP's S - SR1 - SR2 - IP # S publishes descriptor S - SR1 - SR2 - SR3 - DB # C requests descriptor C - CR1 - CR2 - CR3 - DB # C inits RP C - CR1 - CR2 - RP # C informs S of RP C - CR1 - CR2 - CR3 - :IP - SR2 - SR1 - S # S uses RP S - SR1 - SR2 - SR3 - RP # full path established = 6 relays, 7 hops C - CR1 - CR2 - RP: - SR3 - SR2 - SR1 - S The colon delimits the end of each sides control in the full path. The arrows are build extensions, not traffic. Ok, now Its all clear to me. I think it would be a good idea to include these little ascii diagrams in the text, each one of them at the end of the corresponding section of the text or all together in some kind of short summary or overview to easier visualize the state after each step has been performed. Bernd *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
understanding problem, hidden services
Hi, Although This *might* be better asked on the dev list I am sure here are people who can answer this simple question too: I am referring to this text: https://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=doc/spec/rend-spec.txt I recently tried to explain the hidden services to somebody and noticed that there is something I could not answer myself and also could not find in the above mentioned document: line 589: (Alice establishes rendezvous point) == It does this by establishing a circuit to a randomly chosen OR does this mean Alice - OR1 - OR2 - Rend ^^ circuit ending at Rend or Alice - OR1 - OR2 - OR3 - Rend ^ circuitconnecting to Rend I believe its the first one, a circuit to, not a circuit, connecting to, but it is not entirely clear from reading the text. line 609: (Alice connecting to Bob's intro point) = Alice builds a separate circuit to one of Bob's chosen introduction points The same wording, the same interpretation? Alice - OR1 - OR2 - Intro - ORb - ORa - Bob ^^^ ^^^3 3 or are more than 5 nodes involved? More than 5 nodes would destroy the nice symmetry. line 688: (Rendezvouz) == Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous point Here the word ending sounds clear to me. The rendezvouz is the last node in Bob's cicuit: Rend - ORb - ORa - Bob ^^ 3 Now dependig on the iterpretation of line 589 mentioned in the beginning we have either: Alice - OR1 - OR2 - Rend - ORb - ORa - Bob ^^ 3^^ 3 which is nice and symmetrical and involves the same number of nodes from either side or we have this: Alice - OR1 - OR2 - OR3 - Rend - ORb - ORa - Bob ^^ 3 ^^ 3 Which I don't believe (alice would have chosen 4 and bob only 2 nodes). Now here on this website with the nice pictures that tries to explain it the whole problem is avoided by simply drawing a circuit as a green arrow, not mentioning how many nodes it has or whether it ends at the last node or connects to the last node: http://www.torproject.org/docs/hidden-services.html.en But in the text below the last image: In general, the complete connection between client and hidden service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the hidden service. This does not fit to *any* possible interpretation of rend-spec.txt: Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous point, This has to be either a 4-node circuit if Bob is allowed to chose 3 of its nodes or the wording in rend-spec.txt in line 688 is wrong. How does it really work? Bernd *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: understanding problem, hidden services
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/rend-spec.txt https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/path-spec.txt http://www.torproject.org/docs/hidden-services.html.en As you've read and itemized the spec, which I'm off to read, here's my itemized take on the web page... A Tor circuit means three hops and out to the destination, at least in the exit case. So applying that three hop definition of a circuit to HS's would lead to the following summary of that web page: # init IP's S - SRx - SRx - SRx - IP # qty: 'some' or 3 # publish desc S - SRx - SRx - SRx - DB # aka: 1 DA, maybe more # request desc C - CRx - CRx - CRx - DB # aka: 1 DA, maybe more till found # C init RP C - CRx - CRx - CRx - RP1 # inform S of RP C - CRx - CRx - CRx - IP # qty: 1, of 'some' or 3 # S init RP S - SRx - SRx - SRx - RP1 # full path C - CRx - CRx - CRx - RP1 - SRx - SRx - SRx - S Which is seven hops. Everything is consistent on the page with 7. Up until this 6 bomb summary is dropped at the end, which is probably where many people, including me, get the 6 from... In general, the complete connection between client and hidden service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the hidden service. If so, the definition of circuit needs to be clearly redefined in this case. Also... this one needs work too. What is meant by identity? Its inet address is always protected from everyone 'learning' about it because it creates its own circuit. Who cares about the HS descriptor (with public key), anyone can get that. What other reasons, why use RP's? The HS put up a list of random IP's, not single ones, why not use one. The client did pick a single responsible relay, the RP. Or in the IP only case, the IP to use. I think the full path is joined out of band to prevent the DA's from knowing the possible meetme point(s). One of the reasons for not using the introduction circuit for actual communication is that no single relay should appear to be responsible for a given hidden service. This is why the rendezvous point never learns about the hidden service's identity. So I'm just agreeing that the web page and even the spec could really benefit from some clarification on hops and phrasing. I would also put the images above the text descriptions, seems kindof like top posting as it is now. And BOLD the step: labels. Also dug up from that web page... Step two: the hidden service assembles a hidden service descriptor, ... It uploads that descriptor to a distributed hash table. What I've read so far doesn't seem to indicate there is any such 'DHT' in use. It's more like the HS descriptors are simply uploaded to one or more, maybe all, of the 7 or so fixed public directory authorities chosen at random... not into a bulletproof DHT. And are then downloaded by querying the DA's until one is found that has the desired HSD. At least that's my take on it. By way of example, the Phantom project uses a real DHT for this purpose. This makes it pretty much immune to censoring the HS's, as well as overall takedown. And is stronger regarding being able to explicitly know all the descriptors that exist by coercing the DA's to log them (even though it should really be up to the HS admin to control access anyways, ie: scanning for or leaked services in the real world). Phantom expects to have a code release any day now. And last... it is of special importance ... HS sticks to ... guards I'd change that to critical importance or just required :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: understanding problem, hidden services
On Sat, Jan 22, 2011 at 01:57:57PM +0100, Bernd Kreuss wrote: line 589: (Alice establishes rendezvous point) == It does this by establishing a circuit to a randomly chosen OR does this mean Alice - OR1 - OR2 - Rend ^^ circuit ending at Rend or Alice - OR1 - OR2 - OR3 - Rend ^ circuitconnecting to Rend Whenever Alice chooses the node that Alice and Bob will use to interact, Alice uses that node as her third hop in a three hop circuit. Whenever *Bob* chooses it, Alice builds a three hop path of her own and then uses Bob's choice as the fourth hop. So in the above case, it will be the former situation: Alice - OR1 - OR2 - Rendezvous point. line 609: (Alice connecting to Bob's intro point) = Alice builds a separate circuit to one of Bob's chosen introduction points The same wording, the same interpretation? Alice - OR1 - OR2 - Intro - ORb - ORa - Bob ^^^ ^^^3 3 In this case, Alice didn't pick the Intro point. Alice wants three hops that she chose, so it will be Alice - OR1 - OR2 - OR3 - Intro. Whereas Bob wants three hops that he chose, so his side will be Bob - ORa - ORb - Intro. line 688: (Rendezvouz) == Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous point Here the word ending sounds clear to me. The rendezvouz is the last node in Bob's cicuit: Rend - ORb - ORa - Bob ^^ 3 Bob didn't pick the rendezvous point, so he wants three hops of his own plus the rendezvous point. Can somebody write a patch for rend-spec.txt to clarify? Thanks, --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: understanding problem, hidden services
Ok, I think it could be written as: Each endpoint must always be in control three nodes, with whoever chose the meetme using that as their third. Assuming meetme's don't apply in other areas of Tor, I suppose it could be further clarified as: Each endpoint must always be in control of three nodes. The Server uses the IP as its third. The Client uses the RP as its third. So for each step in the process it seems like this: # S inits 3 IP's S - SR1 - SR2 - IP # S publishes descriptor S - SR1 - SR2 - SR3 - DB # C requests descriptor C - CR1 - CR2 - CR3 - DB # C inits RP C - CR1 - CR2 - RP # C informs S of RP C - CR1 - CR2 - CR3 - :IP - SR2 - SR1 - S # S uses RP S - SR1 - SR2 - SR3 - RP # full path established = 6 relays, 7 hops C - CR1 - CR2 - RP: - SR3 - SR2 - SR1 - S The colon delimits the end of each sides control in the full path. The arrows are build extensions, not traffic. For the full Client-Server paths, I did not name the relays uniquely as 'OR1, OR2, OR3, ORa, ORb' as you guys have done, because there's no guarantee that they are used only once in such a path. AFAIK, it's possible to have: C - R1 - R2 - RP: - R1 - R3 - R2 - S Note the reuse of relays R1 and R2 in arbitrary positions. The only constraint that holds is that the Client and Server each choose their own unique relays independantly. I've corrected that above by calling out who chose them and their uniqueness within that. I'd definitely do that too in the new spec/page clarification. Does the code check that since S could be thought to consider RP as just a destination beyond its controlled exit of SR3, and RP is also just another relay from which S can build circuits, that RP is in fact excluded from being any of its three relays? In other words, this might be bad: S - SR1 - SR2(really RP) - SR3 - :RP ... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
The second some kind of automation starts kicking in, scanning for hidden services, I think this is a Bad Idea. scanning 36^16 possible hidden services is out of discussion... It's actually 32^16. Considering 10k nodes processing 1 per second would only take 3.9 trillion years to search port 80... The second some kind of automation starts kicking in, scanning for hidden services, I think this is a Bad Idea. ... I still would love it if the authorities receiving the hidden service descriptors would just dump them out in OnionLand for all to see. I'd consider it a bona fide and very welcome service to the community. HINT ;-) At least until Tor went full DHT. HINT ;-) For which the nodes would just dump their own views of same. It's up to the onion operators to permit or allow onion access. Nothing different than on the regular internet. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
Hi, On Fri, Jan 7, 2011 at 20:22, Peter McCann mc...@freeovernetfoundation.org wrote: If not, what do people think about setting up such an index? It seems like it might be very useful for those operators of hidden services that want to expose them to a wider audience than just the people they give the .onion name to. Being able to browse or search the hidden services might also be useful. As long as the hidden services are manually added, i can see where it's a good idea. The second some kind of automation starts kicking in, scanning for hidden services, I think this is a Bad Idea. Hidden services are called hidden for a reason: You need to look to find them. And that is one of the features that is key here, IMHO. Greets! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
On Fri, 7 Jan 2011 13:22:58 -0600 Peter McCann mc...@freeovernetfoundation.org wrote: On the website describing how to set up a hidden service I saw a mention of a (hypothetical?) Hidden Services Wiki where pointers to hidden services are stored. Does such a wiki exist? If so, where can I find it? Years ago, there was a popular place called The hidden wiki which was the only one in existence, that anyone knew about. It was then beseiged by child porn links and images and went away. Since then, many different services claiming to be the hidden wiki have come and gone. Someone also tried to setup a google search appliance to crawl all of .onion space. It didn't get very far for the obvious reason of most hidden service sites don't want to be found by the general population. The services don't link to each other, and they may be on random ports. It's possible one could create a search engine that crawls every possible .onion hostname on common tcp ports (80, 443, 8080, 8443). Over long periods of time, this may find many hidden services. -- Andrew pgp 0x74ED336B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
Hi, Am 07.01.2011 22:26, schrieb Andrew Lewman: It's possible one could create a search engine that crawls every possible .onion hostname on common tcp ports (80, 443, 8080, 8443). Over long periods of time, this may find many hidden services. I haven't given it much thought yet, but I like the idea of a central index and an option in torrc that publishes my .onion to this index (and maybe even push website changes/locally crawl the site). -- Moritz Bartl http://www.torservers.net/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
On the website describing how to set up a hidden service I saw a mention of a (hypothetical?) Hidden Services Wiki where pointers to hidden services are stored. Does such a wiki exist? If so, where can I find it? There could be rumors on the internet(s) that there may be a mediawiki-based wiki with links to .onion sites at http://kpvz7ki2v5agwt35.onion/wiki/index.php/Main_Page There could also be rumors that there is a list of links at http://dppmfxaacucguzpc.onion/ There could even, possibly, be some search-engine at http://oqznfi3tdo6nwg3f.onion/ If not, what do people think about setting up such an index? It seems like it might be very useful for those operators of hidden services that want to expose them to a wider audience than just the people they give the .onion name to. Being able to browse or search the hidden services might also be useful. Expose? Wider audience? Nothing indicates I ever visited a hidden service, but I doubt those who do and those who operate such sites, if they even exist, require the wider audience. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
Nils Vogels wrote: Hi, On Fri, Jan 7, 2011 at 20:22, Peter McCann mc...@freeovernetfoundation.org wrote: If not, what do people think about setting up such an index? It seems like it might be very useful for those operators of hidden services that want to expose them to a wider audience than just the people they give the .onion name to. Being able to browse or search the hidden services might also be useful. As long as the hidden services are manually added, i can see where it's a good idea. The second some kind of automation starts kicking in, scanning for hidden services, I think this is a Bad Idea. scanning 36^16 possible hidden services is out of discussion... at least for me... that's why i stopped cloning google... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Crypto for hidden services [was: TorFaq on https]
Hi, just wanted to add one thing: There is no real reason not to use another layer of cryptography on top of Tor hidden services. Using HTTPS, and convincing users to use HTTPS, is far harder than merely using another layer of cryptography, and provides no real benefit. And (from a user point of view) if your HS uses https, the user sees always the BSCE (Big Scary Certificate Error), for no additional security. This makes the user feel less secure, although he is not. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Crypto for hidden services [was: TorFaq on https]
On Thu, 28 Oct 2010 21:13:34 -0700 Robert Ransom rransom.8...@gmail.com wrote: On Thu, 28 Oct 2010 22:06:03 -0400 grarpamp grarp...@gmail.com wrote: is the server (hidden service) privacy threatened by using https too in any way? I don't see any risk to the server. Not particularly. Though it would add additional fingerprinting oppurtunities beyond Tor and the service themselves. This is the only one I can think of. I thought of this, but the hidden service private key would be enough of a giveaway. Having a second private key around is no easier or harder to hide than having the first private key around. Oh, you meant remote fingerprinting of the server's TLS stack. I didn't think of that, but I doubt that it's any worse than the HTTP server's fingerprint. I thought you were talking about fingerprinting a captured server, because Tor is not supposed to leak (much) information about itself to the other end of a circuit. Robert Ransom signature.asc Description: PGP signature
TorFaq on https for hidden services ( was: Hints and Tips for Whistleblowers )
hello. im starting this as a new thread, as my question is only inspired by the discussion above. in the TorFaq ( https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ ) it says: Why is it better to provide a hidden service Web site with HTTP rather than HTTPS access? Put simply, HTTPS access puts the connecting client at higher risk, because it bypasses any first-stage filtering proxy.. the answer in the FAQ refers to privoxy. so i wonder now: is this answer obsolete meanwhile? or is it still the general recommodation to run hidden services without https? is the server (hidden service) privacy threatened by using https too in any way? the FAQ also says: These objections all apply to HTTPS, TLS, SSH, and generally all cryptography over Tor, regardless of whether or not the destination is a hidden service which i think is causing some confusion. startx *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TorFaq on https for hidden services ( was: Hints and Tips for Whistleblowers )
On Thu, 28 Oct 2010 10:10:52 +0100 startx sta...@plentyfact.org wrote: hello. im starting this as a new thread, as my question is only inspired by the discussion above. in the TorFaq ( https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ ) it says: Why is it better to provide a hidden service Web site with HTTP rather than HTTPS access? Put simply, HTTPS access puts the connecting client at higher risk, because it bypasses any first-stage filtering proxy.. the answer in the FAQ refers to privoxy. so i wonder now: is this answer obsolete meanwhile? Yes. or is it still the general recommodation to run hidden services without https? I would recommend that hidden services not use HTTPS. The Tor hidden service protocol does an adequate job of authenticating servers and encrypting traffic to them. In addition, it is unlikely that any CA that Firefox is configured to trust would issue a certificate for a .onion hostname. is the server (hidden service) privacy threatened by using https too in any way? I don't see any risk to the server. the FAQ also says: These objections all apply to HTTPS, TLS, SSH, and generally all cryptography over Tor, regardless of whether or not the destination is a hidden service which i think is causing some confusion. Yes, that is a bad sentence. I think it's time to nuke that FAQ entry. (Probably long past time to nuke it.) Robert Ransom signature.asc Description: PGP signature
Re: TorFaq on https for hidden services ( was: Hints and Tips for Whistleblowers )
On Thu, Oct 28, 2010 at 10:10:52AM +0100, startx wrote: the answer in the FAQ refers to privoxy. so i wonder now: is this answer obsolete meanwhile? Yes, it's wrong. It's a wiki -- please fix it. :) In fact, none of the Tor developers added this particular question in the first place. That's part of why I've been pushing to migrate the faq entries that are actually useful onto https://www.torproject.org/docs/faq so we can abandon the wiki faq. Thanks, --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TorFaq on https for hidden services ( was: Hints and Tips for Whistleblowers )
Hi, Robert Ransom wrote (28 Oct 2010 09:22:17 GMT) : In addition, it is unlikely that any CA that Firefox is configured to trust would issue a certificate for a .onion hostname. Please note there are other ways to authenticate SSL servers, e.g. see the Monkeysphere project: http://web.monkeysphere.info/ Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | The impossible just takes a bit longer. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Crypto for hidden services [was: TorFaq on https]
or is it still the general recommodation to run hidden services without https? I would recommend that hidden services not use HTTPS. The Tor hidden service protocol does an adequate job of authenticating servers and encrypting traffic to them. In the hidden service context for all below... Tor does NOT authenticate any particular underlying service [web, mail, etc], nor does it encrypt traffic to/from them. Tor merely authenticates and encrypts between two Tor daemons, one as a client and one as a HS. Give an elaborate setup behind a HS, perhaps tunneling the stream off the server, across the net, to other parties who terminate it on some daemon or cloud. Maybe some WikiLeaks form of submission/storage, or joining anon systems, or just a clueless HS admin. Or that someone is able to read the particular crypto Tor uses, but not the crypto your tunnel uses. Would you, or the provider of the intermediate or final services, not want that extra layer of protection just in case? Your bank in it's internal cloud? SSH/IRCS/SILC to behind a HS is an extra tunnel. It costs nothing. Were it still available, no one in their right mind would use ssh -c none. In addition, it is unlikely that any CA that Firefox is configured to trust would issue a certificate for a .onion hostname. Perhaps, and quite unfortunately, not. However, even though the chain would break on the hostname, it would still be of supplementary value if some dual-homed site of importance to the user ran with the same cert [fingerprint] as on the internet. Especially given that the prevalence of the below aside is presumed to be extremely low. [aside: As DNSSEC is not global yet, multi-homing a non onion cert would be on the same par as a bogus/stolen cert and mitm dns, for say your bank.] is the server (hidden service) privacy threatened by using https too in any way? I don't see any risk to the server. Not particularly. Though it would add additional fingerprinting oppurtunities beyond Tor and the service themselves. This is the only one I can think of. These objections all apply to HTTPS, TLS, SSH, and generally all cryptography over Tor, regardless of whether or not the destination is a hidden service The whole, well we've got the anon system doing node to node encryption/auth, why bother with TLS... sounds an awful lot like why Johhny can't encrypt and why the internet still isn't encrypted. As there doesn't appear to be any real reason NOT to use crypto over top of any given anon system, might as well do it just in case. Foregoing extra 0-day's in crypto libs as applied, and the above fingerprinting... why pan it? And PKI, even amongst the anon, can be very useful thing. Communuties will be built, PKI will help. It's no different than the internet. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Crypto for hidden services [was: TorFaq on https]
On Thu, 28 Oct 2010 22:06:03 -0400 grarpamp grarp...@gmail.com wrote: or is it still the general recommodation to run hidden services without https? I would recommend that hidden services not use HTTPS. The Tor hidden service protocol does an adequate job of authenticating servers and encrypting traffic to them. In the hidden service context for all below... Tor does NOT authenticate any particular underlying service [web, mail, etc], nor does it encrypt traffic to/from them. Tor merely authenticates and encrypts between two Tor daemons, one as a client and one as a HS. Tor verifies that the hidden service's descriptor is signed by a private key whose public key's truncated hash matches the hidden service hostname. For an HTTPS connection, your browser merely verifies that some CA which the browser's developers have been paid to make users ‘trust’, whether directly or indirectly, has signed a certificate claiming that the server's public key can be ‘trusted’ to serve a particular hostname. Tor's authentication of hidden services is better than anything HTTPS can do. Give an elaborate setup behind a HS, perhaps tunneling the stream off the server, across the net, to other parties who terminate it on some daemon or cloud. Maybe some WikiLeaks form of submission/storage, or joining anon systems, or just a clueless HS admin. A clueless HS admin can publish all requests which reach his server onto the Internet. A malicious HS admin can forward all requests to NSA, CIA, FBI, Mossad, GCHQ, and whatever other entities are out to get you. Or that someone is able to read the particular crypto Tor uses, but not the crypto your tunnel uses. I'm slightly worried about this, but I currently don't see any tunnel software in use that uses cryptographic algorithms that I consider stronger than Tor's. Would you, or the provider of the intermediate or final services, not want that extra layer of protection just in case? Your bank in it's internal cloud? SSH/IRCS/SILC to behind a HS is an extra tunnel. It costs nothing. Were it still available, no one in their right mind would use ssh -c none. HTTPS to behind a HS costs the user rather a lot of effort, for minimal, if any, benefit. Thus, I would recommend that hidden services not use HTTPS. In addition, it is unlikely that any CA that Firefox is configured to trust would issue a certificate for a .onion hostname. Perhaps, and quite unfortunately, not. However, even though the chain would break on the hostname, it would still be of supplementary value if some dual-homed site of importance to the user ran with the same cert [fingerprint] as on the internet. Especially given that the prevalence of the below aside is presumed to be extremely low. [aside: As DNSSEC is not global yet, multi-homing a non onion cert would be on the same par as a bogus/stolen cert and mitm dns, for say your bank.] I don't expect most users to verify SSL certificate fingerprints out of band, whether ‘out-of-band’ means on the non-Tor Internet, over the telephone network, or through the mythical DNSSEC. is the server (hidden service) privacy threatened by using https too in any way? I don't see any risk to the server. Not particularly. Though it would add additional fingerprinting oppurtunities beyond Tor and the service themselves. This is the only one I can think of. I thought of this, but the hidden service private key would be enough of a giveaway. Having a second private key around is no easier or harder to hide than having the first private key around. These objections all apply to HTTPS, TLS, SSH, and generally all cryptography over Tor, regardless of whether or not the destination is a hidden service The whole, well we've got the anon system doing node to node encryption/auth, why bother with TLS... sounds an awful lot like why Johhny can't encrypt and why the internet still isn't encrypted. As there doesn't appear to be any real reason NOT to use crypto over top of any given anon system, might as well do it just in case. Foregoing extra 0-day's in crypto libs as applied, and the above fingerprinting... why pan it? There is no real reason not to use another layer of cryptography on top of Tor hidden services. Using HTTPS, and convincing users to use HTTPS, is far harder than merely using another layer of cryptography, and provides no real benefit. And PKI, even amongst the anon, can be very useful thing. Communuties will be built, PKI will help. It's no different than the internet. We have a PKI for hidden services already, designed into the protocol. I do not expect piling HTTPS on top of that PKI to add any security at this time. Robert Ransom signature.asc Description: PGP signature
Harden torrc for hidden services?
Are there any extra options you could add in the torrc file to harden hidden services from possible attacks? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [tor] Re: Hidden Services Hosting and DMCA
Hi, On 13.06.2010 23:43, andrew wrote: Then of course he already mentioned a couple of times that he's not in the USA, so even if you were a lawyer he shouldn't take your advice ;) Right. I read the thread too. He is not, but his service and the underlying provider are in the USA. Thank you for your feedback. Still, you're right, I should be more careful with that. I will not host hidden services until I have gathered more information about the consequences. Moritz Bartl http://www.torservers.net/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
On Sun, Jun 13, 2010 at 05:54:41AM +0200, t...@wiredwings.com wrote 3.0K bytes in 57 lines about: : determine the ISP, in the Internet today it is trivial. Regardless of : that, in the end I am just an ISP. If they put so much work in finding You need to be very careful about calling yourself an ISP. There are all sorts of legal obligations around being an actual ISP in the USA. The main item to consider is CALEA compliance and how you handle data retention upon subpoena or court order. I believe the term you want to say is ISP-like or like a common carrier. I'm not a lawyer, don't take this as legal advice. : Especially with the current : political situation, I see a market around Tor, and you should not : misconceive that. Commerce is not all bad. I agree. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
On Sun, Jun 13, 2010 at 10:38:09PM +0200, pipat...@gmail.com wrote 1.0K bytes in 19 lines about: : Then of course he already mentioned a couple of times that he's not in : the USA, so even if you were a lawyer he shouldn't take your advice ;) Right. I read the thread too. He is not, but his service and the underlying provider are in the USA. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Hidden Services Hosting and DMCA
Hi, We are currently having a discussion over at torservers.net on whether it is wise to offer hidden service hosting. Most people don't have a server, they use free email or pay for cheap webhosting. The barrier to create hidden services is quite high. I feel that the Tor network could definitely use an ISP who offers hidden services hosting. My idea was to use a separate, disk encrypted virtual machine for hosting hidden services, and only open it towards the Tor network. Regular, non-anonymous donators should then be able to open their files towards the Internet, too. If you use that server for other things beside Tor you will have a hard time to explain and argue when abuse requests arrive - in fact you can't. It is quite easy to differentiate between a client (tor-exit) or a server (hosted content) also for authorities. Thank you. You're right, this has to be investigated further. I don't think that hosting content - on a logically different machine - influences the forwarding argument for the Tor nodes. Also, I don't see how it is quite easy for authorities to differentiate between middle node traffic and hidden services - that's what they are there for after all. You will not be able to use the response template if you get abuse requests because it does apply for Tor only. Then it will still apply for the IP addresses of the nodes. [...] We further recommend that you not keep any potentially illegal files on the same machine you use for Tor, nor use that machine for any illegal purpose. Although no Tor relay in the US has ever been seized, nor any relay operator sued, the future possibility cannot be ruled out. If that happens, you will want your machine to be clean. [...] The Tor machine will be clean. If I rent a virtual machine, I also don't know what happens on other VMs, and this is how I interpret this. I'm not even so sure if DMCA applies for me, a German hoster offering services, even when using US servers. Internet law isn't easy. Moritz Bartl http://www.torservers.net/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
On 12/giu/2010, at 12.49, Moritz Bartl t...@wiredwings.com wrote: The barrier to create hidden services is quite high. I'm not too sure about this: you can run hidden services on tor clients which do not relay any traffic for the network. Starting a service is not that difficult: an home flat Internet connection and a low power computer are ideal for a small personal hidden service. -- Sent from my iPwn *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
Hi, On 12.06.2010 13:13, Marco Bonetti wrote: On 12/giu/2010, at 12.49, Moritz Bartl t...@wiredwings.com wrote: The barrier to create hidden services is quite high. I'm not too sure about this: you can run hidden services on tor clients which do not relay any traffic for the network. Starting a service is not that difficult: an home flat Internet connection and a low power computer are ideal for a small personal hidden service. That machine should be up 24/7, and you still need to maintain (ie. update) it. -- Moritz Bartl http://www.torservers.net/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
On Sat, 12 Jun 2010 13:15:47 +0200 Moritz Bartl t...@wiredwings.com wrote: On 12.06.2010 13:13, Marco Bonetti wrote: On 12/giu/2010, at 12.49, Moritz Bartl t...@wiredwings.com wrote: The barrier to create hidden services is quite high. I'm not too sure about this: you can run hidden services on tor clients which do not relay any traffic for the network. Starting a service is not that difficult: an home flat Internet connection and a low power computer are ideal for a small personal hidden service. That machine should be up 24/7, and you still need to maintain (ie. update) it. What a strange thing to say! How can you credibly claim to know the availability requirements for other persons' hidden services? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
Hi Scott, On 12.06.2010 21:10, Scott Bennett wrote: That machine should be up 24/7, and you still need to maintain (ie. update) it. What a strange thing to say! How can you credibly claim to know the availability requirements for other persons' hidden services? I sorry you're right. Being not a native speaker, you shouldn't take all my phrases literally. ;-) Let me rephrase that: I see a group of people who might to provide hidden services, but don't have the resources and/or expertise and/or will to do it all by themselves. Cheers, Moritz *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
On 12.06.2010 22:15, Moritz Bartl wrote: I sorry you're right. LOL now that was a typo. :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hidden Services Hosting and DMCA
Thus spake Moritz Bartl (t...@wiredwings.com): On 12.06.2010 13:13, Marco Bonetti wrote: On 12/giu/2010, at 12.49, Moritz Bartl t...@wiredwings.com wrote: The barrier to create hidden services is quite high. I'm not too sure about this: you can run hidden services on tor clients which do not relay any traffic for the network. Starting a service is not that difficult: an home flat Internet connection and a low power computer are ideal for a small personal hidden service. That machine should be up 24/7, and you still need to maintain (ie. update) it. Actually, the uptime problem is a rather good reason not to consolidate hidden services with your exit node. An anonymous user on the I2P network used to run a public intersection attack on I2P router uptime vs eepsite (hidden service) uptime. It was rather easy to correlate which I2P nodes were running which services with this data. Of course, running hidden services in a separate VM might not have the correlation that using the same Tor process will, but host OS downtimes will still be correlated. If it is known that you are a large provider of hidden services, it becomes useful for an adversary to closely monitor your host OS for downtime to correlate to downtime of hidden services. As a related point, you need to be very careful about your opsec when providing services like this. While US law protects you from incriminating yourself by revealing your own encryption keys (probably), it does not protect you from divulging encryption keys of your users if you have them, nor does it protect you from court orders requiring you to install monitoring software into your user's systems to see what they are doing. Add in the correlation properties for hidden services or other data that may be available due to knowledge of your hosting setup (think apache+php versions, etc), and there may be a sufficient level of cause for such court orders to be binding. Of course, you can try to simply ignore these orders due to the fact that you're German and they're not likely to extradite you over them, but you'll probably lose your server, and you might have trouble entering the US at a later date then. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpfRAgqRsjIQ.pgp Description: PGP signature
Re: Hidden Services Hosting and DMCA
Hi Mike, Thanks for your valuable input. What you are saying implicates that there might be forces interested in investigating what I am hosting. In a way, you need to compare it to any ISP hosting illegal content without knowledge. In the case of hidden services it might be harder to determine the ISP, in the Internet today it is trivial. Regardless of that, in the end I am just an ISP. If they put so much work in finding the source, and the source turns out to be me - as in an ISP -, what else is there to do other than contacting me? I will do everything I can to shut down illegal services, not only because I am forced to by law, but because I feel it is the right thing to do. The hosters I deal with all agreed to forward abuse to me based on DCMA (or the appropriate country specific equivalent), and I approached them with a commercial partnership background. If I were to defend the idea, I could say that if you tried to find the source of a hidden service, personal servers with worse/less regular uptime on a residential line would be much easier to track down. Of course, you can try to simply ignore these orders due to the fact that you're German and they're not likely to extradite you over them, but you'll probably lose your server, and you might have trouble entering the US at a later date then. Sad as it is, if that's what it takes, I'm up to it. My education spans carefully crafted rights, and if these rights are no longer guaranteed, I will, I want to, stand up for them. I will never *ignore* any orders, but I will carefully examine the legal basis of the inquiry. I've been maintaining a fairly high bandwidth Tor exit for years now, and I know how to deal with abuse. The worst thing that happened was a murder case investigation, but it was no problem to clear it up without any interruptions of my Tor node. I have contacted enough cooperating ISPs outside the US if that turns out to be necessary (and I hope to find more through this project). This specific server at Softlayer is paid for on a monthly basis. I will not provide decryption keys, and luckily I am not forced to do so. If I were, I would not consider doing this. I have closely looked at (somewhat) related incidents in Germany, and all charges have been dropped for lack of evidence if the respective disks were encrypted, in all cases. I feel that this discussion is on the brink of something off topic, but the implications are something that definitely need to be clarified in any case, no matter how I decide. Speaking to the list: I understand that most of you are skeptical about this venture, and you have all the right to be. You should be. But don't just give up one me, tell me about it. Especially with the current political situation, I see a market around Tor, and you should not misconceive that. Commerce is not all bad. Moritz *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[GSoC] JTor Hidden Services
Hello Everyone, I am doing GSoC this summer with Tor. My name is Kory Kirk, I am a Computer Science masters student at Villanova University (west of Philadelphia); I will be graduating this weekend and then I am moving to Austin, TX a week later. Last year I also participated in GSoC with the Tor project adding features to Torbutton Firefox extension. This summer I will be working on implementing Hidden Service access and publishing capabilities in the Java implementation of Tor, JTor, with Bruce Leidl. In addition, I will be revising rend-spec to reflect the current state of Tor hidden services. You can follow my progress by checking for updates on my GSoC blog, http://korykirk.com/GSoC/2010http://korykirk.com/GSoC/2010/index.php/, my proposal is also available there. I am very excited to have another Summer of Code with Tor. I look forward to collaborating with people! My irc nick is koryk feel free to shoot me a message if you have any questions/critiques of my proposal. -Kory
Hidden Services
I'm trying to set up a hidden service (website) and for some reason, FF won't resolve the url (zygwjgs2sp7wcmws.onion). My FF settings are as follows: HTTP Proxy: 127.0.0.1:8118 SOCKS5 Proxy: 127.0.0.1:9050 network.disable.dnsPrefetch set to true network.proxy.socks_remote_dns set to true I'm having the same problem with Apple Safari (which on Windows is apparently just IE in a new skin) with the same proxy settings. Windows XP Home SP1 Do I need a web server already running for this to work (if so, I'm feeling very dense right now)? If so, I can easily set up Apache to deal out to 127.0.0.1:80. -- PIT signature.asc Description: OpenPGP digital signature
Re: Freenode's (irc) Tor Catch 22? Two hidden services = zero?
[...] I found this problem too but as I could understand the registration for the accounts with gpg need to be made by hand by the operators so we need to wait one or two weeks. I also be waiting. -- Ciao leandro pgpErNoxB1uU9.pgp Description: PGP signature
Freenode's (irc) Tor Catch 22? Two hidden services = zero?
Freenode's website lists two tor hidden services for their IRC network: http://freenode.net/irc_servers.shtml Their hidden server #1 (public): irc://mejokbp2brhw4omd.onion/ Their hidden server #2 (gpg): irc://5t7o4shdbhotfuzp.onion/ Their hidden server #1 is for the general public using tor, while server #2 is for those who go through the process of using gpg and being identified with your key for server #2. Two servers, one public and one which requires a few hoops to jump through prior to use, this all sounds well doesn't it? Until you attempt to *use* either server, that is. Login attempt #1: their public tor hidden service (server #1): Try once, twice, try all day and it drops your connection with a message of signing up for their hidden service #2 for gpg users. Weird, so while their website lists their hidden service #1, it's actually non-functional with a message dropping your connection informing you of their gpg hidden service. With the desire to login to freenode using tor, I continue this quest by attempting to sign into their hidden server #2 in order to register an account for their gpg service. A glimmer of hope for a few seconds, until it drops me with a sour bad password message. I attempted to login with tor on one of their public non-hidden service servers and it didn't matter which public server I tried, it dropped the connection because tor is banned on their public servers. So here's the rub: In order to use their gpg hidden service you must apply first as instructed near the bottom of the page at: http://freenode.net/irc_servers.shtml But in order to start the process for gpg application, you must first *register* an account on freenode. Since the first public hidden service kicks you and won't allow you to register an account, the second gpg hidden service kicks you because you haven't been approved for an account, and finally, attempts to login to their public freenode servers with tor fail. This makes it impossible to login with tor on any of their servers and generate an account with which to apply for freenode's gpg hidden service. Unless you sign into their public servers without using tor or by some other means where you would likely be giving away your private details through an insecured medium. Why do they retain the hidden service #1 just to kick users? Why don't they allow you to sign in and create an account and either disallow access to all channels (so you may only make an account to sign up for gpg tor) or allow you to register an account and create a sandbox for these tor users in one channel such as #gpg-torsignups? This would allow users to sign into their hidden service #1 and create an account securely in contrast to right now where no one can securely create an account for a gpg tor application. Isn't this sort of a catch 22? Why do they mention hidden services on their website at all? I don't see any SSL enabled public servers on their list. So one would have to login to an unsecured server in order to register for a hidden service/gpg? This sounds all wrong, or am I missing something? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
abot hidden services
Helo, how secret are hidden services, because i heard abaout some attacks like Revealing Hidden Services by their Clock Skew? what ist the secrest way to deploy a hidden service? thanks versendet mit www.oleco.de Mail - Anmeldung und Nutzung kostenlos! Oleco www.netlcr.org - jetzt auch mit Spamschutz. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
hidden services questions
What happens if someone offers a hidden service (i.e., same .onion address, same keys, etc.) on more than one computer, perhaps in different locations? How do HSDir servers handle such a situation? Does the most recently published hidden service descriptor supplant earlier descriptors even if it comes from a different source? Can HSDir servers even recognize a [possible] problem? 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 * **
Hidden services
I don't seem to be able to access any .onion addresses at the moment. Can someone point me to a known working one? Thanks, GD _ Lauren found her dream laptop. Find the PC that’s right for you. http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290
Re: Hidden services
Hidden wiki is up right now: kpvz7ki2v5agwt35.onion Ringo downie - wrote: I don't seem to be able to access any .onion addresses at the moment. Can someone point me to a known working one? Thanks, GD _ Lauren found her dream laptop. Find the PC that’s right for you. http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290
Re: Question: Hidden Services, Virtual Machines, and iptables
On Tue, Jul 7, 2009 at 10:38 PM, Ringo2600den...@gmail.com wrote: ... I still feel like there's got to be a simpler way to do this. iptables owner match (by process uid) is simpler, both LAMP and Tor in a single VM. restrict outbound for LAMP user processes. lightweight appliance type virtual machines can be light on resource consumption even with many running concurrently. the LAMP stack will be the most resource intensive part. best regards,
Re: Question: Hidden Services, Virtual Machines, and iptables
Ringo wrote: Hey Tor users, My work to write a how-to manual for setting up and securing hidden services is well underway, but I've got a question that's been getting at me. Obviously, hidden services are the 'most secure' when they're run inside a virtual machine (qemu, vmware, etc. pick your poison). One could certainly run Tor inside the vm and then have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. We would only want the vm accessing the web IF it was going through Tor, but we wouldn't want to just route all vm traffic through the host's Tor client because then you could be running Tor... over Tor. You could use a live-cd instead of a VM. as coderman suggest owner match is probably the simplest if you have an extra IP address you could assign it to the VM and match on it. We have been considering adding something like this to our live-CD. The problem of course is dealing with NAT.
Question: Hidden Services, Virtual Machines, and iptables
Hey Tor users, My work to write a how-to manual for setting up and securing hidden services is well underway, but I've got a question that's been getting at me. Obviously, hidden services are the 'most secure' when they're run inside a virtual machine (qemu, vmware, etc. pick your poison). One could certainly run Tor inside the vm and then have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. We would only want the vm accessing the web IF it was going through Tor, but we wouldn't want to just route all vm traffic through the host's Tor client because then you could be running Tor... over Tor. One solution would be to create an iptables blacklist (on the host) and then ban connections to any computers which *aren't* Tor servers. This seems like it might be a little work to implement and an adversary could always set up a Tor server if they could hack your hidden service and remotely execute code (or cause your web server to fetch external content). Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious. You've only got one layer of encryption and any serious exploits found in Tor could be used against the host machine, revealing the true IP address of the hidden service. Also, if somebody were forced to reveal the encryption key to the hard drive, the game would be up as opposed to running a vm from a deniably-encrypted truecrypt drive that was mounted remotely via ssh. Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? Also, anybody with hidden service security tips (particularly on implementing a LAMP server) is welcome to contact me off-list for obvious reasons. My PGP key is pasted below. Thanks, Ringo -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEniUKIRBADfn8kULsRd3si+zPnVbeVp4C/cjxfOxvPURPjRMDPRZPuDuEI5 QIiMP+lZs0Y1BS/zubrwJ/R+knZW0dfkCbd0IBqhtcci4ZiDXRCNxxYow0MysweG sbZE0QY4T2u40ffOLs9m/ENiDebUxknTyAg8/Jim9aBdEDgurCc7HCX+iwCghfLh 1POMWQRkXB4zUmXQfp+u+0MD/j5SUN6ct6fH4ex3L/WeIHRA+PZXBEpQv5HCwcYO 9VAtS0KYTtrBePXuhabjmiyhWIVsPHa8A+5RW3ONkK4gQ71E7sh2nu44p0rOSVkz 9/ZQiHVCjxZJNhvCsabIFT2/G8OFo2XPnJ0+8Gfluueb5a/HKArUWHIvkws82kQ5 75RJBACJp436/Bvk/CpKDkIG8v/4dQkyNKhv5AEAbx3jNjdOAxNSK0tBaQAulgCk GFNkk+wpv6OWaawgQzFh71KvmEswSLObXk+S6WZgC+Epy4XmfzzDG/gIHD0VuBQ+ 2D8JzFT/TiDMu6wdYu4kgDg5sO4a5Yzn7xoYMF5YWzXnPKhXi7QacmluZ28gPHJp bmdvQGhhY2tibG9jLm9yZz6IZgQTEQIAJgUCSeJQogIbIwUJAeEzgAYLCQgHAwIE FQIIAwQWAgMBAh4BAheAAAoJEFUc7QiIWsvrdtkAn3KtPdxxC/qWmmIFZ4Nc4cFE as42AJoDwdk/N9I3sPvc91wTTlbsKhoHLrkEDQRJ4lCiEBAAs2JYGr1k1Dgi3DMy h0ziX+22tIWWyIJoGKWKFspA7nGeniOBodLBvR+POtqqGCh+bkm9I0X/YMF9oVcP xXBql7H6E4JSgtCk7xtohDpLlfcCpsddVxcJdXYLynTUMcmJtCER0bCNIkTmYoV7 uNXAqmUNAp4zaI70yWsidpAVHme0+sBUYNinfBdlcaMddzslbDtRV7yGKgvW3E5e hPNTJ0pWF6WJg4VsEOFoP7pldtQ4YWScskvuCk957K4t4Of3QZs13Nn9sQZleFJU E2L1bxEHuSqY/f1F/pbKmc7in8qkoBBAyhUbzCNxxELdof3uJpBy0pw0468GvSyb Z4jyh2XFvxFFAcelzc453y9GOylIC0OQczkrzOa6QrIWQSmeCzn/byjLoi+TRFve usRmJn5H9MJg+k+mG5LJM2mcyQJU2UOPDvSurKmk50vByBED6Qn5CvhXJp18H6Uk 2r+PICG4h8aN9KZpSrMAqYggyKgAxHTlCaQzGCwvJGiX6lx6iIm2GLoqeHdRHZZX 9XognVcbTwUWJkL0LR9nhm5U0GhFGM9eRdLw89C/Z/s1/Q/QLjoDh60qXcYo+vFS 5bJtiT52HnlA002opyi+Zn5mk9aXQiksOJruIdNw1rvJSe+uAIYQeBv+rinxzAyL 4f/p/+vvgnfgkEc2G1hLuGTvWMsAAwYP+gIhIgQ6UwQ0Bu1gyRN88Gs9H0fnQ74Z RmFXDgUtpn1YrFzFfTNegQh8vvgo1pXV4ZDPc0w9Cs8QHrspnkYrvSymAEmwYtGd nvnAVVROIJfN5d140Z1FJXCgFp/3m2SAX1omYyN3/5WX9ef1uaYWub48kSdqfHlr xe8Z15nXQ9E6WMgDtP5jXpfCkAnweW6/WSGRrHlRyBUevCTyRSZ4dwtim0GHsls9 VbfDYWJVxiKWdgjtjg+PfsXrdQG2KICEHXprS9/tYCheWaHP4couXVHDPUNMGK/w HSYXbr0/xA0i0JHpRzVCDweKZ32hgbYkTXp0U7ArBYLtbfpWlB8uWHFFAIS5yJQL YMwc8/qFCgl5fUGMk4ZLTgbftQo/sfcOAIPQl2nVjhnvzucj8PgBBaJgH9ORTpW6 89zIzOtfXfju0dq4LC6Xj4h6SA/duh8dEiBzewNJ1FwnlrywvaQjsVdx5+5RolAk gZKcT4hHCj+s2vCAyF5R70rfKkZkKhMuUzEWc4R4AzbkmI1eTtEl/FJVCzBsJRan HC+YMgCdf2ujTxvBltytpWrs0nvzFVY6+RyihQsqlV6KeOtDBTv38a8Q5gdARK0j 5og+X3SWHW0p29PSKk6a3NeSB08J0wlXsrNOJ/JXlYw/yIifZdgl6fO8V7rPBoQt xIQB5UKSXj8YiE8EGBECAA8FAkniUKICGwwFCQHhM4AACgkQVRztCIhay+vXkQCf beWbtPmJOWbXn+9LEaJTqcN73REAn2MmtesdDs24QjWfZeTfc8dyEZ2n =O0oE -END PGP PUBLIC KEY BLOCK-
Re: Question: Hidden Services, Virtual Machines, and iptables
On Tue, Jul 7, 2009 at 6:10 PM, Ringo2600den...@gmail.com wrote: ... One could.. run Tor inside the vm and have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. ... Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? in such a configuration i prefer to use two virtual machines. one vm has host-only networking to serve hidden service content. second vm hosts Tor router with hidden service pointed at vm host. host uses iptables redirect and/or tcp proxy to connect hidden service connections from Tor VM to hidden service VM port at host-only endpoint. (there are variations on this theme...) best regards,
Re: Question: Hidden Services, Virtual Machines, and iptables
That's a good solution, but it sounds like it would take lots of memory/cpu, especially if you're running both of these VMs from an encrypted partition. If a serious exploit was found in Tor (or implemented in Tor), it would still be able to break out of the main VM, but at least it still wouldn't have a real IP address. I still feel like there's got to be a simpler way to do this. Ringo coderman wrote: On Tue, Jul 7, 2009 at 6:10 PM, Ringo2600den...@gmail.com wrote: ... One could.. run Tor inside the vm and have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. ... Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? in such a configuration i prefer to use two virtual machines. one vm has host-only networking to serve hidden service content. second vm hosts Tor router with hidden service pointed at vm host. host uses iptables redirect and/or tcp proxy to connect hidden service connections from Tor VM to hidden service VM port at host-only endpoint. (there are variations on this theme...) best regards,
Hidden services on Tor versions 0.1.2.x should be upgraded soon!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, if you run a hidden service on Tor version 0.1.2.x or lower, you should upgrade to 0.2.0.x or 0.2.1.x soon. Otherwise, people running Tor versions 0.2.2.x or higher won't be able to reach your hidden service. Why is this the case? We added a new format for hidden service descriptors in 0.2.0.x and made hidden services and clients speak both the old and the new format. 0.2.1.x didn't change that. But in 0.2.2.x we have just dropped support for the old format. Speaking both formats at the same time means an unnecessary message overhead that we have to stop at some point. That means that a hidden service running 0.1.2.x and a client running 0.2.2.x won't be able to connect; the same applies to hidden services on 0.2.2.x and clients on 0.1.2.x. This is also a reminder that 0.1.2.x is obsolete. End-of-life for 0.1.2.x was announced in February 2009 [0]. There are known security holes in 0.1.2.x that are fixed in later versions. Please upgrade! Best, - --Karsten [0] http://archives.seul.org/or/announce/Feb-2009/msg0.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUSP8ACgkQ0M+WPffBEmXrGwCgz0K1wlUgNZmzbyeQ4CbukbOh TZIAoJ/iNHYpCqESCSuo41gl5/DfEcA9 =bdsr -END PGP SIGNATURE-
Re: Tutorials for providing Hidden Services?
On Thu, Dec 18, 2008 at 06:24:46PM -, 6cnf6c...@sneakemail.com wrote 0.7K bytes in 10 lines about: : I want to provide basic free anonymous blogging services using Tor's hidden services. Are there any tutorials for this, apart from the basic setup information on Torproject.org? More specifically, how can I stop my users from identifying my server? What do I have to pay attention to? There is no tutorial that I know of. Each piece of software has different concerns and configurations to protect both your and your users anonymity. : How can I block connection attempts by Apache using my external network interface, eg. if the users execute scripts that contact external addresses? What information is exposed by environment variables, and how can I stop the user from reading them? For example, can I modify timezone/timestamps to obfuscate my server location? Just some thoughts. Run apache on localhost. Set the system time to UTC. Check the 404 page and such so that it doesn't give out the hostname. Run apache in a jail, etc. Run the jail/vm on a system without a public IP; such that if someone does break apache, they find the IP address is 192.168.1.2 (or some other RFC1918 scheme). : What settings do I have to change to fully remove Apache's IP logging to protect my users? Disable access logging. -- Andrew
Tutorials for providing Hidden Services?
Hi! I want to provide basic free anonymous blogging services using Tor's hidden services. Are there any tutorials for this, apart from the basic setup information on Torproject.org? More specifically, how can I stop my users from identifying my server? What do I have to pay attention to? How can I block connection attempts by Apache using my external network interface, eg. if the users execute scripts that contact external addresses? What information is exposed by environment variables, and how can I stop the user from reading them? For example, can I modify timezone/timestamps to obfuscate my server location? What settings do I have to change to fully remove Apache's IP logging to protect my users? Thanks, Daniel
Re: Tutorials for providing Hidden Services?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 6cnf6c...@sneakemail.com wrote: Hi! I want to provide basic free anonymous blogging services using Tor's hidden services. Are there any tutorials for this, apart from the basic setup information on Torproject.org? More specifically, how can I stop my users from identifying my server? What do I have to pay attention to? How can I block connection attempts by Apache using my external network interface, eg. if the users execute scripts that contact external addresses? What information is exposed by environment variables, and how can I stop the user from reading them? For example, can I modify timezone/timestamps to obfuscate my server location? What settings do I have to change to fully remove Apache's IP logging to protect my users? Thanks, Daniel If you're running a hidden service, you don't have to turn off Apache's logging because it will all look like it's coming from Localhost. You should start a guide on the NoReply wiki or maybe one of the hidden ones. Ringo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJSsCO6pWcWSc5BE4RAsCxAKCHn9uIVIAmd+Y1TLZaY+bI8hT7LQCgxNCG 4hVbEhYrgkaexSmDIC1QWqA= =lz6G -END PGP SIGNATURE-
Future Development on Hidden Services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, as some of you may know, there have been several improvements to hidden services lately. First, hidden services publish their descriptors to a distributed directory [1] consisting of currently 71 nodes. Second, hidden services may require client authorization already during connection establishment to block unauthorized requests as early as possible [2]. Third, hidden service performance has been improved with respect to advertising and accessing hidden services [3,4]. Certainly, there are still things that can (and should) be improved. This is an attempt to compile a good list of future development tasks on hidden services. Comments are most welcome. If there are other things with hidden services that need improvement, please let us know. - --Karsten 1. Further improve performance and reliability - -- In the current NLnet project on speeding up hidden services [3] we found and fixed a lot of performance-related bugs, identified the likely bottlenecks of the protocol, and added the most important performance improvements to the code [4]. But there are still some possible improvements left that require evaluation and possibly coding if they turn out to be useful: a. Descriptor fetches on client side are an issue. Most failed connection establishment occur when trying to fetch the descriptor of a hidden service. We could parallelize this step as well (maybe also in combination with a certain delay to avoid extensive network load), just as we do with client-side requests to introduction points [4]. This might speed things up and lead to better reliability (at the price of increasing the number of requests to the distributed directory). b. The client-side request timeout of 60 seconds could be improved. It doesn't make sense to have a 60-seconds timeout for 5 substeps and stick to it even when realizing that the first substep has already taken 55 seconds. The other 4 steps (that are invisible to the client) simply cannot succeed in that time. This would also improve reliability, because we are otherwise giving up on requests that succeed soon after. c. The INTRODUCE1 cells could be combined with the first BEGIN cell to initialize an application stream. After establishing a 6-hop circuit from client to service, the client still needs to initialize an application stream over it which takes another 6 seconds in the mean. Maybe there is a chance to send the stream initialization message already as part of the introduction request. Or the hidden service could initialize the first stream back to the client. There might be security implications that prevent this, so more thoughts are needed here. d. Adapt the protocol to low-bandwidth environments: The effects of low-bandwidth connections on either accessing or running hidden services has not been investigated so far. Maybe such environments require us to change parameters like timeouts when we realize that our connection is bad. Jörg Lenhard is currently working on measurements using telephone and cell phone connections that hopefully give us some new insights. e. One of the big performance issues is general Tor circuit-building performance. This comes in two pieces: First, extending a circuit in Tor has a nontrivial chance of timing out or failing. Second, extending a circuit in Tor takes too long, both in terms of mean and in terms of variance. These problems are magnified for hidden service use, a) because the path is twice as long, and b) because some components of the path really do need to be made on demand, whereas for normal Tor circuits you make the whole circuit beforehand. So, if this improves for general circuits in Tor, hidden services should inherit these performance gains 'for free'. 2. Improve hidden services with client authorization - Beginning with version 0.2.1.6-alpha, hidden services support client authorization. That means that hidden services can restrict access to a small set of clients and prevent other clients (or introduction points/directory nodes) from establishing a connection. When client authorization is applicable, it reduces the risk of certain attacks on locating hidden servers [6] or denial of service. Once this feature is more tested, people should be told that it exists and how to use it. a. Make client authorization for hidden services easier to use: Domenik Bork has made a start on making Vidalia support configuration of hidden services with client authorization in his GSoC project [7]. His changes will hopefully be merged into Vidalia trunk quite soon. The question is whether people understand the interface, or if this needs improvement. b. Write good howtos for both service operators and clients: First, explain to the service operator what steps are required to add or remove authorization for a given client. Second, help end users understand how
Re: Block hidden services
Am 29.08.2008 um 07:15 schrieb F. Fox: xiando wrote: is it - in analogy to exit policies - possible to block certain (or all) hidden services of using my node as directory or introduction point and to disable rendezvous point functionality for my node? (I understand that I cannot block being a rendezvous point for specific hidden services.) If not, I vote for such a feature. I strongly disagree with your vote for such a feature. There may be anonymity issues involved. Your refusal to have involvement with hidden service introduction may ease the adversarys attempts to locale my hidden service and identify me as the operator. I cannot follow how this shall be possible, can you elaborate this? The exit policies allow me as a tor node operator not to offer connections to certain IPs. In the same way I should have the possibility not to offer services for certain hidden services as long as I can identify them (that is directory and introduction point services). I want to point out, that there are hidden services which are (at least) anonymity issues by their own. At the very least, such a new feature - if introduced - should be opt-in; by default, a node should have the ability to be an introduction or rendezvous point. I'm fine with that. But I think it's not fair to force Tor operators, that want to offer their resources for anonymous access, to automatically support hidden services as well. They are to different services and should be decoupled. So at least an option to switch off hidden service functionality is needed. But I prefer a flexible option like the one above. Regards, Sven -- http://sven.anderson.deBelieve those who are seeking the truth. tel:+49-551-9969285 Doubt those who find it. mobile: +49-179-4939223 (André Gide)
Re: Block hidden services
is it - in analogy to exit policies - possible to block certain (or all) hidden services of using my node as directory or introduction point and to disable rendezvous point functionality for my node? (I understand that I cannot block being a rendezvous point for specific hidden services.) If not, I vote for such a feature. I strongly disagree with your vote for such a feature. There may be anonymity issues involved. Your refusal to have involvement with hidden service introduction may ease the adversarys attempts to locale my hidden service and identify me as the operator. signature.asc Description: This is a digitally signed message part.
Re: Block hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 xiando wrote: is it - in analogy to exit policies - possible to block certain (or all) hidden services of using my node as directory or introduction point and to disable rendezvous point functionality for my node? (I understand that I cannot block being a rendezvous point for specific hidden services.) If not, I vote for such a feature. I strongly disagree with your vote for such a feature. There may be anonymity issues involved. Your refusal to have involvement with hidden service introduction may ease the adversarys attempts to locale my hidden service and identify me as the operator. At the very least, such a new feature - if introduced - should be opt-in; by default, a node should have the ability to be an introduction or rendezvous point. FWIW, it's not possible for a node to differentiate between proxy and hidden-service traffic for relay purposes; this has been discussed before. - -- F. Fox Owner of Tor node kitsune http://fenrisfox.livejournal.com Note 2008/08/19: I lost my old GPG keypair, and have generated a new one. Authenticity can be verified by checking the ContactInfo on kitsune. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBCAAGBQJIt4XeAAoJECxKjnsrYHNHXyIQAKOr2HaP2kVHUb+fmiYxmH8q 7yGLJurxGNLrjZnxph77nFvjEfv1vQsYzGLP0vUiRz84uiTZGhIf5VHhBGwsbxIe c9zExz9AIqNKk3qaIzyr3ojySxrxbblgnpxjf8hGy1QjQB7bfQdv7ND5YXYUapob Bb5uRdnZXyMHRtavXNErkQnF/daYkcm4mCLqVAUqKmIEwzOaM6efIGTw1w4gk0Zu wDpUZIGupDTPES4W7P8P7oX5eojqBS5ihDbit0VE8wB7PFwkFFTIAFrnkS8GRMGr sYQY/pk7RNI9GUF14pMl0lM+D4Y2CpPXsjqETJQAPYXX0Pn++Izb8vXx0iZFmbjV lJJ0v+D49H7U3VbNIOFS8tJ8iTXEoPaIp87wRp3nTgH2CbWW/Q1kStE0kzTsJa8N AlzdzCcmWYTnKRJcm7ndNomnf7YdfmTyGQbRpMrF8mRUDqCf7o8MyJONJVphjLc0 yYWAZgcghQPR5JRcnlpbCPcpi7cWRLdwt8lJ2KctWLROge7Cg4M7s4u4Ezu2SdLi QbW1YHkKm+0d5oHTDX9hTyWdMXw7fHv69Fm4wxEo8xkuG0wJCj0fbnSnKNF4g514 +foJIiFTxdUiazCZ09Po6dFXdL7GKOjcP6aK9DSZ2Fh4Z4SYb7PQzH29YgqkBbUa 5U2kXvSsLTNPjHRYA1KR =xAbI -END PGP SIGNATURE-
locating hidden services
Hi again, Learning about hidden services - what are the methods (if any) for Tor users to locate a hidden service? Is there a way to search for them, get the info from the directory servers, etc? Say for example that I have a web server running as a hidden service and I only want people from a certain group to be able to locate/access that server. Authentication has already been addressed on the server but I don't want users who are not part of that group to bang on my hidden service with a bunch of bogus login requests. In the past, I've used port knocking/SPA to address this issue but I'm not exactly sure how that would work out in a Tor/Hidden Service environment - anyone have any experience along those lines? Any other information or advice? Thanks as always - nD -- Live the good life! Click now for great retirement planning assistance! http://tagline.hushmail.com/fc/Ioyw6h4dQXa9Q3uwL9LU4xK72RWz8nFg7UkzDwSFU923hWGZKosOrH/
First Vidalia Prototype including User Authorization on Hidden Services
Hey list, a few of you may know me from IRC, ohers may not. I'm one of this years Google Summer of Code students. My project is about implementing Vidalia support for Hidden Services with User Authorization, according to the Tor proposal 121-hs-authorization of Karsten Loesing. A Hidden Service is a service that is reachable by a .onion adress, but the IP-Adress of the service provider is hidden. My goal is now to let Vidalia configure those Hidden Services, give a Service provider the possibility to create User Authorization data(.onion adress and a descriptor cookie) for each user he wants to access the service. Additionally there should be the option to store authorization data needed to access other hidden services in Vidalia. So a Service Provider has then the opportunity to create individual authorization data for single users and it would be no problem to exclude users from a service if he wants to let them no longer access the service. As a few of you may have noticed I uploaded the first prototype of my Google Summer of Code Project. This prototype includes the complete functionality explained above with all the communication to/from Tor as well as persistent storage of the configuration. Within this Mail I give you a little How2 for the installation of my Vidalia branch and the correct Tor branch you need to run it with User Authorization. Here starts the little installation help: Tor related: 1)Download the newest version of Karstens Tor branch (svn co https://tor-svn.freehaven.net/svn/tor/branches/121-hs-authorization/) 2)start a terminal and switch into the directory of 121-hs-authorization 3)type in the following command lines 1. ./autogen.sh [Enter] 2. ./configure [Enter] 3. make 4) if everything worked fine there shoul be the Tor binary in /121- hs-authorization/src/or/ Vidalia related: 1)Download the newest branch of my Vidalia branch (svn co https://svn.vidalia-project.net/svn/vidalia/branches/hidden-services) 2)start a terminal and switch into the directory of hidden-services branch 3)type in the following command lines 1. cmake . make [Enter] 4)if everything worked fine there should be a Vidalia binary in hidden- services/src/vidalia/ 5)click on the binary to start Vidalia 6)click on settings and then on „General“ to configure the path to the Tor executable in that way that it points to the 121-hs-authorization version 7)click on „Save“ 8)click on „Stop Tor“ 9)click on „Start Tor“ 10)now the new Tor version should be started and you can start configuring Hidden Services with/without User Authorization etc by clicking on „Settings“ and then „Services“. Possible configurations of Hidden Services: • normal Hidden Service with one single adress for all users • Hidden Service with User Authorization to easily include/exclude single users while the service is still reachable with the „old“ adress by other users who are configured. • Store the Authorization Data you need to access Hidden Services. I would really appreciate it if I can find a few people who are interested in testing it and giving me some feedback or/and bug reports. Remember, this is just the first prototype and there are bugs and things i'm going to change in the next weeks. So this test phase is thought to give some feedback about the look and feel, whether the communication to/from Tor works as it should etc.. GUI stuff. Best regards, - --Domenik PGP.sig Description: This is a digitally signed message part
Re: First Vidalia Prototype including User Authorization on Hidden Services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This looks really cool, thanks for all of your hard work! Comrade Ringo Kamens Domenik Bork wrote: Hey list, a few of you may know me from IRC, ohers may not. I'm one of this years Google Summer of Code students. My project is about implementing Vidalia support for Hidden Services with User Authorization, according to the Tor proposal 121-hs-authorization of Karsten Loesing. A Hidden Service is a service that is reachable by a .onion adress, but the IP-Adress of the service provider is hidden. My goal is now to let Vidalia configure those Hidden Services, give a Service provider the possibility to create User Authorization data(.onion adress and a descriptor cookie) for each user he wants to access the service. Additionally there should be the option to store authorization data needed to access other hidden services in Vidalia. So a Service Provider has then the opportunity to create individual authorization data for single users and it would be no problem to exclude users from a service if he wants to let them no longer access the service. As a few of you may have noticed I uploaded the first prototype of my Google Summer of Code Project. This prototype includes the complete functionality explained above with all the communication to/from Tor as well as persistent storage of the configuration. Within this Mail I give you a little How2 for the installation of my Vidalia branch and the correct Tor branch you need to run it with User Authorization. Here starts the little installation help: Tor related: 1)Download the newest version of Karstens Tor branch (svn co https://tor-svn.freehaven.net/svn/tor/branches/121-hs-authorization/) 2)start a terminal and switch into the directory of 121-hs-authorization 3)type in the following command lines 1. ./autogen.sh [Enter] 2. ./configure [Enter] 3. make 4) if everything worked fine there shoul be the Tor binary in /121-hs-authorization/src/or/ Vidalia related: 1)Download the newest branch of my Vidalia branch (svn co https://svn.vidalia-project.net/svn/vidalia/branches/hidden-services) 2)start a terminal and switch into the directory of hidden-services branch 3)type in the following command lines 1. cmake . make [Enter] 4)if everything worked fine there should be a Vidalia binary in hidden-services/src/vidalia/ 5)click on the binary to start Vidalia 6)click on settings and then on „General“ to configure the path to the Tor executable in that way that it points to the 121-hs-authorization version 7)click on „Save“ 8)click on „Stop Tor“ 9)click on „Start Tor“ 10)now the new Tor version should be started and you can start configuring Hidden Services with/without User Authorization etc by clicking on „Settings“ and then „Services“. Possible configurations of Hidden Services: •normal Hidden Service with one single adress for all users •Hidden Service with User Authorization to easily include/exclude single users while the service is still reachable with the „old“ adress by other users who are configured. •Store the Authorization Data you need to access Hidden Services. I would really appreciate it if I can find a few people who are interested in testing it and giving me some feedback or/and bug reports. Remember, this is just the first prototype and there are bugs and things i'm going to change in the next weeks. So this test phase is thought to give some feedback about the look and feel, whether the communication to/from Tor works as it should etc.. GUI stuff. Best regards, - --Domenik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIcpikmBTzXUpNYqQRAln2AKCSV53gheuM6er7HM1QFOaw+nOx1gCeMwNq 9U0pUtWopElyVKUFrAnmYR8= =JEOa -END PGP SIGNATURE-
Re: ejabberd patch for Jabber S2S over hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I don't know about specifics, but I can tell you from my own casual experimentation, that IM over Tor can work; it will encounter more latency than without an anonymizing layer (of course), but it's generally not too bad. - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSAJ+Qej8TXmm2ggwAQhdYA//a2/upO2Nm6iB+Mu3sUhCyfGfuK41vMed fVgZ79ArR8jfPj4PBuR26sOxRZLLAz0Myg1VZ8ucez3LpglY5vJ6qqD/7ryDdHzm XE6KGfa0oV7ci1JGM8gdXqpHr4h5812r9aNhJ+zOb3TUBw+KLghSrQARx1yBh2D+ WLRWmm5onJi4LcmrmAy+7mKSkptCDnsKAyOk43YKhhu0Mn7n1rPA0T+4E/8GwNsm Mf2FJPFNLHSPs/BehlQ3KYYNYqfO7iUfO+xqMcRhxDrF7hFSgOKXTlQGZ1+jA60A 12qQq2U/+n8ZBvrttU1nbmf9Dg/gpXPJ2hhnMKyoxbbLLSRwfE6FVequEvbqQxEl yzLZ8cqHzGRiiuXStNtA6OexUQ+6poQz7VVFsGEp2ice5j9iPuwaa8K3r5WPY6OD y38farmN7RIRcxGKNWlcgU2ggFBnpvMxQHsXN49FbGkwasIudFkLbWatenFjLWsp VJ4i03UG9RuQJPWJBYmMrGcO0f8JB/fkJXoD2uPK7B8fq01vlqfZQ7hZr9OjJp6c obOJxLGSiAif3BHjes2DF/1Via/6brOl9YncozW0mueYSgYU7r44hYOoqB//wDuo prPZv+NYbFKNSf9MBxICAaXG1KRluEVSU4xBH+Wt7k3X01Gv/tNVmKiwuol689O7 B/q2ixKxfHo= =3Qpk -END PGP SIGNATURE-
ejabberd patch for Jabber S2S over hidden services
Hello, I love playing with Jabber and like the idea of overlay networks. Here[1]'s a patch for the ejabberd-2.0.x branch of ejabberd which lets you run it for a .onion host and make it connect through a SOCKS5 proxy. It is somewhat configurable, ejabberd.cfg.example has it. [1] https://spaceboyz.net/~astro/ejabberd-2.0.x+tor.patch The code is experimental and the main problems are DNS (as usual) and slow connection establishment to hidden services. It is ultimately slow and the S2S handshake timeout had to be increased from 5 to 60 seconds. This does not look very responsive for *Instant* Messaging and it is still timing out most of the time. I'm now asking for further test installations and advise on this ultimate slowness. Do hidden services perform this bad in general? Two testing servers run at: - vbwtqhpr3c5syrbu.onion - 6kgmplpcyjpesalg.onion C2S port is 5222, S2S is 5269 (the patch assumes that) and you may reach me as user 'astro' on both of these Jabber servers. I have some further thoughts on this, but I'd like to wait for any interest here. Stephan -- (Internet) Jabber-Id: [EMAIL PROTECTED]
Hidden Services
Here's a strange question. Let's say I have a hidden service on the onion route. I change machines but still want to use the same address for the service but on the new machine. Is that possible? I imagine no out of the box but that it is probably tied to some PGP machine key to be able to process it so...it is possible but with several steps. Anyone have a clue and suggestions? Thanks, Chris
Re: Hidden Services
Hi Chris, Chris Burge wrote: I change machines but still want to use the same address for the service but on the new machine. Is that possible? Yes, that's no problem as long as you keep the private key file for the hidden service (private_key in HiddenServiceDir). Marco
[Long!] Re: Darknetting and hidden services [Was: Re: virtues of middlemen]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jo wrote: On 01/01/2008, F. Fox [EMAIL PROTECTED] wrote: These are Tor's hidden services: Servers accessible anonymously, where both client and server are unknown to each other. =:o) Since such services are visible only via Tor, they would fall under the darknet definition, I believe. This is what I was getting at ... just didn't say it right :( It's okay. =:o) After all, the hidden service side of things is quite a bit more obscure than the (likely) most common use of Tor - an anonymity layer and inherent outproxy to the normal Web. (About that anonymity layer... Although I've never seen it formally described as such, I could see it being considered as a separate logic layer in the TCP/IP stack, since it is such a general-use TCP conduit. It'd look something like this: * [Application] | [Anonymity] | [Transport] | [Internet] | [Network Access] * Just for kicks...) I have often wondered just how big the network could get, and what impact this has on the Internet. There are many Internet resources that will always be needed - e.g. email will need to be accessible from / routed to Tor; Google, Wikipedia, Universities, etc are not going to be replicated, ... At the moment the rest of the Internet can ignore Tor (except for those who want to block it) but - if big enough - one could imagine the need for ubiquitous gateway services to allow simple (transparent?) access to resources within the network. If it became mainstream and massive, yes. However, I don't have much hope for that, if history is a guide for the most likely development of the future [1]. Such a ubiquitous deployment will most likely (though sadly) remain the wet dream of hackers, civil libertarians, crypto-anarchists, and cipherpunks. The network has - though far from ubiquitous - grown quite a bit over the few years. Around 2005, the paper Low-Cost Traffic Analysis of Tor[2] mentioned there being around 50 Tor nodes; IIRC, that's mushroomed to around 1,600. (I suppose that such a mushrooming effect could cause someone to look Tor through another historical POV, though - that of the Internet itself. It did something similar... =:oD ) [1]: This is one reason why I try to study as much history as I can, BTW; many mistakes are made in the present, which could have been avoided if the one who made them had learned about certain aspects of the past. [2]: http://www.cl.cam.ac.uk/users/sjm217/papers/oakland05torta.pdf Of course it has to get big enough first. PGP is still struggling (I don't even have a signing key for this email address) and services such as Usenet which were huge in their time are now rapidly being replaced. (This one really irks me - a fantastic idea with some basic privacy elements built in, being replaced by lesser technologies). SSL, OTOH, has become pretty much mainstream and is still developing ... the challenge to be able to grow Tor will be to do the same - make it mainstream. True, it's a shame some of these things aren't more mainstream. That thing about Usenet also strikes a chord with me; when a technology with many years of history behind it ends up circling the drain, it's just sad. Old doesn't always mean inferior, or even obsolete/superceded; a good example are the Unices, which started way back in the 1970s (IIRC). Sure, things have changed a lot since then, but the basic model is still there. The core of the Net runs on it (and if more of the users did, we might not have half the bedlam going on right now! =xoD ). Of course to become mainstream it needs to be REAL easy. And if Tor gets to the point where it is so simple that you don't really need to understand it, there is a distinct possibility that many of the benefits may no longer be realised (how do you know you've got a secure, private connection if you don't understand WHY it is secure and private - particularly what *isn't* provided). (snip) This is one reason why malicious Tor exit nodes and scripts/applets/etc. on servers have had such success in de-masking Tor users - it's not a silver bullet. Users have to configure their applications carefully, as well as be careful what they let pass through Tor (either explicitly entered, or implicitly leaked). As it stands right now, Tor is for people who have a decent knowledge of how to secure themselves - and I don't see that changing anytime soon. I'm glad to see the warnings that have been put on the front page of the Tor Project site - but the fact remains, sheep will be sheep. Not everyone will pay attention to it - and they very well could suffer the consequences. (Amazingly, a lot of the sheep they found, I would think belong in the wolf category! =xoD ) The exits and servers I mentioned previously were those I read about as proof-of-concept - but most of them are so feasible (requiring so little effort), that a teenager could probably do
Darknetting and hidden services [Was: Re: virtues of middlemen]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jo wrote: (snip) There were/are some sites which I think you could only see from Tor - Secret Diary, forums, file sharing ... a quick scan of core.onion show some more that may exist only inside the network. (snip) These are Tor's hidden services: Servers accessible anonymously, where both client and server are unknown to each other. =:o) Since such services are visible only via Tor, they would fall under the darknet definition, I believe. - -- F. Fox: A+, Network+, Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHeaIrbgkxCAzYBCMRCB09AJ40P0f1rDF3gnNZhfHj4mvE4i1ytQCgiBA/ qOAiuEg9Buh7+KmzCPrDSMw= =r172 -END PGP SIGNATURE-
Re: question about A/B communication with dir servers for hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Are the streams from Bob and Alice to put get the descriptor of a hidden service always established over Tor circuits Yes, they are. or sometimes direct streams from the OP's to the Tor directory server? No, never. In other words: Is it assured, that the directory server doesn't know, that Bob has established a hidden service and Alice has asked about it? Correct, the directory server never learns about the IP addresses of the service provider and its clients. - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGX9em0M+WPffBEmURAqJaAJ41JL/Vba+WIC2l5Y1oIiNbjGUHrACgvfrn TQPzLmLsOE0ihY2oPwFPjYY= =aGRk -END PGP SIGNATURE-
question about A/B communication with dir servers for hidden services
Hi, i have read in the rend-spec.txt: Bob's OP opens a stream to each directory server's directory port via Tor. (He may re-use old circuits for this.) Over this stream, Bob's OP makes an HTTP POST' request, to a URL /tor/rendezvous/publish relative to the directory server's root, containing as its body Bob's service descriptor. Alice opens a stream to a directory server via Tor, and makes an HTTP GET request for the document '/tor/rendezvous/z' (...) (She may re-use old circuits for this.) and have one question for understanding: Are the streams from Bob and Alice to put get the descriptor of a hidden service always established over Tor circuits or sometimes direct streams from the OP's to the Tor directory server? In other words: Is it assured, that the directory server doesn't know, that Bob has established a hidden service and Alice has asked about it? -- Ciao Kai Homepage: http://hp.kairaven.de/ Weblog: http://blog.kairaven.de/
Re: a solution on the horizon to counteract detecting temperature through clock skew (on Tor Hidden Services)?
On 5/14/07, Wes Felter [EMAIL PROTECTED] wrote: ... Power analysis is not the same thing as temperature-induced clock skew. i've wondered about using a frequent ntpdate to reduce skew, and if that is not sufficient, what about a modified client that uses adjtime() or settimeofday() with random offsets (+/- within some tolerance) to gently randomize on a few minute schedule? is there a public tool to analyze clock skew like that mentioned in the attacks to determine if such workarounds are effective? best regards,
Re: Hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi JT, I read the docs and slides on hidden services. But I still don't quite get it. Maybe I can help you with this. On slide 19 it looks as if there was only one hop between the client and the server. Is this the case or has the diagram been simplified? All connections to introduction and rendezvous points are sender-anonymous. This is depicted by the big onions on the slides. These connections consist of more than one hop just as with circuits to public servers. The standard hop count for each sender-anonymous connection is 3. If only client and server are for real and the all tor servers along the path are compromised then can the operator find out what the hidden service is offering and who is communicating. Well, if _all_ Tor servers in the path from a client to a hidden server were compromised, they could find out that the two are communicating. Communication between the two is still end-to-end encrypted from the client's to the server's Tor node. But the adversaries could make an own attempt to connect to the hidden server and find out what it is offering. Anyway, we are talking about at least 6 routers of which 3 are picked by the client and 3 by the hidden service. So, it's not so likely that they are all compromised. In fact, this is what Tor relies on. I think, you should not be too nervous about that kind of attack. Inside the Tor network(not using exits) everything is encrypted, right?! So does the last node in the path, connected to the hidden service know, that it is talking to a hidden service? As far as I understand hidden services can be run by servers and clients. The last node in the circuit, which is closest to the hidden server, does not know that it is talking to the hidden service. The hidden server opened a circuit to that router as done with every other circuit. So, this router cannot conclude what the hidden server is doing. It could also be - which is more likely - a usual client. If you are more interested in attacks on this, you might want to read the paper by Øverlier and Syverson on locating hidden servers. Hope this helps. Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGA5qm0M+WPffBEmURAnRiAKCi0SCx4kD7nqh/7Y1zAFtFOZO7BgCffIMP UpT0Vm7Bs7OUu9wn1UDsMCc= =9Lkd -END PGP SIGNATURE-
Re: Talks of hidden services and DNS
As I understand it (correct me if I am wrong -- I am very new), the .onion TLDs are built up from two hexadecimal parts, so they are cannot be something that is easy to remember (such as hiddenwiki.onion). It is explained here: http://wiki.noreply.org/noreply/TheOnionRouter/HiddenServiceNames + The reason for using cryptic fingerprints instead of human-readable names is described in [WWW] Zooko's Distnames: they are self-authenticating. If a client wants to connect to a hidden service he asks the directory services for the .onion name's service descriptor which includes its public key. If the hash of the public key matches the .onion name, the client can be sure it will encrypt data for the right hidden service. Zooko's Triangle which is discussed in Stiegler's [WWW] Petname Systems argues that names cannot be global, secure, and memorable at the same time. This means while being unique and secure, .onion names have the disadvantage that they cannot be not meaningful to humans. Links: http://zooko.com/distnames.html http://www.skyhunter.com/marcs/petnames/IntroPetNames.html + A naming system introduces costs and reduces benefits gained from the current system - and it doesn't offer much in return. I could rehash all the old argument, but it's already explained so well in the links above... And yeah, a naming-schema/translator existed at one point (and there's nothing to stop anybody from offering such a system), but IIRC it was not exactly wildly popular. Regards herfel -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
Talks of hidden services and DNS
Hello everybody, I am new to this list (and Tor in general), but I have been wanting to contribute for awhile. As I understand it (correct me if I am wrong -- I am very new), the .onion TLDs are built up from two hexadecimal parts, so they are cannot be something that is easy to remember (such as hiddenwiki.onion). I am wondering whether there have been any talks of running a DNS system (outside of Tor) that would convert something like .hidden TLDs into .onion. This would allow server administrators to pick domains that make sense, and would allow publishing things as hidden services to become more broadly used. It would not have to run inside of Tor, but would have to be accessible to Tor. I think most of the current tools for DNS (BIND and such) would work relatively well, and might require only a few hacks (we could even have everything just be CNAMEs instead of A records). Am I missing something big? I think this would make running hidden services much easier if Tor gets larger -- and they will be much more enticing to use for the Tor users. -- Kasimir Gabert
Re: Talks of hidden services and DNS
There already was a service like this within tor called... well I forget the name. The problem with such a system outside tor is they they could be ordered to remove DNS entries and then it would censor those onion sites. Does anybody remember the name of that program? Ringo Kamens On 3/11/07, Kasimir Gabert [EMAIL PROTECTED] wrote: Hello everybody, I am new to this list (and Tor in general), but I have been wanting to contribute for awhile. As I understand it (correct me if I am wrong -- I am very new), the .onion TLDs are built up from two hexadecimal parts, so they are cannot be something that is easy to remember (such as hiddenwiki.onion). I am wondering whether there have been any talks of running a DNS system (outside of Tor) that would convert something like .hidden TLDs into .onion. This would allow server administrators to pick domains that make sense, and would allow publishing things as hidden services to become more broadly used. It would not have to run inside of Tor, but would have to be accessible to Tor. I think most of the current tools for DNS (BIND and such) would work relatively well, and might require only a few hacks (we could even have everything just be CNAMEs instead of A records). Am I missing something big? I think this would make running hidden services much easier if Tor gets larger -- and they will be much more enticing to use for the Tor users. -- Kasimir Gabert
Re: Talks of hidden services and DNS
The tricky part will be deciding who is authoritative for the DNS records. If any user can submit a name, what if its already taken? Does it overwrite, or is it first-come, first-serve? If its distributed, then a rogue operator could serve false responses for a target name. If this is something that the tor core would operate, it still needs some form of authentication to manage/update/remove/etc and authentication seems to be the exact opposite of what tor is supposed to provide. -HD On Sunday 11 March 2007 21:10, Kasimir Gabert wrote: I do not see any major security holes that this would bring up. It seems to me like it would be the same as accessing google.com through Tor -- the DNS is looked up through Tor and so it would not be overridden by a malicious ISP or country.
Re: flooding attacks to discover hidden services
On 02.01.2007, at 09:34, Paul Syverson wrote: On Mon, Jan 01, 2007 at 06:22:52PM +, Steven Murdoch wrote: On Tue, Jan 02, 2007 at 01:39:05AM +1100, Wikileaks wrote: Open an onion connection to the hidden service, asking for echos. Now flood each router. If the ping is overly delayed, the router is on the hidden path. This is a special case of the attack described in 5.2 of [1]. Then it seems a further recommendation for hidden server operations is to manually specify guard nodes from a set of high traffic nodes. Lucky.
flooding attacks to discover hidden services
Does the public nature of tor routers makes hidden services vulnerable to discovery using flooding attacks? Open an onion connection to the hidden service, asking for echos. Now flood each router. If the ping is overly delayed, the router is on the hidden path. Since the rendezvous node is known and the other nodes vary over time, this will eventually reveal the entry node.
Re: flooding attacks to discover hidden services
On Tue, Jan 02, 2007 at 01:39:05AM +1100, Wikileaks wrote: Does the public nature of tor routers makes hidden services vulnerable to discovery using flooding attacks? Open an onion connection to the hidden service, asking for echos. Now flood each router. If the ping is overly delayed, the router is on the hidden path. Since the rendezvous node is known and the other nodes vary over time, this will eventually reveal the entry node. You've roughly described the attacks we carried out that are described in Locating Hidden Servers. Hidden servers and Tor clients in general are much less vulnerable to this since the introduction of entry guards about a year ago. See http://www.onion-router.net/Publications.html#locating-hidden-servers also to counter flooding to introduction points and related issues http://www.onion-router.net/Publications.html#valet-services HTH, Paul -- Paul Syverson () ascii ribbon campaign Contact info at http://www.syverson.org/ /\ against html e-mail
Re: flooding attacks to discover hidden services
On Tue, Jan 02, 2007 at 01:39:05AM +1100, Wikileaks wrote: Open an onion connection to the hidden service, asking for echos. Now flood each router. If the ping is overly delayed, the router is on the hidden path. This is a special case of the attack described in 5.2 of [1]. If we assume that the hidden service is on a Tor server then the nodes which will show positive correlation will the the hidden service and the guard node. If the guard nodes are stable then this gives the hidden service some protection. If the hidden service is not on a Tor server, and there is no other way for the attacker to build a list of candidates to ping, then the attack becomes a lot harder. Furthermore, there is no reason the hidden server needs to respond to pings, or even have a public IP address. Tor only requires that the hidden service be able to make outgoing TCP connections. Hosting the hidden service on a Tor node gives some plausible deniability, but opens up attacks like the one you describe. Thanks, Steven. [1] http://www.cl.cam.ac.uk/~sjm217/papers/oakland05torta.pdf -- w: http://www.cl.cam.ac.uk/users/sjm217/ pgpoNTU5q7e6S.pgp Description: PGP signature
Re: flooding attacks to discover hidden services
On Mon, Jan 01, 2007 at 06:22:52PM +, Steven Murdoch wrote: On Tue, Jan 02, 2007 at 01:39:05AM +1100, Wikileaks wrote: Open an onion connection to the hidden service, asking for echos. Now flood each router. If the ping is overly delayed, the router is on the hidden path. This is a special case of the attack described in 5.2 of [1]. Right. I was misreading you at first as repeatedly flooding requests to the hidden server and having hostile Tor nodes detect when they are on the path. I think though what you ask is much closer to the attack described in Steven's paper than to the attack in the paper I cited. He has already noted the main pros and cons of how the hidden server is configured (wrt the Tor network) and how it behaves wrt this attack. A further note is that the attack in Steven and George's paper was successful when the Tor network consisted of about 35 nodes and for routes consisting of relatively low bandwidth nodes. It is an interesting open question if something comparable could scale up to the current network. In principle it should, but I suspect the engineering of it would be much harder and would involve synching many attack-flooding clients. It might cause other problems for the Tor network before it succeeds in general, if it can at all. But, it could also be interesting to see if this succeeds substantially more often than roughly c^2/n^2 because the perecentage of attackable paths has some nice properties (from the attacker's perspective). aloha, Paul
Re: flooding attacks to discover hidden services
If the hidden service is not on a Tor server, and there is no other way for the attacker to build a list of candidates to ping, then the attack becomes a lot harder. Yes, this is what we observed too; but found nothing about this in the FAQ on hidden services and the default tor config is not set up to permit this configuration without hackery. Likewise [not in reference to hidden servers], it is better for Tor to use a different outbound address to inbound, since the ORport addresses are published globally by Dirservers. Also not mentioned to my knowledge. Lucky.
Re: hidden services spoof
On Mon, Sep 11, 2006 at 04:10:27PM -0500, Arrakistor wrote: I am writing an updater for tor to automatically grab the latest version. One problem I am coming across is where to host it so they cannot be spoofed. I was thinking of putting it at a server in a .onion address. How easily can a node in the tor network be spoofed? Is there a better solution than hosting the tor updates inside a .onion server? Checking the PGP signature on the release should be enough to detect fake updates. (You've been checking PGP signatures already, right?) -- Nick Mathewson pgp7LjOpZo7l2.pgp Description: PGP signature
Re[2]: hidden services spoof
Nick, Yes but the sig is only as good as the person you trust. That is why I haven't released Torpark 2.0b2 with 0.1.2.1-a, I simply don't have a trusted binary. I don't think they yet have a pgp plugin for NSIS language yet. I'll see what else can be done for verifying sigs. Regards, Arrakistor Monday, September 11, 2006, 4:49:26 PM, you wrote: On Mon, Sep 11, 2006 at 04:10:27PM -0500, Arrakistor wrote: I am writing an updater for tor to automatically grab the latest version. One problem I am coming across is where to host it so they cannot be spoofed. I was thinking of putting it at a server in a .onion address. How easily can a node in the tor network be spoofed? Is there a better solution than hosting the tor updates inside a .onion server? Checking the PGP signature on the release should be enough to detect fake updates. (You've been checking PGP signatures already, right?)
Re: hidden services spoof
Arrakistor wrote: Nick, Yes but the sig is only as good as the person you trust. That is why I haven't released Torpark 2.0b2 with 0.1.2.1-a, I simply don't have a trusted binary. I don't think they yet have a pgp plugin for NSIS language yet. I'll see what else can be done for verifying sigs. You're not going to get a better way to validate trust than a pgp signature. If you don't trust the tor signing release keys, you shouldn't trust the code they're signing. Some random .onion address given over a mailing list isn't a secure way to verify anything. Someone can compromise the server on the other end of the .onion address. It sounds like you're building an automatic updater for your system. I suspect that you should be very careful as you're introducing a method for automatically downloading binaries and potentially running untrusted code. You need to verify the pgp signature of builds just as you would source code before building. At the cost of repeating what Nick said, you're verifying pgp signatures already already, right? Something, Jacob Appelbaum
Re[2]: hidden services spoof
Yes, I am building an updater. If phobos finishes the manual on how to get it to compile under mingw, I will compile, sign, and release them myself. And yes, I am verifying the sigs I use in the release. Regards, Arrakistor Monday, September 11, 2006, 6:27:38 PM, you wrote: Arrakistor wrote: Nick, Yes but the sig is only as good as the person you trust. That is why I haven't released Torpark 2.0b2 with 0.1.2.1-a, I simply don't have a trusted binary. I don't think they yet have a pgp plugin for NSIS language yet. I'll see what else can be done for verifying sigs. You're not going to get a better way to validate trust than a pgp signature. If you don't trust the tor signing release keys, you shouldn't trust the code they're signing. Some random .onion address given over a mailing list isn't a secure way to verify anything. Someone can compromise the server on the other end of the .onion address. It sounds like you're building an automatic updater for your system. I suspect that you should be very careful as you're introducing a method for automatically downloading binaries and potentially running untrusted code. You need to verify the pgp signature of builds just as you would source code before building. At the cost of repeating what Nick said, you're verifying pgp signatures already already, right? Something, Jacob Appelbaum
Re: Tor server question regarding hidden services.
On Fri, 08 Sep 2006 00:45:40 -0700 Caitlin [EMAIL PROTECTED] wrote: Hi. I just finished enabling a hidden service on my Tor server but I felt compelled to ask a few questions. 1). In order to run a hidden service, does one have to set-up a Tor server with an exit node? If so, would I have to use the rule: accept * 80 ...(?) Thanks, Caitlin Be who you are and say what you feel because those who mind don't matter and those who matter don't mind. - Dr. Seuss, Oh the Places You'll Go __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Hi Caitlin, Someone correct me if I'm wrong, but I'm fairly sure the answer to your question is No. You should not need to configure your server to exit on port 80 in order to run a hidden service. In any case, this should be fairly easy to test. Once you have your hidden service configured, set your server to NOT exit to port 80, and then try to access your hidden service through the Tor network. Hope that helps. Best regards, Joe
Re: Tor server question regarding hidden services.
You do not need to run an exit node to run a hidden service. -Jon
Re: Tor server question regarding hidden services.
On Fri, Sep 08, 2006 at 11:54:54AM -0400, Jonathan D. Proulx wrote: You do not need to run an exit node to run a hidden service. Just to be complete: you do not need to run a Tor node at all to run a hidden service. Your hidden server can just be a client as far as the Tor network is concerned. -Paul -- Paul Syverson () ascii ribbon campaign Contact info at http://www.syverson.org/ /\ against html e-mail
Revealing tor hidden services by their clock skew
http://www.lightbluetouchpaper.org/2006/09/04/hot-or-not-revealing-hidden-services-by-their-clock-skew/ This is on the front page of reddit.com right now, so it should get some attention. Murdoch's paper is here: http://www.cl.cam.ac.uk/~sjm217/papers/ccs06hotornot.pdf
