tor-onions

tor-onions@lists.torproject.org

157 discussions

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

Exit Enclaves 2.0 ?
by Fabio Pietrosanti (naif) - lists 11 Feb '16

11 Feb '16

Years ago there where the so called "Exit Enclaves" https://trac.torproject.org/projects/tor/wiki/doc/ExitEnclave but those where abandoned. That approach was quite cool, because the end-users would had been able to just avoid using onion addresses, but keep using internet addresses having the very same security properties. It would be very nice to restore the exit-enclaves concept, reshaping it in this new context, so that end-users on Tor Browser could just hist www.website.com and, if that website support Tor, his traffic will go directly to him as an Exit node. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi

4 4

Re: [tor-onions] Protect against ddos in tor
by Ann O'Nymous 10 Feb '16

10 Feb '16

Ron Risley: > >> On Jan 27, 2016, at 08:24, Flipchan <flipchan(a)riseup.net> wrote: >> >> Hi all! Great with a new mailing list anyhow i was wondering IF >> anyone have any tips on some good ddos defense for .onion sites , >> take care > > Hi! > > Many DDoS attacks, particularly those that use reflection and > amplification, rely on the attacker knowing your IP address. Such > attacks cannot be used against a properly implemented .onion site, as > the service's IP address is hidden. There are also torloris and pyloris, which are not volumetric. > Conversely, defense against DoS attacks often involve blacklisting > attacking IP addresses. Since the attacker's IP addresses will also > be hidden, such defenses cannot be implemented. Indeed. > What you're left with is using good fundamental site design. > Specifically, putting any resource-intensive operations behind > authentication or a CAPTCHA. Of course, any CAPTCHA should probably > be locally generated to avoid leaking the hidden service's address, > and CAPTCHA generation could, itself, become the target of a DOS > attack. > > If it's appropriate to the site's mission, I would make only a > simple, static authentication page visible to non-authenticated > users. Wouldn't torloris or pyloris work against that too? Are these attacks still effective against onion sites? If so, what are the best defenses? One can reduce webserver read and write idle times, but that can also block legitimate users on high latency circuits. There is also the flag CloseHSServiceRendCircuitsImmediatelyOnTimeout. Is it useful to set that to "1"?

2 4

mkonion?
by Alec Muffett 09 Feb '16

09 Feb '16

I've never played with Docker myself, but this looks interesting: "mkonion is a very simple tool to allow you to set up a Tor Onion Service (also known as a Tor Hidden Service) for an existing Docker container." https://github.com/cyphar/mkonion <https://github.com/cyphar/mkonion> and https://news.ycombinator.com/item?id=11063900 <https://news.ycombinator.com/item?id=11063900> -a

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

tor-onions