- tor-dev - lists.torproject.org

Anonymous local count statistics
by Saurav Malani 10 Jul '18

10 Jul '18

Hello Everyone, I am 4th year student at IIIT-H, India. I want to contribute to TOR project specifically to "*Anonymous local count statistics". *I am done with building TOR. I looked at the ticket and had an overview of Tor documentation. But, I feel like being lost. So, it would be great if someone here can guide me on this further, as I am a bit novice in this field, by providing links with relevant info related to the project and also by guiding me on what to do next? and what is done till now? Thank-you, Regards, Saurav Malani

2 1

The case with Tor2Web
by George Kadianakis 09 Jul '18

09 Jul '18

Hello! It's a semi-secret that tor2web traffic has been blocked from the Tor network when we introduced the DoS subsystem this March [0]. The reason is that a big part of the DoS traffic was coming from one-hop clients continuously hammering onion services. This is something that we've been considering doing for a while (for security and code-complexity reasons), and it just happened naturally during the DoS incident. As part of this, and since the DoS subsystem is going to stick around, we are planning to permanently kill the Tor2Web subsystem of Tor, in an effort to simplify our codebase and our feature list. If you've been relying on tor2web for something, please consider switching to a normal 3-hop client indeed. This is a heads up so that you can let us know if that won't work for you, or you need help transitioning out. Cheers and hope we are not making you sad. [0]: https://trac.torproject.org/projects/tor/ticket/24902 https://blog.torproject.org/new-stable-tor-releases-security-fixes-and-dos-…

2 1

locked out of my bug report #26675
by starlight.2018q2＠binnacle.cx 08 Jul '18

08 Jul '18

Today I opened a ticket regarding difficult to understand Torflow behavior. Subsequently I figured out the behavior, realizing it is a non-material bug that has no serious implication. However I can no longer revise the ticket, possibly due to https://trac.torproject.org/projects/tor/ticket/26675#comment:2 or perhaps due to the next change which somehow reversed >Date: Sat, 07 Jul 2018 01:33:46 -0000 >Changes (by cypherpunks): > * status: new => closed > * resolution: => fixed I find this troubling.

2 2

is that the correct URL in the TBB design document?
by nusenu 06 Jul '18

06 Jul '18

Hi, https://www.torproject.org/projects/torbrowser/design/#identifier-linkabili… writes: > While the vast majority of web requests adheres to the circuit and > connection unlinkability requirement there are still corner cases we > need to treat separately or that lack a fix altogether. "lack a fix altogether" links back to the design document itself: https://www.torproject.org/projects/torbrowser/design/ is that the correct URL or a copy-paste error? thanks! -- https://mastodon.social/@nusenu twitter: @nusenu_

2 4

Nearly everything in the Tor source code is moving in 0.3.5
by Nick Mathewson 06 Jul '18

06 Jul '18

