- tor-dev - lists.torproject.org

DNS-over-HTTPS (DOH) in Firefox/Torbrowser
by nusenu 01 Jul '20

01 Jul '20

Hi, since Mozilla did tests [0] on DOH [1] in Firefox I was wondering if Torbrowser developers have put any thought into that as well? Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because the answer probably matters for exit documentation in the relay guide if clients do DNS themselves over TCP connections instead of relying on the exit (even if torbrowser is not the only tor client). thanks, nusenu [0] https://www.ghacks.net/2018/03/20/firefox-dns-over-https-and-a-worrying-shi… [1] https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ -- https://mastodon.social/@nusenu twitter: @nusenu_

4 4

[RFC] Proposal: A First Take at PoW Over Introduction Circuits
by johnymnx＠airmail.cc 01 Jul '20

01 Jul '20

Hello, list ! Some ideas about this proposal, it's a little bit surface ideas, cause I'm not currently digging deep into the internals of Tor-core. There's user division on different classes there ("The standard web user", "The motivated user", "The mobile user"). I would add "Registered user", user registered within the service. Thus service keeps fast-access DB(Redis) with some unique-id of registered user, which is given to registered user. When user wants to connect to HS, he puts this Unique-ID via TBB (similar to stealth auth introduced recently) About "The mobile user", mobile user can be offered two options: 1. Go to Desktop 2. Compute series of reCAPTCHA 3. If mobile user is "The registered user", enter unique-id saved in some encrypted vault on the phone Registered and unregistered class of users introduces another issue When HS starts its operation and no registered users exist, and DDoS starts with initial HS availability to the World, unregistered/guest users will have no chance to register on HS. Thus, hybrid solution is required, as described in 5.2 (5.2. Future directions [FUTURE_WORK]) "PoW + "Third-party anonymous credentials" HS must have Third-Party Human Puzzle service behind Anit-DDOS operator (Cloudflare, e.t.c.), where unregistered users could solve some AI-proof puzzles and get access-token to connect to HS In the long run, when user base of HS is saturated, and number of user registrations decays, PoW for unregistered users can be significantly increased, thus protecting HS from huge DDoS attacks, cause it's usually when HS is popular and has big and saturated user base, it becomes target for huge DDoS attacks. Verification of PoW I didn't dig deep to HS implementation, but it seems reasonable if decision about PoW verification is made on the closest node to client(ClosestNode). 1. HS sends encrypted PoW task to client 2. Client computes PoW 3. Client sends PoW to ClosestNode 4. ClosestNode verifies PoW (verification of PoW is always much faster, than Proof) 5. Verification succeeded - approve connection to HS 6. Verification failed - disconnect this client > Finally, our proposal has a big benefit over the blockchain use cases: > it's > much more agile. We can deploy changes to the PoW algorithm without > having > to hard-fork, and we can do this even through the consensus for maximum > agility. This means that we should try to use this agility to our > advantage. Change of PoW algorithms can be made in form of some PoW CAP(capability) flag, so some version of client supports PoW_CAP1, PoW_CAP2, PoW_CAP3 and HS supports PoW_CAP1, PoW_CAP1, thus they both can only interact with intersection of their PoW_CAP# sets. Similar to OpenVPN crypto-capabilities exchange between client and server

1 0

Docker containers to run tor with multiple glibc versions
by Daniel Pinto 01 Jul '20

01 Jul '20

