tor-onions

tor-onions@lists.torproject.org

157 discussions

Hidden Service IP Addresses
by phiaslai＠nonkly.com 03 Jul '16

03 Jul '16

Can a hidden service expose it's IP address? Can I run a hidden service from a server that has DNS pointing to it for a domain? Can I run a hidden service from the same server as a tor relay (which openly exposes the IP address)?

7 7

Criteria for intro point, rendezvous point selection?
by Paul Syverson 18 Jun '16

18 Jun '16

We were trying to figure out some criteria for selecting intro points and rendezous points as well as circuits to connect to them and had some questions we couldn't determine from our poking around for answers. Does anyone know for current stable code (and, e.g., post 224 etc. if any of this is expected to change) the following? Are guards ever selected for intro points? Are exits ever selected for intro points? Are guards ever selected for rendezous points? Are exits ever selected for rendezvous points? Are client circuits to intro points selected from prebuilt circuits? If so, is the third hop an exit relay? Or is a prebuilt circuit cannibalized in some way to avoid using an exit? Are client circuits to rendezvous points selected from prebuilt circuits? If so, is the third hop an exit relay? Or is a prebuilt circuit cannibalized in some way to avoid using an exit? Fuller answers (e.g., 'Yes. guards can be selected as intro points, but only in accord with their chance of being selected as a middle relay.') and/or where to find these in documentation appreciated. If someone knowledgeable feels this is better directed at tor-dev, please let me know (or simply reply there rather than here). aloha, Paul

2 1

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 19 Apr '16

19 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 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

tor-onions