From grarpamp at gmail.com Tue Dec 4 23:36:33 2018 From: grarpamp at gmail.com (grarpamp) Date: Tue, 4 Dec 2018 18:36:33 -0500 Subject: [tor-onions] [tor-talk] Tor official list of new .onion addresses? In-Reply-To: References: <7acae6c647e93a409625eab301ab48b2@cock.li> Message-ID: [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. From anan at disroot.org Sat Dec 15 10:01:00 2018 From: anan at disroot.org (anan) Date: Sat, 15 Dec 2018 10:01:00 +0000 Subject: [tor-onions] Torify WebDAV ? Message-ID: <9502a764-aa47-d8d2-14a8-7e135265c242@disroot.org> 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! From anan at disroot.org Mon Dec 17 20:42:00 2018 From: anan at disroot.org (anan) Date: Mon, 17 Dec 2018 20:42:00 +0000 Subject: [tor-onions] Torify WebDAV ? In-Reply-To: <9502a764-aa47-d8d2-14a8-7e135265c242@disroot.org> References: <9502a764-aa47-d8d2-14a8-7e135265c242@disroot.org> Message-ID: <215a3230-72c2-51a9-7631-eeec065587a6@disroot.org> anan: > 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! > Problem solved, I found the 32-bit Nextcloud client I needed. From jsevans at pm.me Tue Dec 18 20:28:14 2018 From: jsevans at pm.me (J. S. Evans) Date: Tue, 18 Dec 2018 20:28:14 +0000 Subject: [tor-onions] ramdisk based onions sites Message-ID: 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? From grarpamp at gmail.com Wed Dec 19 03:58:57 2018 From: grarpamp at gmail.com (grarpamp) Date: Tue, 18 Dec 2018 22:58:57 -0500 Subject: [tor-onions] ramdisk based onions sites In-Reply-To: References: Message-ID: > Would there a be a significant security/privacy advantage to running a > .onion site in a VM that lives entirely on a ramdisk? RAMdisk means in RAM not on media. That devolves to cold boot, or even FDE, attacks, both of which are relatively harder or complicated or short time window than plaintext disk. Or process and general memory space and I/O capture in real time by VM parent, hypervisor, etc. If you can't trust the VM parent, which you probably can't, the answer might be no, or yes, depending on the range of capability estimate you assign to them. > dumped in the event of an emergency Some OS have knobs to turn off all swap, dump, pagefiles, etc that otherwise go to media by default. Your questions are far too generic so no one can really help you. Sit down and chart out your own datasets, risks, threats, backups, etc. Punch your questions into any search engine. Learn OS admin as needed. Etc. From grarpamp at gmail.com Wed Dec 26 18:10:49 2018 From: grarpamp at gmail.com (grarpamp) Date: Wed, 26 Dec 2018 13:10:49 -0500 Subject: [tor-onions] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns] Message-ID: > 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]