Hello, I've been investigating some bugs related to the seccomp sandbox. While doing this, I've developed some docker containers that can run tor with different versions of glibc. As this might be useful for future problems, I wanted to share them. You can find the containers in my github repository: https://github.com/Jigsaw52/docker-containers-glibc-tor I've created containers for the currently supported versions of Ubuntu and Debian. Each container builds the glibc versions with which I was able to start the tor built on that container. They also download and build tor from the current master branch and create a test torrc which enables Sandbox and %includes folders and files in the home folder of user user. There is also a container for alpine to test tor with musl libc. To run a program with a specific version of glibc, use the command: run_with_glibc <GLIBC_VERSION> <PROGRAM_PATH> [<ARGS>] You can see which glibc versions are installed in /opt/ or in the dockerfile. On the root user home folder, you will find a script install_glibc.sh that will download and build the glibc versions passed as arguments. The script supports glibc 2.13 and above. If you need to build versions of glibc before 2.13, the following page will be helpful: https://www.lordaro.co.uk/posts/2018-08-26-compiling-glibc.htm Even though we can build glibc 2.13, even the oldest containers (Debian 8 and Ubuntu 14.04) are only able to run tor with starting with glibc 2.17. This is because the tor binary built in the container (using the container system glibc) requires symbols for glibc 2.17. According to this page (https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa45b1) this provides coverage for the glibc versions present in the supported versions of the top 10 Linux distros, except for CentOS 6.10 which EOLs in November. Two containers (Ubuntu 14.04 and 18.04 or Debian 8 and Debian 10) are enough to cover the glibc versions from 2.17 to 2.31. Best regards, -- Daniel Pinto

1 0

Implementing an embeddable C++ Tor client, advice requested
by The Paranoia Project 26 Jun '20

26 Jun '20

Hello everyone, I'm a long time user of Tor, first time poster here. Over the last few months, I have been working on a light weight C++ client only implementation of the Tor protocol, intended to be used as an embedded library in other applications. It is now at the stage where it can complete bootstrapping, build circuits, as well as connect to services / host hidden services (v3). I have been building this primarily off the spec documents (which have generally been extremely helpful), and well as the assistance of stepping through the official Tor implementation when needed for troubleshooting and to confirm specifics. Before I release this to the wider world, I'd like to confirm a few points that may not be explicitly stated in the specs. 1. In general, what are the things to look out for when implementing the Tor protocol beyond "making it work" and validating all data (signatures, timestamps, etc)? One thing I'm concerned about is the risk of fingerprinting where the spec does not completely specify behaviour, e.g. the order in which link specifiers are passed in an extend cell, exact criteria for when circuits are explicitly destroyed etc. (I'm very excited to see the proposals around CBOR on this point which would help greatly with knowing that a canonical data representation was used). 2. When it comes to bootstrapping, the official implementation appears to favour accessing directories via plaintext HTTP rather than connecting on the OR port and using create fast / begin dir. What is the motivation for using the plaintext option (and for that matter, having a plaintext http service open at all)?. While the OR will learn just as much about the client regardless, it seems like the default plaintext access to directory information unnecessarily gives away details of how clients engage with the Tor network to third parties. 3. When using bridges and in particular pluggable transports, how is the client intended to safely bootstrap in the cold start case where it does not know up front which bridge/relay it will be connected to (e.g. when using Snowflake)? The RSA identity can be accepted in blind faith based on the Tor handshake, and it's then possible to get the full details with create fast / begin dir, but how does a client know that it has been connected to a bridge that is "blessed" by the Tor network rather than a MITM actor? 4. Finally, if anyone reading has been involved with or close to the development of other unofficial Tor implementations, what are the lessons learned on this front? I'm aware of among others Orchid (updated last in 2016), node-Tor (does not implement ECC) and torpy (does not implement hidden services v3). What makes these fail / stall? Many thanks, P

2 2

Re: [tor-dev] Reproducing #33598 "chutney does not fail on some SOCKS errors"
by c 18 Jun '20

18 Jun '20

On Mon, 15 Jun 2020 14:06:37 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: > This seems plausible, though 0.0.0.0:x will just be the local computer as well. > > Maybe you could try routing to a known-unassigned address, or one that > Tor simply won't support, like the one from RFC 6666? From my understanding 0.0.0.0/32 is a special address that is not supposed to be routable. But `ping 0.0.0.0` does seem to redirect it to 127.0.0.1 for whatever reason; it might be some odd Linux-specific behaviour. I'll check for other known-unroutable addresses and try one of them. > [...] > > It's in Traffic.py, Source.handle_connect(), in this line: Thanks, I'll take a look at it. Caitlin

