- tor-onions - lists.torproject.org

Tor-onions
by Carol Trujillo 03 Jan '19

03 Jan '19

Hi, i would like to see and post in the tor-onions list. Thank you

2 1

Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]
by grarpamp 26 Dec '18

26 Dec '18

> relays have a rather distinct signup and fingerprint pattern > usually seen for onion attacks. > ... > a) If you are an .onion operator I'd like to encourage you to switch to onion > services version 3 > ... > so we can start > ... > b) dropping onion version 2 services eventually. These are two separate things not necessarily tied together, thus split for clarity as above. The former a) is up to the onion operator based on their needs. If they have no need for v2, or need v3, they can or should switch to v3, indeed. The latter b) is a feature that some users and operators in and for onionspace explicitly choose and depend on to support common apps, and thus would definitely not like to see yanked out from under them. Better instead to advertise and update the default onion semantics for [new] users to v3, and continue support and backport doable features to v2 until time below... Node operators (tor-relays) would continue offering v2 HSDir support module until such time as the reasons for choosing v2 by those above are supported in v3 or vN. See the threads on this subject on tor-talk, tor-onions, and tickets for more. [CC for inclusion, move there if not relay specific]

1 0

ramdisk based onions sites
by J. S. Evans 19 Dec '18

19 Dec '18

Would there a be a significant security/privacy advantage to running a .onion site in a VM that lives entirely on a ramdisk? The downside obviously would be that anything not backed up would be lost in the case of a reboot. To me the upside is that it would be very difficult to see anything that had been running in the VM if it needs to be dumped in the event of an emergency. I've heard of techniques that can get bits of data from ram that has been turned off, but I don't think that's easy/inexpensive to do. What do you think, group?

2 1

Torify WebDAV ?
by anan 17 Dec '18

17 Dec '18

Hi, I have an onion service with a Nextcloud server. I would like to access its files from a 32-bit computer. Nextcloud desktop client is torifyable, but it is 64-bit. Nextcloud does not privide a 32-bit desktop client. I tried torsocks nautilus so that I could access my files through "Connect to server" using WebDAV, but it says it cannot resolve hostname. Any suggestion on how to access my onioned Nextcloud files from my 32-bit GNU/Linux computer? Thank you!

1 1

Re: [tor-onions] [tor-talk] Tor official list of new .onion addresses?
by grarpamp 04 Dec '18

04 Dec '18

[Typo in onion list address, fixed and resent herein] > The descriptors seem to indicate onion addresses. So if I act a relay, I > seem to be able to get the addresses. Then how? ... Could someone > skilled try to get the lists? :D Yes, many services, researchers, and privates routinely do this. The code exists in some repositories, or you can write your own, it's not hard. Enumeration and listing in and of itself is not a problem, neither good nor bad on its face, a mere fact of the technology in use. It's up to the v2 users to decide if the tech works for them or not, fits their use case or not, and whether or not to use it, not use it, or use something else, or to seek or be provided education on the tech and tradeoffs. For many users, v2 vs v3 simply doesn't matter. For others, you may wish to blog or help them choose v2 vs v3. And in fact, v2 onion services are very useful when combined with OnionCat to yield IPv6 and UDP transport among tor's P2P onions. That's simply not possible with v3's no-IP TCP only onions. So for example, VoIP and other existing and new comms apps, mossh, and Bittorrent freespeech and robust uncensorable distribution channels, are enabled and exist entirely within tor's v2 onion space, somewhat similar to I2P. Search the list and tickets for "onioncat" for other use cases. Just because some poor souls footshoot themselves... which they'll still obviously somehow mangage to do with any tech regardless... isn't sufficient reason to cease support, maintenance, development, backporting, and furtherance of an agnostic technology such as v2 onions. > with OnionCat to yield IPv6 and UDP transport among tor's P2P > That's simply not possible with v3's no-IP TCP only onions. That is to say, it's not possible with code that exists today... the various possible solutions, and others yet to be proposed, that could provide those things with v3 onions, haven't been developed and put into working code yet. As such, it would be an interesting project for anyone or group that wants to do it.