Hello, friends! For quite a while now, the program "tor" has been built from source code in just two directories: src/common and src/or. This has become more-or-less untenable, for a few reasons -- most notably of which is that it has led our code to become more spaghetti-ish than I can endorse with a clean conscience. So to fix that, we've gone and done a huge code movement in our git master branch, which will land in a release once Tor 0.3.5.1-alpha is out. Here's what we did: * src/common has been turned into a set of static libraries. These all live in the "src/lib/*" directories. The dependencies between these libraries should have no cycles. The libraries are: arch -- Headers to handle architectural differences cc -- headers to handle differences among compilers compress -- wraps zlib, zstd, lzma container -- high-level container types crypt_ops -- Cryptographic operations. Planning to split this into a higher and lower level library ctime -- Operations that need to run in constant-time. (Properly, data-invariant time) defs -- miscelaneous definitions needed throughout Tor. encoding -- transforming one data type into another, and various data types into strings. err -- lowest-level error handling, in cases where we can't use the logs because something that the logging system needs has broken. evloop -- Generic event-loop handling logic fdio -- Low-level IO wrapper functions for file descriptors. fs -- Operations on the filesystem intmath -- low-level integer math and misc bit-twiddling hacks lock -- low-level locking code log -- Tor's logging module. This library sits roughly halfway up the library dependency diagram, since everything it depends on has to be carefully crafted to *not* log. malloc -- Low-level wrappers for the platform memory allocation functions. math -- Higher-level mathematical functions, and floating-point math memarea -- An arena allocator meminfo -- Functions for querying the current process's memory status and resources net -- Networking compatibility and convenience code osinfo -- Querying information about the operating system process -- Launching and querying the status of other processes sandbox -- Backend for the linux seccomp2 sandbox smartlist_core -- The lowest-level of the smartlist_t data type. Separated from the rest of the containers library because the logging subsystem depends on it. string -- Compatibility and convenience functions for manipulating C strings. term -- Terminal-related functions (currently limited to a getpass function). testsupport -- Macros for mocking, unit tests, etc. thread -- Higher-level thread compatibility code time -- Higher-level time management code, including format conversions and monotonic time tls -- Our wrapper around our TLS library trace -- Formerly src/trace -- a generic event tracing API wallclock -- Low-level time code, used by the log module. * To ensure that the dependency graph in src/common remains under control, there is a tool that you can run called "make check-includes". It verifies that each module in Tor only includes the headers that it is permitted to include, using a per-directory ".may_include" file. * The src/or/or.h header has been split into numerous smaller headers. Notably, many important structures are now declared in a header called foo_st.h, where "foo" is the name of the structure. * The src/or directory, which had most of Tor's code, had been split up into several directories. This is still a work in progress: This code has not itself been refactored, and its dependency graph is still a tangled web. I hope we'll be working on that over the coming releases, but it will take a while to do. The new top-level source directories are: src/core -- Code necessary to actually perform or use onion routing. src/feature -- Code used only by some onion routing configurations, or only for a special purpose. src/app -- Top-level code to run, invoke, and configure the lower-level code The new second-level source directories are: src/core/crypto -- High-level cryptographic protocols used in Tor src/core/mainloop -- Tor's event loop, connection-handling, and traffic-routing code. src/core/or -- Parts related to handling onion routing itself src/core/proto -- Support for encoding * The "tor" executable is now built in src/app/tor rather than src/or/tor. * There are more static libraries than before that you need to build into your application if you want to embed Tor. Rather than maintaining this list yourself, I recommend that you run "make show-libs" to have Tor emit a list of what you need to link.

1 1

Tor port restriction option was removed
by Keifer Bly 05 Jul '18

05 Jul '18

Hello, On the newer versions of tor browser, I have noticed that the “does this computer’s internet connection go through a firewall that only allows certain ports?” was removed. I think this should be put back in the tor browser configuration options for users who are trying from behind firewalls that only allow certain ports. Thanks.

6 14

Proposal: Check Maxmind GeoIP DB before distributing
by Jaskaran Singh 04 Jul '18

04 Jul '18

Hi List, Please have a look at this proposal. Filename: Check-Maxmind-GeoIP-DB-before-distributing.txt Title: Check Maxmind GeoIP-DB before distributing Ticket(s): #26240 Author: Jaskaran Singh Created: June 2018 Status: Open 0. Motivation and Overview We're using Maxmind's (company registered in the US) GeoIP Database, which is not just antithetical to the philosophy that one should not totally rely on a service/software for all needs, but has some serious security repercussions too. Trusting Maxmind's GeoIP Database is dangerous, as it may lead to some possible attacks on the Network. We propose that the Database be checked for integrity before distributing to the users. The whole process of checking for integrity can be assigned to the Directory Authorities (or any trusted systems) who would be responsible for completing it using a script. We should also give a choice to the user whether she wants to use Maxmind's DB or any other DB of her choice, or even to not use any Geo-IP DB at all. 1. Threat Model We assume an adversary that is capable of introducing false information in the Maxmind GeoIP database, either by it's influence over the company or otherwise. The adversary also has enough resources to perform Sybil attack on the network. 2. Attacks on the Network 2.1 Sybil attack under the Radar The Tor Network is constantly monitored for any suspicious spike in nodes, as it may be an indication of an oncoming/undergoing sybil attack. A powerful adversary can coerce Maxmind to map some specific IP address blocks to different countries. This may lead to people/scripts monitoring the network to not feel suspicious about this event, and would result in the adversary staying under the radar. 2.2 False Location indication for a shady node A large percentage of people don't want the exit of their circuits to be located in certain countries where the communication is under surveillance. The powerful adversary knows this as well. Users generally add a line in their config that allows them to not form a circuit through nodes located in those locations. To overcome this, the adversary can coerce Maxmind to alter it's database to map some particular IP's to locations which the user thinks are havens of free speech. 3. Design of the Solution We should check Maxmind database against it's own previous versions. Additionally we should also simply stop using GeoIP database intrinsically for every purpose but still allow users to plug in their own databases through the interface we implement. Perhaps the latter can be introduced as ./configure option for when the user is highly distrustful of Maxmind and wants to use a service she trusts, or doesn't wants to use at all. The two solutions are explained below. 3.1 Checking for integrity Step 1: The Dir Authorities (or any trusted computers) fetch the latest maxmind geoip-db along with its previous versions. Step 2: Tor Nodes' location are checked against the previous versions for any changes. Step 3: All the Dir Authorities perform the above two steps independently of each other. A count of the number of changes in node locations is maintained. If the changes are in significant amount, they are viewed with suspicion, since this can be the preparation of a sybil attack by the adversary. In such a case, the new changes into the database can be discarded. Though, even change in a single node's location is concerning, but it is not easy attribute that change to malice. Sometimes there are genuine reasons for a location to change. Step 4. This database is then distributed to the users. 3.2 Doing away with GeoIP location altogether GeoIP databases are occasionally un-realiable and can be done away with safely. We can provide a ./configure option to the users that enables them to plug in their own trusted service. If the user doesn't have access to a database of her own choice, she can simply choose Maxmind, or not use any database at all. It would remove our dependence from just one database, and diversify our usage. 4. Licensing issues Maxmind has a pretty liberal license when it comes to their database, as summarized below Maxmind - CC BY-SA 4.0 * Copy and redistribute the material in any medium or format * remix, transform, and build upon the material for any purpose, even commercially 5. Dealing with false positives Maxmind calculates geolocation of an IP addr using WHOIS records, Reverse DNS etc. It claims to have precision rate of 99.5% on country level. The other 0.5% is more likely to be those IP addresses for which neither WHOIS record nor Reverse DNS are setup. A very large percentage of Tor Nodes are run from datacenters, which usually have all their records set up. It's highly unlikely for an IP address belonging to a datacenter to be mapped to a wrong location. Hence, false positives would be very few, and can be safely ignored after a simple manual/scripted investigation. -- Jaskaran Veer Singh (jvsg) jvsg1303 at gmail dot com PGP 2814 3FB7 A32D 429B 092E 27F0 8AA3 C532 9E1A 6AD8