1 0

GSOC: Social Media Sharing for OONI
by Krona Emmanuel 18 Jun '20

18 Jun '20

Hi, I'm Krona Emmanuel, working on implementing better Social Media Sharing within OONI Explorer [1]. OONI Explorer allows users to view measurements and visualizations of network interference around the world. This project is aimed at improving OONI Explorer in the following areas: 1. SEO 2. Social media link sharing. 3. Sharing charts So far, I have been working on making prototypes for charts and social media link sharing. I recently finished a PR which improved the meta tags of measurement pages to better indicate the results of the measurement [3]. You can see more details about the project on the GSOC project page [2]. I would be very happy to get any suggestions etc about the project. I'll also send in more updates about the project as I implement features. Regards, Krona Emmanuel 1. https://explorer.ooni.org/ 2. https://summerofcode.withgoogle.com/projects/#4714428131442688 3. https://github.com/ooni/explorer/pull/470

1 0

Onion Client Auth on v3 descriptor via Control port
by Miguel Jacq 17 Jun '20

17 Jun '20

Hi, I'm one of the OnionShare developers, looking at what can be done to support Client Auth with v3 onions. OnionShare depends on Stem for all its interaction setting up ephemeral onions, so we need Stem to support that fierst. So I have been working on adding support for ONION_CLIENT_AUTH_ADD to Stem. I actually have it working as far as getting a 250 OK back from the controller! Nice. But I'm puzzled, because despite successfully adding the client auth, I can access my onion service *without* auth in Tor Browser. Here is a link to a PoC script. Note that it doesn't do the ONION_CLIENT_AUTH_ADD via Stem here yet. I have that working locally, but this issue isn't with my Stem implementation I don't think... https://gist.github.com/mig5/2e95a3fbe157e1f78764f7a718bf93b9 Here's the output if I run the script with python3 create-v3-service-and-keys.py user@onionshare:~$ python3 create-v3-service-and-keys.py http service: http://127.0.0.1:8080/ starting onion service with: key_type='NEW', key_content='ED25519-V3' http://4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd.onion/ private base64: wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= public base32: WJJTONEA5SRZKVHHAYY2EHIF5LNF3526RCLYSC7ZZRCPVPIFA6PA==== private base32: YJELEM2W2A3WOSHDOPX2DNTHNQ7TW4GQMX6KC4VNZ4NWTHGJHL6Q==== Now, if in another terminal I telnet to the control port and manually add the onion auth, I get a 250, I can view the auth etc: user@onionshare:~/git/stem$ sudo -u debian-tor telnet 127.0.0.1 9051 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Authenticate "" 250 OK ONION_CLIENT_AUTH_ADD 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd x25519:wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= 250 OK ONION_CLIENT_AUTH_VIEW 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd 250-ONION_CLIENT_AUTH_VIEW 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd 250-CLIENT 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd x25519:wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= 250 OK So that all looks good. But what is weird, is if I go to http://gmdo3idszymnvfbuf2fm6miepearldgwbo7qfc4lsrw2kact2ka77kqd.onion/ , I see my 'hello world', I never had to add any client auth to Tor Browser. What am I doing wrong? How do I make the onion auth actually be 'required' since I succeeded at adding it? I was under the impression that as soon as I ran ONION_CLIENT_AUTH_ADD and got a success, from that point on, client auth would be *needed*. Maybe it's a problem with how I'm generating the keys? I had a bit of trouble figuring out how to send the base64 encoded private key. Even so, it accepts the private key, and yet it allows access without auth, which surprised me... It's probably really obvious but I've been working on this a while so I'm tired :) Time to embarass myself on a public mailing list.. Thanks in advance! Mig

2 3

Onion Service v2 Deprecation Timeline
by David Goulet 16 Jun '20

16 Jun '20