1 0

hidden website - which cms to choose ?
by dlugasny＠protonmail.com 28 Nov '18

28 Nov '18

Hi, I just would like to know which CMS is commonly used for Tor Hidden websites ? Which software YOu suggest to create some small hidden website ? Do You use cmses without databases or with DB ? I`m drupal user, do You think that drupal is secure enought to use it as cms for hidden website. Thanks in advance for any advices. Cheers Dlugasny Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

HSV3 - chmod 700 for keys
by Patrick ZAJDA 06 Nov '18

06 Nov '18

Hello, When creating a hidden Service version 3, I noticed the public and private key files have a chmod 700 when hostname is 600. For hostname I understand; but why execution is set for keys? I tried to chmod 600 for key files and it also worked. Is there a particular reason for this situation? Cheers, Patrick

2 1

Debugging an ubuntu / apache2 / tor / ssl setup
by Peter Brooks 14 Oct '18

14 Oct '18

I was just wondering if there were any debugging tools you could recommend. I'm setting up a tor site on ubuntu, using apache2 to work with ssl. I'm having trouble tracking the errors. I can see my site is there, but not working. Looking at a well known site: torsocks --debug wget --no-check-certificate www.propub3r6espa33w.onion It works. When I do it for my site, I get: 1538477773 DEBUG torsocks[8726]: Socks5 received connect reply - ver: 5, rep: 0x05, atype: 0x01 (in socks5_recv_connect_reply() at socks5.c:525) 1538477773 ERROR torsocks[8726]: Connection refused to Tor SOCKS (in socks5_recv_connect_reply() at socks5.c:549) But when I look for the connection refused on the server, I can't find any reference to it in syslog or in hs.log or hsinfo.log - I've directed the weblogs to syslog. Where should I be looking? I'd like to be able to capture the flow: https -> tor network -> 127.0.0.2 port 443 -> tor -> apache -> *.php To see where, and why, it fails. I'd hoped to find a debug option, or log, that allows me to see the socks5_recv_connect_reply() being sent from my server. Any suggestions?

8 16

Re: [tor-onions] Probably-stupid question about Circuit IDs
by Gabbi Fisher 26 Sep '18

26 Sep '18

Hi there! I'm now maintaining Cloudflare Onion Services (Mahrud recently left to pursue his PhD). I will be the new point person at Cloudflare for this project. T, here are some answers to your questions: > Is the connections between Cloudflare's Tor onion service and Cloudflare's proxy > instance encrypted? As of now, the proxy protocol header passing from the onion service to the proxy instance is not encrypted. (This header includes a synthetic IP address based on circuit ID, which we use to uniquely identify circuits). We understand that this is undesirable and leaks information about the circuit ID at this hop. We're discussing options on how to address this. > Does Cloudflare host its onion services in the same data centre as the proxies they > talk to? No. > Does the Cloudflare proxy strip out the PROXY header? > Or does it get transformed into X-Forwarded-For? (Or something similar?) X-Forwarded-For contains the synthetic src IP we include in the PROXY header. > Why does the Cloudflare dashboard show the circuit id to site owners? > They can't effectively block a circuit id; if they try, there may be collateral > damage to unrelated users; and it is an information leak. The Cloudflare dashboard shows all traffic (even that with a synthetic IP) to customers as part of a standard logging procedure. I agree that customers should not block these synthetic IPs, given that they correspond to ephemeral circuits. Though customers will be able to see these synthetic IPs, they aren’t really actionable due to their short-lived nature. > How long does Cloudflare retain these circuit ids? The synthetic IPs (built from circuit ids) are collected under Cloudflare’s standard logging procedure. As such, they could be kept as short as one week (for debugging purposes) or as long as one year (if a log is included in the 1% we sample for analysis purposes). Given the extremely short-lived nature of a circuit, these logs will be devoid of any context to us. On Sun, Sep 23, 2018 at 7:46 PM Mahrud S <dinovirus(a)gmail.com> wrote: > I think it would be better if you draft a response to this rather than me > responding. > > ---------- Forwarded message --------- > From: teor <teor(a)riseup.net> > Date: Sun, Sep 23, 2018 at 12:38 AM > Subject: Re: [tor-onions] Probably-stupid question about Circuit IDs > To: <tor-onions(a)lists.torproject.org> > Cc: Mahrud S <dinovirus(a)gmail.com> > > > Hi Mahrud, > > > On 23 Sep 2018, at 12:10, Mahrud S <dinovirus(a)gmail.com> wrote: > > > > In short, yes. I think everything mentioned above is correct, and I'm > not sure what else to add. > > I'm still not quite clear on some of the details: > > > On Sat, Sep 22, 2018 at 9:09 PM teor <teor(a)riseup.net> wrote: > > > >> On 23 Sep 2018, at 04:50, Alec Muffett <alec.muffett(a)gmail.com> wrote: > >> > >> That latter seems not very much worse than the information which a > compromised exit node would be able to obtain ("Browsing Normal Web over > Tor") although it would be a lot more available when the circID is > presented to the any backbone observer who can sniff IPv6? > > > > This IPv6 address isn't in the IP header of the packets between > Cloudflare's > > onion service and Cloudflare's proxy. > > > > It's sent inside the TCP (or TLS?) connection between the Tor onion > service > > and the proxy instance, as a text header before any other inner TCP or > TLS: > > https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt > > > > If Cloudflare encrypts their onion service to proxy connections (and they > > should), the circuit id will only be known to the onion service and its > guard > > (or rendezvous point, for a single-hop onion service connection). > > Is the connections between Cloudflare's Tor onion service and Cloudflare's > proxy > instance encrypted? > > > Alternately, if Cloudflare hosts its onions in the same data centre as > the proxies > > they talk to, then the risk of interception is low. > > Does Cloudflare host its onion services in the same data centre as the > proxies they > talk to? > > > Then, if the proxy strips out this header before sending the request to > the origin > > site, or connects to the origin site using TLS, then this IP address > shouldn't be > > visible on the backbone. > > Does the Cloudflare proxy strip out the PROXY header? > Or does it get transformed into X-Forwarded-For? (Or something similar?) > > > Also note: the CloudFlare dashboard shows the circuit id to site owners: > > https://blog.cloudflare.com/cloudflare-onion-service/ > > > > I can't see how having the actual circuit id is useful to site owners. > > They can't block it effectively, because it's transient. > > (And the same circuit id can be re-used by independent connections.) > > Why does the Cloudflare dashboard show the circuit id to site owners? > They can't effectively block a circuit id; if they try, there may be > collateral > damage to unrelated users; and it is an information leak. > > That said, it's no worse than any other onion site operator using the > circuit id > feature, except that Cloudflare could collect and store a significant > number of > circuit ids. > > How long does Cloudflare retain these circuit ids? > > T > > > -- > mahrud <algorithms.jux-foundation.org/~mahrud/blog> >

1 0

Eventual Success at getting Alt-Svc working for my personal Wordpress blog
by Alec Muffett 23 Sep '18

23 Sep '18

Hey All; I just got Alt-Svc to mostly-work for my blog at https://dropsafe.crypticide.com/ Here's what I did, and why: I set up a dummy interface on my blogserver (for rationale/instructions, see link below) $ grep osite0 /etc/hosts > 169.254.255.253 *osite0.onion* > $ ifconfig dummy0 > dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500 > inet 169.254.255.253 netmask 255.255.255.252 broadcast > 169.254.255.255 > $ ping -c 1 *osite0.onion* > PING osite0.onion (169.254.255.253) 56(84) bytes of data. > 64 bytes from osite0.onion (169.254.255.253): icmp_seq=1 ttl=64 time=0.167 > ms Set up an onion service, pointing at the dummy interface (rather than localhost or the machine's physical network interface): HiddenServiceDir /path/to/wherever > HiddenServicePort 80 *osite0.onion*:80 > HiddenServicePort 443 *osite0.onion*:443 > HiddenServiceVersion 3 > HiddenServiceNumIntroductionPoints 3 Configured Apache: # Set ALT_SVC_PORT explicitly because SERVER_PORT fails curiously > SetEnv ALT_SVC_PORT *443* > SetEnv ALT_SVC_ONION *kfq56...trimmed...o6uqd.onion* > SetEnv ALT_SVC_MAXAGE 600 > # Set the Alt-Svc header if the request has not arrived via EOTK; > # You almost certainly do not need to do this, it's specific to EOTK > development. # EOTK sets "*X-From-Onion*: 1" so if that value is empty, set the flag to > true: > RewriteCond %{HTTP:*X-From-Onion*} ^$ > RewriteRule ^ - [ENV=*USE_ALT_SVC*:true] > # ...maybe put other tests here, and then eventually we do: > Header set '*Alt-Svc*' '*h2="%{ALT_SVC_ONION}e:%{ALT_SVC_PORT}e"; > ma=%{ALT_SVC_MAXAGE}e; persist=1*' env=*USE_ALT_SVC* Enabled HTTP/2 on my Apache server (it's not enabled by default): # *a2enmod http2* # ...after adding "*Protocols h2 http/1.1*" to the vhost > config > # *systemctl restart apache2* ...then I found this error message in /var/log/apache2/error.log: *The mpm module (prefork.c) is not supported by mod_http2. The mpm > determines how things are processed in your server. HTTP/2 has more demands > in this regard and the currently selected mpm will just not do. This is an > advisory warning. Your server will continue to work, but the HTTP/2 > protocol will be inactive.* Bother. I found *mpm_prefork* really was enabled by default, and was a hard dependency for php7.0 operation (necessary for Wordpress): # apache2ctl -M | grep mpm Then I found this answer: *https://serverfault.com/a/904115 <https://serverfault.com/a/904115>* ...which told me how to fix this by swapping over to *mpm_event* and *php_fpm*. I followed the instructions (needed to tweak the cited path for the *ProxyPassMatch *line) and tested that the header was being generated and looks sane, via my TorBrowser's tor daemon: $ curl --http1.1 -x socks5h://127.0.0.1:9150/ -I > https://dropsafe.crypticide.com/ | grep -i Alt-Svc > Alt-Svc: h2="*kfq56...trimmed...o6uqd.onion*:*443*"; ma=600; persist=1 The test required the *--http1.1* option for curl, otherwise if the curl client negotiated a h2 connection, I wouldn't apparently see any of the options in a greppable manner. Re: the dummy interface, as described elsewhere: https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-producti… ...the joy of using a dummy interface in this fashion is that all connections from the Tor daemon to a webserver on the same machine will be logged as coming "from" the IP address of the dummy interface. This means that you can track accesses that arrive via the Alt-Svc onion connection, separately from all the others: $ grep 169.254 www-dropsafe-access.log > *169.254.255.253* - - [22/Sep/2018:23:05:48 +0000] "GET / HTTP/1.1" 200 > 231583 "-" "curl/7.54.0" > ...which provides the otherwise-missing information of *whether the Alt-Svc Onion Link is actually being used*. Setting up a dummy interface on Ubuntu is fairly easy, but on Raspbian was a pain because *dhcpcd* gets in the way; eventually I just disabled dhcpcd and went back to /etc/network/interfaces, which was okay because my blog server only has static addresses. I'm still not entirely convinced that everything is working as expected/desired, but I'll update again when I am more certain. The blog is also available via EOTK at https://dropsafe.dropsafezeahmyho.onion/ - requires SSL acceptance. Best of luck. - alec -- http://dropsafe.crypticide.com/aboutalecm

3 4