tor-onions September 2018

tor-onions@lists.torproject.org

11 participants
6 discussions

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

Probably-stupid question about Circuit IDs
by Alec Muffett 23 Sep '18

23 Sep '18

Hi All, I'm just skimming Mahrud's patch at https://github.com/mahrud/tor/commit/a81eac6d0c0a35adc6036e736565f4a8e2f806… ...referenced from elsewhere, and also from the blog post: https://blog.cloudflare.com/cloudflare-onion-service/ Luckily for us, the IPv6 space is so vast that we can encode the Tor > circuit number as an IP address in an unused range and use the Proxy > Protocol to send it to the server. Here is an example of the header that > our Tor daemon would insert in the connection: ...and it makes me wonder how far back up the chain of hops towards the client, that the circuit ID is visible to a malicious relay? Is it mostly-hidden several onion-skins down? I presume it's not trackable all the way from the client's guard? Am thinking about the necessary scope for a correlation attack. -a -- http://dropsafe.crypticide.com/aboutalecm

4 5

Draft: Different Ways To Add Tor Onion Addresses To Your Website
by Alec Muffett 22 Sep '18

22 Sep '18

I've spent the morning pulling together a bunch of draft thoughts regards the technical pros/cons of differing forms of site onionification; thoughts, comments & feedback are warmly welcomed: https://medium.com/@alecmuffett/different-ways-to-add-tor-onion-addresses-t… - alec (ps: apologies if you see 2+ copies of this, I am treating maillists separately) -- http://dropsafe.crypticide.com/aboutalecm

1 0

TBB 8 alt-svc and redirecting alt-svc'd users to navigate via the .onion
by Mike Tigas 21 Sep '18

21 Sep '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey y'all, Copying this over from a reply I made to tor-talk (since I mentioned it over in the #tor-onions IRC channel). Basically 1) confirming that alt-svc does seem to work consistently in newer TBB, and 2) a fun accident in sending a HTTP 302 to folks that get to the onion via alt-svc. > [...] > In any case, I did a quick test on propublica.org *not* using cloudflare's built-in onion service feature (since we're running our own with our own EV cert anyway), and wanted to mention it here: > > Set `alt-svc: h2="www.propub3r6espa33w.onion:443"; ma=300`, and looks like TBB (8.5a1) actually did silently switch over to using the onion for the connection. As above, there'd generally be no outward indication to the user that this has happened, except I'd actually configured the onion proxying bits (right now running nginx) to throw the browser a 302 redirect to the onion domain if the HTTP Host header isn't the onion domain. So, I'd inadvertently set this up to work where the user actually > does get fully redirected over to the onion. > > (I've since taken off the alt-svc header, since that was just a quick test and I'll need to figure out if that's behavior we want in lieu of the TBB UI getting an explicit user interaction before moving to the alt-svc. But figured that's worth mentioning for folks who _do_ want to easily make a clearnet domain redir TBB to an onion domain.) > > [1]: https://trac.torproject.org/projects/tor/ticket/27590 > [2]: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png Anyway, that was a fun and awesome surprise. Perhaps should be obvious, but honestly I had no idea how the alt-svc behavior was going to work. Hopefully this is helpful to others? - -- Mike Tigas https://mike.tig.as/ -----BEGIN PGP SIGNATURE----- Comment: https://mike.tig.as/pgp/ Comment: http://tigas3l7uusztiqu.onion/pgp/ iQIzBAEBCgAdFiEEGzfVMu3Uhpsce8OaFLh4upXaaEoFAluley0ACgkQFLh4upXa aEp25g//ZvfORMnDMc4kf0OicTYRsv0mJUA/QS7GAqtpNX4Su5iqQWRYN8yE80iU a3u06z+V1lVCLW5GKjGdPZjcxtAaRmq+fezR9ScUhxIg+BdeApQHUpYgf7DABZtL ImYNx8dO3gkFjbmA0P6Cpxzf5Fl8nYMuyH40LivlufWERapYX9r6YKTR0o0zmkzj 06A9E7wPGeJxnbD+pc8XxSdtCJhxFRGVqoT9MqnRkiMTRU1Dh2Fbriyaqx1iHj/H CjCGIE3A9WmGdUKlRgcJzMFoRz/GXLnxGzEjT3eOu56BA3CY/ShYyUMmUf3ILj0s 8L5UHs7zlzSWFpfqO7kYrm0IJForS32DxtsQHGcVyz6Hi+UHBHoWob+1caukWX4G CI7sC+rw//M3iGxJddRUYHTNh8ZJSpglDAP0mBd3qBCTvBHTDuqBopfLr4/Vs3MY DKTYmjT+vp2HeXu3gT7S8E+aF40WmFNmQLBvnxqb0PclbhRxXhd+5UxAfzv6EW0L oZgL4vQzuEjV4j15vozqlojTInIlrpLdWAmx0xAhRfQIdjSHlWWXhkKdGIl12H76 wswRkBi2LHBzPANx7VkMT7FItF7+Hcw5MwEsZ8NJV7P6mWZ8CtT8fUJaPLAAYaBX q0UELMhkXQi6XoX7M8WRfY/d8R71fNUgzJTUNffktE3yBpxdliWIuAQBEwoAHRYh BOk8LVk3LzcQmzAuvZFvvD/f12DEBQJbpXstAAoJEJFvvD/f12DE4fkCCM54+/b8 Z3qI9XBUC2iNgjaFuVYd8IgS0ikl5xLMePJTZVp1FxrNhBmqd0G8JwhRxOq6PNWf tPH7VLpv1jtPX/AGAgkBqemkYIZnEGujCdQuiYjyHDsiWofIjcycX3ei593IDMXp NqdrFz2/auLeZYHBPKaH5ts4Vj+xIAW4Zk0DBafmQfM= =XpLQ -----END PGP SIGNATURE-----

3 5

Privacy Audits for Onion Services
by Jason S. Evans 20 Sep '18

20 Sep '18

Hi all, How can I best audit an onion service to make sure that my IP can not easily be compromised? Is there a list of things to do to try to hack my own site to try to find the IP? Thanks! Jason

9 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

tor-onions September 2018