- tor-onions - lists.torproject.org

Re: [tor-onions] [tor-relays] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]
by grarpamp 05 Jan '19

05 Jan '19

On 1/4/19, teor <teor(a)riseup.net> wrote: >> 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. > > It's not just about feature parity. Right. Feature parity is nice and excellent goal, till then, and with *no* plan for same on horizon table, it's about outright removal and killing of long standing features instead of rightly letting users choose from among all features to suit their needs. Killing ".<node>.exit" in URI's raised some questions, and using MAPADDRESS was the nearly functionally equivalent alternative existing / provided. All good. Killing v2... whose 80-bit addressing just so happens to enable appending to an RFC4193 /48 to create a 128-bit IPv6 space allocation with its inherent UDP all provided by way of Onioncat and OnionVPN over v2 onions and v2 HSDir nodes... would rip out accessibility to ***entire classes of transport protocols*** that users, and their applications, around the world, need to function properly, and can and do use. With the main arguments revolving that users are too stupid to select which of v2 or v3 best suits their needs, that v2's benefits have no acceptable tradeoffs for them, etc. That argument should be rejected. As should others... > Maintaining a reasonable level of security for v2 onion services > requires a lot of paid and volunteer time. We need to find bad > relays, and block them on directory authorities. Not really. v2 onion in it's current form has been more or less coded, done and operational for ~20 years, minus occaisional bug and enhancement phases. People have already explained in recent threads how, after the default out of the box mode for all *new* users is changed to v3 onions, those with need to use v2 onions can and will happily explicitly choose v2 and it's tradeoffs, manually in configs, to support their needs. Those tradeoffs should be documented onsite and in v2 man sections. Tor could even make some future release flag, complain about, and not load any current v2 config it detecs, directing them to such handholding docs until they specify "V2YesMommyImABigKidNow=true". As far as money goes, the Tor Project takes in $4.2 Million a year. Some of it's people are taking over $178k a piece, with at least 7 of them receiving over $100k, and the true volunteers eschewing all. Those numbers don't include all the slush, side and decentral funding either. Where's the 210 coders and others receiving $10k stipends for half the budget? Where's the open budget and mechanism? People do inquire this from time to time. People can start another Subject to comparatively analyse Tor Project alongside other opensource network overlays and cryptographic comms projects, and even other opensource projects in general. Even start Subjects where other projects could include, remove, or improve on whatever strategy Tor did to reach $4.2M. There's no lack of funds in Tor Project. > If we spend a lot of time blocking relays, we can't spend that > time on improving other areas of the tor network. Let's define this "blocking" as being of v2 HSDir scraping, not of all the other forms of bad relays. Community volunteers run the public opensource automated scrape detection and reporting tools. The weekly config change volunteer DA's execute based on that is trivial effort. With a bit of logic it's even automateable. Yet as above, v2 users do and will soon *explicitly* choose and accept those tradeoffs. So that's a non argument too. > v2 onion services also add a significant amount of load to the > Tor network. They use older, inefficient crypto, and they are No. v2 is not some new network tax that just came alone, it's the first mass version and the entire base of onionland. Load is a ratio. v2 used to carry 100% of the load since then, and still carries over 90%. Some crypto is HW accel, some not, in both v2 and v3. And if that was a metric'd and studied issue, even other 80-bit algos could be chosen in some long term v2 support release. > often targeted by scanners. No again. Let's define what "scanners" might mean... Land of v2 and v3 are equally web spidered 24x365, it's HTML, no one can stop that. Known v3 onions are portscanned just as much as v2 onions are. If "scanning" means "searching for key collisions by generating offline", both v2 and v3 are reasonably collision proof to make that nearly moot. And "scanners" testing generated key lists for HSDir resolve or TCP connect on the live network will learn in one day that there is absolutely zero hope there. So that's all moot. For separate topic of v2 HSDir "scraping" see above. > If we spend a lot of network resources on v2 onion services, > then we can't use those resources for more efficient, user-focused > traffic. No. Users have reasons to use, and do and will continue to select and use v2, even if they have to fork tor. v2 is "used" by "users" and is thus "user-focused" traffic by definition. > So there are many engineering tradeoffs here. Where? Draw up a list of what needs to be done to make 80-bit v2 support and engineering better. Work to minimize the diffs between v2 and v3, update whatever algos and protocols in v2 needs addressed, modularize and make v2 pluggable (and vN for that matter), call for extended maintainers, etc. > Hopefully, we'll have feature parity on v3 very soon. And then > apps will migrate from v2 to v3 (or dual-stack). IPv6 (with inherent UDP) parity for v3 onions (or vN) would be awesome :-) There have even been a good number of threads over time where people have suggested ideas on ways to make that happen. Look them up and start from there. However parity is not there yet, so no such apps and users that need to use v2 for it will migrate there, until then. They will continue to select and use v2 as appropriate. > It's best if we transition slowly, in a planned manner. But we do > need to transition in the next few years. Otherwise, we might have > to transition quickly due to network or crypto breaks. And that's > not a good experience for anyone. If's already been decided to make v3 the new default. And certainly not unreasonable to make v2 require explict new config to utilize, the placing of a flag to satiate those benevolents having such concerns for users. However killing v2 is not really a good option until something comes along that provides equivalent of 128-bit IPv6 onion transport (inherently brings UDP), which is today offered by 80-bit v2 onions HSDir and Onioncat. > We try not to have conversations across multiple lists, because > it's confusing. It's hard to follow threads, the conversations > get split up, and the subjects get mangled. Inclusion, informing and information is important. Don't create confusion by bloating and destroying valuable Subject header space with stupid list tags, colossal mistake there made by so many admins and instead of teaching requestors why it's bad. Use a good MUA that does proper email threading. Trim superfluous entries from To and Cc. Don't top post, don't block quote, don't send HTML, etc... Put at least some work into all your comms all the time, that way any occaisional missed or overridden elements have minimal effect on the ongoing aggregate sum. Don't be a lazy September fuck. > Let's use tor-relays for further discussion. Draft a proposal for what aspects might go where. Maybe tor-relays for v2 HSDir support and their CPU specific bits of the subject. Yet the overall topic and conversation is much larger. Until it gets figured out, sorted into whatever workbins, what goes where... some inclusion and crossing now and then is in fact efficient, useful, and won't blow up the world :)

1 0

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 27 Dec '18

27 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 18 Dec '18

18 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 05 Dec '18

05 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 29 Nov '18

29 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 15 Oct '18

15 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 27 Sep '18

27 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