- tor-dev - lists.torproject.org

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

Support for full DNS resolution and DNSSEC validation
by Christian Hofer 14 Jun '20

14 Jun '20

Hi there, I have a proposal regarding DNS name resolution. Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure… Implementation: https://github.com/torproject/tor/pull/1869 All functioniality is behind the DNSResolver feature flag, so don't forget to activate it before you start testing. Please let me know what you think. BR Christian

7 29

Walking onions specifications: Project wrap-up
by Nick Mathewson 10 Jun '20

10 Jun '20

On a grant from the zcash foundation, I've been working on a full specification for the Walking Onions design. This is the last update for the spec project. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html Week 4: Voting (part 1) and extending circuits. https://lists.torproject.org/pipermail/tor-dev/2020-March/014207.html Week 5: Voting (part 2) https://lists.torproject.org/pipermail/tor-dev/2020-April/014218.html Week 6: Editing, voting rules, and client behavior (part 1) https://lists.torproject.org/pipermail/tor-dev/2020-April/014222.html Week 7: Exit policies: How do they work? https://lists.torproject.org/pipermail/tor-dev/2020-April/014232.html Week 8: Onion services, relay honesty, migration and families https://lists.torproject.org/pipermail/tor-dev/2020-April/014255.html Week 9: (There was no week 9) Week 10: Pushing towards completion https://lists.torproject.org/pipermail/tor-dev/2020-May/014281.html == Since the last update The last couple weeks of the walking onions project were mostly the "fiddly bits" left over from previous work. I had to edit for consistency and clarity, move text around, add specifications for missing details, and so on. There were parts of the voting design that didn't actually work as written, and needed to get tweaked around. Index voting was tricky for a few reasons: notably, index weights are a complex function of bandwidths, which themselves are voted on. I had hoped that we could move the algorithms we use for weighting out of the consensus algorithm and into the authorities, but for now, I think we're stuck with having them as yet another thing authorities need to implement identically. At least the new consensus system itself is extensible, so we have a clear path forward to a better consensus approach for indices (if we ever figure one out). I also needed to figure out handling for VoterCerts: I had done the first version of the spec for how they should appear in parameters documents before I actually figured out how voting would work, and the two approaches weren't compatible. This took some revision, but I think it should work out now. Similarly, I had known that we'd need to use the "detached signatures" mechanism from the existing consensus protocol, but the Walking Onions spec didn't actually allow for this. Fortunately, this was an easy chance to make. And overall, I went through a pretty large number of places in the document where there were "XXXX" comments indicating things I had to come back to later. With that, the first version Walking Onions proposal was ready to go out as [PROP323]. You can see a rendered version of it over at [PROP323-RENDERED], though there will be a better URL for that in the future. I also put out the remaining side related proposals ([PROP321] for families, and [PROP322] for link specifiers for directory ports). == Project recap When I first described Walking Onions [PROP300], I had only the general outlines of a design for a more efficient Tor network: a couple of tricks to allow clients to continue building secure paths through the network without having to know a list of relays on the network. But I had known there would be remaining problems to solve, and listed them in that proposal. Thanks to this grant, I've been able to flesh out Walking Onions to a specified design that I think we could actually build. In doing so, I ran into the typical specification curse, where each change led to a need for other changes. Notably: * The need for a new kind of directory-like structure led to the need for a more flexible and parsable metadocument format, and a more generic voting algorithm for authorities. * When designing the new meta-format, I found a better approach for handling expiration and clock synchronization between clients and relays that should allow us to be a little more lax with skew, while better resisting attacks based on serving obsolete information. * The search for a reasonable solution to exit policies led to a hybrid extraction/designed approach for clustering exit ports by their correlatedness, then designing exit policies around semantic similarity in port types. * When enumerating the various ways that clients need to be able to request SNIPs and circuits, I found a need for a span-based SNIP query request, which I hadn't previously known that we'd need. This simplifies some of our logic. * (and more; please see previous updates.) The resulting documents (proposals 318 through 323) are not final: I believe that as we continue to discuss them, and eventually implement them, we'll find further opportunities for improvement--and for fixing things that I missed when I was designing and writing all of this. But I think we've got a much firmer grasp of this project now. I think there are parts that we could in principle start building now: the preliminary proposals 318 (limiting protocol versions), 319 (cell fragmentation) and 321 (improved family handling) are high on my list for now, if we get time. And now the design iteration begins! [PROP300] https://gitweb.torproject.org/torspec.git/plain/proposals/300-walking-onion… [PROP321] https://gitweb.torproject.org/torspec.git/plain/proposals/321-happy-familie… [PROP322] https://gitweb.torproject.org/torspec.git/plain/proposals/322-dirport-links… [PROP323] https://gitweb.torproject.org/torspec.git/plain/proposals/323-walking-onion… [PROP323-RENDERED] https://people.torproject.org/~nickm/volatile/rendered.html

1 0