4 3

txtorcon 18.0.1
by meejah 03 Jul '18

03 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Unfortunately there was a problem when parsing onion services on Python2, which is fixed by txtorcon 18.0.1 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.0.1 https://github.com/meejah/txtorcon/releases/tag/v18.0.1 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.0.1.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.0.1.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 4c158ee5cfc294a0e20c00dde2a146f04ebe6c6d1c3d7c164c0bd1c56e3d1bc6 dist/txtorcon-18.0.1.tar.gz 2c3f7c768bebf081d0742cdce023b4496bf3b44c423ed7f06bd8d6254e07273e dist/txtorcon-18.0.1-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAls3D3ARHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaadixQgA2rB6Hhx+0wDFxPDA+CubQon2wUxeszDv Q7HGWwqrq/0HhtkaxPgxMxa3TBGumhIlAI1LMhUIGQEl4b4gEPPJddoF8FE7EJKM yECemsJhPcznWEciK/uAIUNXYoT1Np5YwcaMgr8jhrBjYWU4054QJo1U9dtwJfwK 3XI7vItcqtE2x9itF5ggbzOE2tc5v2nh3yyk1DMwNl7+C+LhMBsz26Dqx1ODvl5y e21eFc/2S0IU77S4qx/waSsjAJJBorJGI6HxYeQwLWF4nqE6pHIbePldqJyWAaJH dI+akz5oyFR56/ddzikL1HY4L2xMqJ37c5ISEqzZSU5+3DT3wGTmow== =mZu3 -----END PGP SIGNATURE-----

3 7

documenting reload vs. restart requirements per torrc option
by nusenu 03 Jul '18

03 Jul '18

Hi, I like unbound's documentation with this regards, for example they say in their man page: > The interfaces are not changed on a reload (kill -HUP) > but only on restart. Could we add such information to every torrc option in the manual? background: In relayor I need to reload/restart tor daemons on configuration changes currently I blindly assume reload is fine, because in most cases it is but it comes with the prices of accepting a certain level of error since not all configuration changes can be applied by reloads. To fix this I'd need to have authoritative information about what changes require restarts vs. reloads. [1] https://unbound.net/documentation/unbound.conf.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

man: "IPv6 addresses should be wrapped in square brackets"
by nusenu 01 Jul '18

01 Jul '18

Hi, tor's man page for OutboundBindAddress* options say: > IPv6 addresses should be wrapped in square brackets since it does not throw an error without square brackets: does it make any difference? Previously I forgot the square brackets when generating torrc files with relayor and I would like to document the impact of my bug (if there is any). thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 4