- tor-onions - lists.torproject.org

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 30 Mar '16

30 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 30 Mar '16

30 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

Confirmations
by jesús gonzález 13 Mar '16

13 Mar '16

Mi email is jesuma03(a)gmail.com

1 0

Re: [tor-onions] Exit Enclaves 2.0 ?
by karsten.n＠secure.mailbox.org 08 Mar '16

08 Mar '16

Moritz Bartl wrote: > I was wondering the same when I saw the instructions published by mailbox.org last week: > They operate an exit relay, and suggest to use MapAddress statements and > the exit notation to use heir exit for *.mailbox.org. I didn't see this > previously, and they also don't explicitly enable exit notation, so I > wondered if that actually works. It works. You have to enable exit notation only, if you want to enter it in the URL bar of the browser. MapAddresses with exit notation defined in torrc are working with default settings. grarpamp wrote: > Using the 'router <nickname>' in '.exit' or 'mapaddress' notation is > nondeterministic... anyone can poof a relay with the same name.... Yes - you are right. I changed the German tutorials at https://support.mailbox.org/knowledge-base/articles/tor-service and replaced the name with fingerprint of the Tor node. But have a look at Tor docs: https://www.torproject.org/docs/tor-manual.html.en > For example, if you always want connections to www.example.com to exit > via torserver (where torserver is the nickname of the server), use > "MapAddress www.example.com www.example.com.torserver.exit". It is not suggested, that fingerprints are possible and more secure. May be, somebody can update the Tor docs too. grarpamp wrote: > Follow this autoresponder if you want... Thank you for you advice to the discussion here. I closed the ticket because we can discuss it here directly and it is not required to include the first-level support of mailbox.org. I will do the recommended steps. I will try to learn... ;-) Greetings Karsten N.

7 10

Renaming Rendezvous Single Onion Services
by Tim Wilson-Brown - teor 25 Feb '16

25 Feb '16

Hi all, It looks like Rendezvous Single Onion Services may not make it into tor before the 0.2.8 code freeze in a few days' time. One of the blocking issues is that it needs to be renamed. Nick said on IRC: "RSOS is not really intelligible in the same way that Hidden Service was." "I want to make really sure that nobody configures this without realizing it's not anonymous" Does anyone have any suggestions? I'm out of names (and soon to start travel). Tim

7 12

HTTP GZIP Compression remote date and time leak
by Jose Carlos Norte 22 Feb '16

22 Feb '16

The gzip compression format used by HTTP if accepted by both server and client, under certain configurations, provides the date of the server that compressed the HTTP Response. This information can be used by a third party to know the time zone where the onion site is hosted. I have written a more in depth explanation about the topic at: http://jcarlosnorte.com/security/2016/02/21/date-leak-gzip-tor.html A proof of concept is included, to check if your service is leaking this information through the gzip headers of a compressed HTTP Response. I have decided to share this because is not an obvious miss-configuration that could lead to the leak of information about the physical position of your hidden service. Be careful. Of course, just knowing the timezone of your hidden service server is not enough to know your identity, or your exact server location, but combined with another leaks or other pieces of information, could be dangerous.

3 3

Should the user be allowed to specify FQDNs for HS TARGETs?
by David Goulet 13 Feb '16

13 Feb '16

Hi everyone! So we have this pending feature ticket here that we would like to know if people here do use FQDN? https://trac.torproject.org/projects/tor/ticket/18037 Currently, consensus seems to lean towards _not_ allowing it. Thoughts? Thanks! David

2 1