- tor-dev - lists.torproject.org

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 02 Jul '18

02 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 02 Jul '18

02 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

minor website update request: have the tor-relay guide ready for Ubuntu 18.04
by nusenu 28 Jun '18

28 Jun '18

Hi, I wanted to have the tor relay guide ready for the new Ubuntu LTS version 18.04 nearly at the same time when it is released. Thanks to the torproject debian maintainer we already have packages for bionic. Basically the only thing that is missing is the website update to include the new distro for the sources.list generator. For that I submitted an update on trac [1] a few days ago. From my personal experience, my website update requests (also trivial ones) take about two months to get committed, it would be great if we could speed things up for this specific request to have the relay guide ready for the new Ubuntu LTS nearly at the same time when the release is happening. (I won't be bothering you with non-tor-relay-guide related website updates anymore). thanks, nusenu [1] https://trac.torproject.org/projects/tor/ticket/25888 -- https://mastodon.social/@nusenu twitter: @nusenu_

3 4

txtorcon 18.0.0
by meejah 26 Jun '18

26 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm very pleased to announce txtorcon 18.0.0. This introduces a new Onion services API (including v3 support) and a bunch of other changes (including a new versioning scheme). Starting now, versioning is more Twisted-like: the first number is the year, the second is the "release in that year" and the minor number is for bug-fixes. No backwards-incompatible changes will occur without first being deprecated for at least one full release (this has been my practice anyway, so using "SemVer" no longer made sense). The documentation is updated with all the new Onion APIs, and a full list of changes follows: * await_all_uploads= option when creating Onions * properly re-map progress percentages (including descriptor uploads) * properly wait for all event-listeners during startup * re-work how TorState.event_map works, hopefully reducing reproducible-builds issues * TorControlProtocol.add_event_listener and TorControlProtocol.remove_event_listener are now async methods returning Deferred -- they always should have been; new code can now be assured that the event-listener change is known to Tor by awaiting this Deferred. * TorControlProtocol.get_conf_single method added, which gets and returns (asynchronously) a single GETCONF key (instead of a dict) * also TorControlProtocol.get_info_single similar to above * if Tor disconnects while a command is in-progress or pending, the .errback() for the corresponding Deferred is now correctly fired (with a TorDisconnectError) * tired: get_global_tor() (now deprecated) wired: txtorcon.get_global_tor_instance * Adds a comprehensive set of Onion Services APIs (for all six variations). For non-authenticated services, instances of IOnionService represent services; for authenticated services, instances of IAuthenticatedOnionClients encapsulated named lists of clients (each client is an instance implementing IOnionService). * Version 3 ("Proposition 279") Onion service support (same APIs) as released in latest Tor * Four new methods to handle creating endpoints for Onion services (either ephemeral or not and authenticated or not): * Tor.create_authenticated_onion_endpoint * Tor.create_authenticated_filesystem_onion_endpoint * Tor.create_onion_endpoint * Tor.create_filesystem_onion_endpoint * see create_onion for information on how to choose an appropriate type of Onion Service. * Tor.create_onion_service to add a new ephemeral Onion service to Tor. This uses the ADD_ONION command under the hood and can be version 2 or version 3. Note that there is an endpoint-style API as well so you don't have to worry about mapping ports yourself (see below). * Tor.create_filesystem_onion_service to add a new Onion service to Tor with configuration (private keys) stored in a provided directory. These can be version 2 or version 3 services. Note that there is an endpoint-style API as well so you don't have to worry about mapping ports yourself (see below). * Additional APIs to make visiting authenticated Onion services as a client easier: * Tor.add_onion_authentication will add a client-side Onion service authentication token. If you add a token for a service which already has a token, it is an error if they don't match. This corresponds to HidServAuth lines in torrc. * Tor.remove_onion_authentication will remove a previously added client-side Onion service authentication token. Fires with True if such a token existed and was removed or False if no existing token was found. * Tor.onion_authentication (Python3 only) an async context-manager that adds and removes an Onion authentication token (i.e. adds in on __aenter__ and removes it on __aexit__). Allows code like: * onion services support listening on Unix paths. * make sure README renders on Warehouse/PyPI You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.0.0 https://github.com/meejah/txtorcon/releases/tag/v18.0.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.0.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.0.0.tar.gz.asc ...and now also available 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 818f6ec96a9d60cb4cb47d98f2c843c7a83004c25be07daafeb9eb9aaed74f7c dist/txtorcon-18.0.0.tar.gz d2f91a3770d7fd8c46372e5573bb23ab65c1be33f12e9ff4ac4af24e6f5f6069 dist/txtorcon-18.0.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlsogE4RHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaadF6gf+OZ/SIZi9C2Ohce7R/ZVpw4F7qI/2ESds T4TmAhjoc2CzGwSp+Zcxcs2RUw5Xt1lim9ckLSRBZL+agXmmarvzV6Uc3DFrL8rZ 6JUcjzd0WNYHzXXCIM11WG47/hIqRQ0gAYI9NnEF5ELJ/B03tDmXMT4KgMnnYJj2 lvewxN+2QvthCDme5lfNanDP16VGyRXKIxdKpulZfWBZ7vPe1xYgF3jpPXzkRxYu /kKMi/BudgruiCBdYrAUa+tIqKq7H482rczszBVSvMDZuLlhPozixPEWY/rNTg4r 4d2dCz6HlQqaBkpAnB4P6udGlWfeRkRnWOO0bIPPv5FlCcmNLUKkTQ== =jH7N -----END PGP SIGNATURE-----

1 0

Dealing with DNS requests by Tor unaware programs
by procmem 25 Jun '18

25 Jun '18

Hello. We are trying to safely deal with programs that don't support Tor DNS stream isolation so they don't pollute TransPort. I've read the manual but it's not clear if you enable IsolateClientProtocol by default. Is that the case? Also if the former is enabled, do you have IsolateDest enabled for DnsPort or not? If no then what is the rationale for this decision? Thanks.

3 2

DoH over non-HTTPS onion v3
by nusenu 24 Jun '18

24 Jun '18

Hi, this is just a short heads-up. I'm currently tinkering about how we could improve DNS security and privacy for tor clients. My idea write-up is not done yet but since the IETF DoH WG [1] is proceeding towards their next steps I wanted to move now before it might be to late and let you know that I might ask them if they want to allow non-HTTPS uris in the case of onion v3 addresses (currently HTTPS is required). This might be handy for TB in the future. If you have objections let me know. I also reached out to Seth Schoen and asked him about his efforts to make onion v3 DV certificates acceptable to the CA/Browser Forum (if that is possible then the HTTPS requirement isn't a problem for DoH over onion v3). regards, nusenu [1] https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