Greetings everyone! I will try to make this quick. Deprecation of v2 has already been discussed on this list [0] and so this is not about re-creating this discussion but rather giving you the Tor Project timeline for v2 deprecation. To very quickly summarize why we are deprecating, in one word: Safety. Onion service v2 uses RSA1024 and 80 bit SHA1 (truncated) addresses [1]. It also still uses the TAP [2] handshake which has been entirely removed from Tor for many years now _except_ v2 services. Its simplistic directory system exposes it to a variety of enumeration and location-prediction attacks that give HSDir relays too much power to enumerate or even block v2 services. Finally, v2 services are not being developed nor maintained anymore. Only the most severe security issues are being addressed. That being said, the deprecation timeline is now quite simple because v3 has reached a good maturity level: * v3 has been the default since Tor 0.3.5.1-alpha. * v3 is feature parity with v2. * v3 now has Onion Balance support [3] * Entire network supports v3 since the End-of-Life of 0.2.9.x series earlier this year. The deprecation to obsolescence timeline: 1) September 15th, 2020 0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6 2) July 15th, 2021 0.4.6.x: Tor will no longer support v2 and will be removed from the code base. 3) October 15th, 2021 We will release new stable versions for all supported series that will disable v2. This effectively means that from _today_ (June 11th 2020), the Internet has around 15 months to migrate from v2 to v3 once and for all. We plan to publish a blog post in the coming days/weeks about this deprecation, in order to inform as many users as possible. It will include the reasons why, how to migrate and the timeline. We'll probably run into some difficulties here; no matter how prepared we think we are, we find that there are always more surprises. Nonetheless, we'll do our best to fix problems as they come up, and try to make this process as smooth as possible. Good Luck! The tor maintainers. [0] https://lists.torproject.org/pipermail/tor-dev/2018-April/013097.html [1] https://shattered.io/ [2] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1084 [3] https://blog.torproject.org/cooking-onions-reclaiming-onionbalance -- 262Gy/4o+HGG/7ELoDp1drRojN33l7AZaBoRHN6mjXY=

5 6

Reproducing #33598 "chutney does not fail on some SOCKS errors"
by c 15 Jun '20

15 Jun '20

I asked on ticket https://bugs.torproject.org/33598 how to reliably reproduce SOCKS errors so that it would be easier to determine when the underlying issue is properly fixed, rather than running into the possibility of race conditions (as the current workaround depends on "waiting long enough" for connections to succeed most of the time). In #tor-dev I believe it was arma who pointed me toward the right direction, but that still leaves me with unresolved questions. It was suggested that I can attempt SOCKS connections to an invalid host/port versus a valid one, in order to have a reliable failure case for testing. But in the context of Chutney I believe we only want to attempt local connections, correct? So either attempting connection to 127.0.0.0/8 on a known-closed port, or perhaps more simply 0.0.0.0 on any port, would be a reliable case to use, correct? Also from my comment on #33598: > Assuming workaround is at Traffic.py:441? I see the timeout was > adjusted in 95ce144c which has more changes than just that line. and > will decreasing the timeout back to 0.2 be enough to encourage > failure? Last question: I looked for a bit, but where is Chutney actually initiating SOCKS connections to Tor during tests? I still find it hard to follow especially when I am going in blind for much of this. Caitlin

2 1

#32888 IPv6 and 'Address' option
by c 15 Jun '20

15 Jun '20

Trac <https://trac.torproject.org/projects/tor/ticket/32888> describes that "we should also log [for] IPv4 and IPv6: the Address torrc option" and as tor(1) states, 'Address' takes only an IPv4 address and port. So what is suggested here? Make 'Address' support IPv6 to be consistent with other options ('ORPort', 'SocksPort', 'TransPort', 'DNSPort', and the like all support multiple declarations per torrc, both IPv4 and IPv6)? If we will have IPv6-only relays in the future, this option would make quite a bit of sense. Since I'm on the topic of #32888, I went ahead and pushed the IPv6 logging portion to <https://github.com/torproject/tor/pull/1932> and have tested with 'ORPort [::1]:9001' and it seems to log successfully. Not a big change, so I expect it to be an easy merge. Caitlin

2 1