- tor-onions - lists.torproject.org

domain socket as HiddenServicePort target -- permissions!?
by Johannes 16 Jun '16

16 Jun '16

Hello gents, I'd like to use a unix domain socket as HiddenServicePort target so I can remove networking capabilities from my hidden service's server process. Tor does not connect to my socket, though. Tor's debug level logging does not show any (comprehensible) errors. This is very frustrating to debug! Because of the documentation of unix domain sockets in *other* parts of Tor, like ControlPort, SocksPort et. al., I suspect it is about permissions. How *exactly* are the requirements of ownership and permissions of the socket and its directory and why? This is totally under-documented! I've tried to look at the sources (https://trac.torproject.org/projects/tor/ticket/11485) but I could not make much sense of it. I've manage to somehow create a socket that worked, but firstly there are so many variables so for the love of gods I was not able reproduce it and secondly as far as I can recall that were perms that required elevated privileges to get them set, which is totally out of the question for production. I'd like to elaborate more on what did work, but I am truly lost! Version: Tor 0.2.7.6 (git-605ae665009853bd) TIA, Johannes

3 5

nunca tube asceso a nada
by jesús gonzález 09 May '16

09 May '16

no tube enlace

2 1

Tor, HS, Library
by cippalippa 08 May '16

08 May '16

Dear folks, we'll have the opportunity to talk and leverage HS/Tor at one of the most ancient University & Library in Europe. We'd propose to start something like "libraryfreedomproject.org" use to do in US but with a special focus on Onion Services. I'd ask to you if you'd share your list of case histories about using Websites & Hidden Services in the Facebook way, bloggers, artists and so on. But by common entity (persons or company), not by crypto movements or real anonymous HS. Cases of websites who think Tor users like an important audience for their contents and/or services. That's why I supposed the ML tor-onions could be the right starting point. I'll appreciate any feedback in contributing sharing cases of HS like these. If you prefer, or don't want to spam the ML, you'd reach me directly. I'll release the case histories list hoping it'd be useful for others too. Just to say, we experimented lots of HS on related projects. By example one on many, last year we shared content data/social mining on HS about the International Festival of Journalism '15. Knowing guest's contents could be censored somewhere. And it happened on the clearnet, mainly by far-east, so this year we opened an HS to permit access to the entire Festival's contents b/c lots more guests were coming from censored countries. Thank you for your time and patience in reading this, [TW] @Gilda35

4 3

Hidden datagram service
by Olof Tangrot 25 Apr '16

25 Apr '16

>But why not just use TCP in the first place? Why limit services to the most bandwidth consuming kinds of sockets? Olof

4 4

Hidden datagram service
by Olof Tangrot 18 Apr '16

18 Apr '16

Hi. I am playing with the possibility to send datagrams to a hidden host from an anonymous client. But with some problems. Is it possible at all or is the encrypted tunnels designed for streams only? Using the hidden ssh-service a program called connect/connect-proxy seem to be involved on the connecting machine (over SOCKS5). Would 'connect' be possible to use to send route the datagrams from the talker program to the .onion host? Olof

2 1

Best webserver for a personal onion site?
by Alec Muffett 15 Apr '16

15 Apr '16

Apache? Nginx? Lighttpd? Thttpd? Other? What's the most bombproof / least likely to get misconfigured? -- http://dropsafe.crypticide.com/aboutalecm

5 4

avant - tar for onions
by Ivan Markin 11 Apr '16

11 Apr '16

Hello all, I've released a small tool called `avant`[1]. Basically it's a tiny sibling of the OnionBalance[2] written in Go and is in public domain. I made it because Python is too heavy and messy for my little setup and I need just one binary that does only one simple thing. As with the OnionBalance one can: * Perform load balancing * Keep long-term private keys outside dangerous zone * "Rename" already running onion services It can be called in a way similar to `tar`: $ avant frontonionklew8 backonionl3yfkxk backonionfmakgtd ... At the moment you can: o Select to which replicas you want upload your descriptor(s) [-replica-mask 101010] o Make distinct descriptors to fit up to 10x6=60 introduction points [-distinct-descs] o Publish descriptors to files [-save-to-files] Note that this is not a stable release. If you want to make it better/simpler you're always welcome to send me patches. I hope it can be useful. P.S. Golang doesn't seem to be able to fetch git repos over the .onions so you have to clone it yourself into your GOPATH (e.g. using torsocks). -- [1] http://hartwellnogoegst.onion/avant [2] https://github.com/DonnchaC/onionbalance -- Depends on Yawning's Tor control library `bulb` [3] and my written-on-purpose libs: `onionutil` [4] for parsing/utils and `keycity` [5] for key management (only PEM private keys atm). [3] https://github.com/Yawning/bulb [4] http://hartwellnogoegst.onion/onionutil [5] http://hartwellnogoegst.onion/keycity -- Sweet onions, Ivan Markin

1 0

Re: [tor-onions] Renaming Rendezvous Single Onion Services
by Tim Wilson-Brown - teor 29 Mar '16

29 Mar '16

Hi Kate, Aaron and others currently favour "open onion services". What do you think? Tim > On 28 Feb 2016, at 18:30, Tim Wilson-Brown - teor <teor2345(a)gmail.com> wrote: > > Hi Kate, > > As we talked about at your press session, can you help us name a new "Hidden Service" variant? > > If we call the overall feature "Onion Services", we need to come up with names for a new variant: > * "Single" Onion Services: a service where the client is anonymous and the server is not (like Facebook) > > We already have: > * "Hidden" Onion Services: a service where the client and server are anonymous (like SecureDrop) > > We might also want names for two different implementations of "Single" Onion Services: > * "Rendezvous" Single Onion Services: a service where the server only makes connections out, so it can be behind a NAT > * "Extend" Single Onion Services: a service that opens a port that Tor clients can connect to via Tor > But that's not as important, as it's very likely that we'll only end up with one of these alternate implementations in a tor release. > > I've forwarded part of a tor-onions mailing list discussion below. > > Tim > >> Begin forwarded message: >> >> From: Alec Muffett <alec.muffett(a)gmail.com <mailto:alec.muffett@gmail.com>> >> Subject: Re: [tor-onions] Renaming Rendezvous Single Onion Services >> Date: 25 February 2016 at 14:17:00 GMT+1 >> To: tor-onions(a)lists.torproject.org <mailto:tor-onions@lists.torproject.org> >> Reply-To: tor-onions(a)lists.torproject.org <mailto:tor-onions@lists.torproject.org> >> >> >> If we do end up choosing a feature-based name, I think we could start with a base name like: >> (With credit to a thesaurus antonyms section...) >> * Visible Service >> * Obvious Service >> * Overt Service >> * Open Service >> * Revealed Service >> * Known Service >> >> Then we could add "Onion" to distinguish Tor services when necessary in context. >> >> We can also add: >> * "Rendezvous", or >> * "Extend" / "(OR)Port" to distinguish between the different onion services. >> >> >> I'd suggest that the general goal is to convey the value proposition and avoid abstract or ambiguous terms that require further explanation. Running through the list of suggestions: >> visible: begs the question "to whom?" and whether a traditional HS is not "visible" >> >> obvious: not bad, but begs grammarians to criticise it >> >> overt: i like this; I like "flagrant" too. both of them speak to the concept that this is the complement of a "hidden" service >> >> open: very good, traditional, positive word, but with overloaded meaning (the open service is closed for maintenance) >> >> revealed: not bad, but grammar again. "overt" is better. >> >> known: same criticism as "visible"; if you're shooting for this you might want to consider "attested" instead? >> >> -a >> >> >> >> _______________________________________________ >> tor-onions mailing list >> tor-onions(a)lists.torproject.org <mailto:tor-onions@lists.torproject.org> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > > teor at blah dot im > OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F > Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

8 10

Re: [tor-onions] Renaming Rendezvous Single Onion Services
by Aaron Johnson 29 Mar '16

29 Mar '16

Hello onioneers, We’ve had several naming discussions for single onion services at this point. They started out as “encrypted services”, then they shifted to “direct onion services”, and most recently “single onion services” seems to be winning. I have been collecting all the suggested names at <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Termino… <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Termino…>>. I have added all terms in this discussion to that wiki page. That page also includes other suggested terminology name changes for onion services. The broader “hidden”->”onion” shift seems to have been successful since this was first created, so that’s encouraging! It does seem that everybody still isn’t satisfied with “single onion services”, though. A couple of points I would make: 1. I think it’s really useful to keep “onion services” as a broad term that includes all onion flavors, including hidden, single, etc. 2. I think the “rendezvous” adjective is not going to be used outside of discussions by developers. Therefore we need not worry about how ugly or confusing the qualifier “rendezvous" is, and we should feel free to attach it when necessary to make the distinction in our technical documents and discussions. At most, in my opinion, enabling rendezvous for single onion services will be a minor configuration option to be considered when setting up your single onion service. Probably, in my opinion, the non-rendezvous variety of single onion services will never get implemented, because the performance cost of including the rendezvous is incredibly minor, while (i) the cost of splitting the anonymity set of services even further is *not* minor, and *(ii) the advantage of enabling NAT-punching is widely useful. > open: very good, traditional, positive word, but with overloaded meaning For what it’s worth, I like “open onion services” for the reasons Alec stated. “Known” and “overt” seem fine to me, but I like the sound and connotation of “open” better. Best, Aaron

7 9

Technical Issues Studying TOR
by Vikas Singh 28 Mar '16

28 Mar '16

Hello sir, I'm presenting a seminar in my college on the DARK NET I was studying the TOR RELAY, while going through it, a question came into my mind, that the destination computer knows the IP of the last node of the relay, so, if the destination is under surveillane, whether the last node will be uner threat and the traffic analyzers can backtrack the relay as they know the address of the last node... I'm vigorously waiting for your reply..

1 0