DNS resolution isolation in Tor Browser
by nusenu 15 Jun '18

15 Jun '18

Hi, I haven't been able to answer this question by looking into the Tor Browser design document, maybe you have an answer: imagine you have two tabs in Tor Browser: 1: torproject.org (circuit A) embeds some youtube.com content 2: google.com (circuit B) embeds some youtube.com content it will route the TCP connection via two distinct circuits (A and B) as described in the design document [1] Will DNS resolution be isolated using the same logic? torproject.org and youtube.com will be resolved via circuit A and google.com and youtube.com will be resolved via circuit B Is that correct? thanks! [1] https://www.torproject.org/projects/torbrowser/design/#identifier-linkabili… -- https://mastodon.social/@nusenu twitter: @nusenu_

3 4

More on Fingerprinting Unlinkability ~ Summer of Privacy
by Vafa Andalibi 14 Jun '18

14 Jun '18

Hello Everyone! I’m Vafa and I’m happy to announce that I’m going to work on a project related to Cross-Origin Fingerprinting Unlinkability in Tor Summer of Privacy (late arrival!), this would be my first contribution to the great Tor project and I will i will try my best to do it well. In this project I’m going to use the results of one of my previous works about web-based browser fingerprinting and I hope that I would be able to extend and employ that to possibly address an issue, i.e. possible paradoxical configurations, regarding sophisticated randomization in the attributes and properties the uniforming of which are difficult. My previously implemented tool [1] builds a model over (semi)-legitimate database of browser fingerprinting and uses this model in three different modes, all of which might come handy or be a good start for this project. In this project, Arthur is going to be my mentor, and the above-mentioned previous work was under supervision of Prof. Jean Camp. I would be happy to answer further questions and discuss things that are (un)intentionally omitted here. Cheers! [1] http://paradoxcatcher.readthedocs.io/en/latest/

1 0