- tor-dev - lists.torproject.org

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 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

Porting TOR Relay Software To Run On Windows
by Keifer Bly 14 Jun '18

14 Jun '18

Hello, So I Retrieved the tor source code from https://github.com/torproject/tor Here’s one thing I have noticed about the network. I have noticed that there is no version of the tor relaying software that will run on Windows. I know Windows isn’t the most secure OS to run a relay off of for a few reasons, however if there was a version of the tor relaying software that was compatible with Windows, this would remove the barrier an quite a number of people who want to run a bridge or relay but do not want to have to go through the hassle of running a Linux virtual machine or something. After just trying to start this project, here is the issue I am already encountering. The tor relaying software is written in C, which I cannot seem to find any compilers for that would work with Windows. Microsoft Visual Studio would be very convenient here, but I have checked and from what I can see it does not support C, but does support C++ and of course C#. Any thoughts on what a good compiler might be to try to port the tor relay software to run as a Command Prompt software on Widows? Let me know your thoughts. Thanks all.

2 1

permission denied when running snowflake-client with debian-tor user
by iry 11 Jun '18

11 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor developers, I met a problem when trying to use the snowflake-client binary extracted from TBB 8.0a8 with the system Tor. Specifically, it seems snowflake-client cannot be run by debian-tor user, regardless of the permissions it is given. I am posting the full steps below. A better formatted version of it can be found here: http://forums.whonix.org/t/replacing-meek-snowflake/5190/18 > Here is the original permission and ownership of snowflake-client: > > user@host:~$ ls -l snowflake-client -rwx------ 1 user user 14160744 > Jun 4 06:17 snowflake-client > > It can be executed by user user: > > user@host:~$ sudo -u user ./snowflake-client 2018/06/04 06:18:21 > > > --- Starting Snowflake Client --- 2018/06/04 06:18:21 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:18:21 Waiting for a "signal" pipe... ^C > > We now change the permission to let it executable by user > debian-tor: > > user@host:~$ sudo chmod 777 snowflake-client > > > user@host:~$ sudo -u debian-tor ./snowflake-client 2018/06/04 > 06:18:43 > > Noticed the permission denied: > > --- Starting Snowflake Client --- 2018/06/04 06:18:43 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:18:43 Waiting for a "signal" pipe... 2018/06/04 06:18:43 open > signal: permission denied > > We now change its ownership to debian-tor:debian-tor: > > user@host:~$ sudo chown debian-tor:debian-tor snowflake-client > user@host:~$ ls -l snowflake-client -rwxrwxrwx 1 debian-tor > debian-tor 14160744 Jun 4 06:17 snowflake-client > > Still, permission denied: > > user@host:~$ sudo -u debian-tor ./snowflake-client 2018/06/04 > 06:19:15 > > > --- Starting Snowflake Client --- 2018/06/04 06:19:15 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:19:15 Waiting for a "signal" pipe... 2018/06/04 06:19:15 open > signal: permission denied > > However, when executing it by user, it works fine: > > user@host:~$ sudo -u user ./snowflake-client 2018/06/04 06:19:22 > > > --- Starting Snowflake Client --- 2018/06/04 06:19:22 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:19:22 Waiting for a "signal" pipe... ^C I didn't find any special requirement for the user who runs snowflake-client from the documentation, so it would be extremely helpful and appreciated if you could share some insights on this problem. :) Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlseXpcACgkQoUtNvG3N 1Tx/fBAAvnl84inklNYJ4N0QRz9X9FAtmTlTTb4mrtW+WM36oaDEFigSZeha7pmw er+oV1hG1SlHf6iel2i6YyUXAi7r6YURqlv0fFtLMaelfAIda/ywEMwVsJ19VHzn qPPEADQVY4c55KuOgkhCMSTxGUn2wXbM+PpFf/WTaZ40gjPOjucUXUxlhwj6X6EX wTBiUEq2yjs4xyWSfgOinFuoPqLG5Hfx/z+1ZSyL2R0yeeK1kSiB5kD90mwfOeKq EM32xbYLy4OmQQ3cABHB2mn0wDaS8E2t22sHXhPNANdJTdM/ztcjI7BZjNMUz1Ig aQEVpLE2yvVQu4O3nyThLnH/b08z4a6oVVE7JQpG9rmLfoFuUbJ6vTF+l6nQTJOY mnkiL6RwGVerm612OXFOLBpHSBbToEX12tqqjC569s/OExcFzHpiiTg22HcOYab/ YSu4zUTX23wRBQhOkBQ7EL+idHGK7lwGN5d0Y45H7cwOoIXwXTu3ff1e6yjuT9Bx Pc+tlkw7vJGB5jhFuW9EYvjrWDklbpR7HZ7TTSkDvGvzXUkAZnCzyBAnePxwQbid 45Vwsn7QCFISsZdXCS53RPoVPbNGcSQTyWn4gv/U37Fb/pZ1LYYAJFcNOl5HB8fl nhXL9D7Mey/79n3hepChBUXpaNeHX9J+7R91A8tUjzz9irmhU8o= =Aie4 -----END PGP SIGNATURE-----

4 3

Debug or a high level of logging still present when using obfs4 bridges
by President Camacho 05 Jun '18

05 Jun '18

Debug or a high level of logging still present in /var/log/tor/log - when using obf4 (or whatever) bridges This is a reminder that this problem continues to exist in Tails 3.7. (and several versions prior) "[warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards." The logging is crazy and consumes several MB per session. ** I have not tested this with plain Tor and/or TBB outside of Tails. ** Nevertheless, this is being posted to tor-dev just in case the problem exists there, too. (and for historical purposes as the problem continues to exist in Tails)

2 1

Removing my relay from the fallback dir list
by Thom Wiggers 05 Jun '18

05 Jun '18

Hi Teor, all, With the DO billing changes (that snuck up on me), I think it's time to retire my main tor relay for the moment. It's on the fallbackdir list though, although it's not currently part of the distributed lists. I've attached a patch that takes it out of the codebase. Maybe it'll appear somewhere else in the future, I'll reconsider it for the fallbackdir list then. Regards, Thom (resent as previous message was sent from address not on list)

1 0

Proposal 292: Mesh-based vanguards
by George Kadianakis 03 Jun '18

03 Jun '18

Hello list, here is the vanguard proposal that supersedes proposal 247. It specifies the newest vanguard design which we've been working on: https://github.com/mikeperry-tor/vanguards FWIW, the above project is still in experimental state and we are expecting to launch it officially in the short term future. Until then, feel free to experiment with it if you feel like it. Check out the proposal and code and let us know if you have any questions or feedback! Thanks! --- Filename: 292-mesh-vanguards.txt Title: Mesh-based vanguards Authors: George Kadianakis and Mike Perry Created: 2018-05-08 Status: Open Supersedes: 247 0. Motivation A guard discovery attack allows attackers to determine the guard node of a Tor client. The hidden service rendezvous protocol provides an attack vector for a guard discovery attack since anyone can force an HS to construct a 3-hop circuit to a relay (#9001). Following the guard discovery attack with a compromise and/or coercion of the guard node can lead to the deanonymization of a hidden service. 1. Overview This document tries to make the above guard discovery + compromise attack harder to launch. It introduces a configuration option which makes the hidden service also pin the second and third hops of its circuits for a longer duration. With this new path selection, we force the adversary to perform a Sybil attack and two compromise attacks before succeeding. This is an improvement over the current state where the Sybil attack is trivial to pull off, and only a single compromise attack is required. With this new path selection, an attacker is forced to do a one or more node compromise attacks before learning the guard node of a hidden service. This increases the uncertainty of the attacker, since compromise attacks are costly and potentially detectable, so an attacker will have to think twice before beginning a chain of node compromise attacks that they might not be able to complete. 1.1. Tor integration The mechanisms introduced in this proposal are currently implemented partially in Tor and partially through an external Python script: https://github.com/mikeperry-tor/vanguards The Python script uses the new Tor configuration options HSLayer2Nodes and HSLayer3Nodes to be able to select nodes for the guard layers. The Python script is tasked with maintaining and rotating the guard nodes as needed based on the lifetimes described in this proposal. In the future, we are aiming to include the whole functionality into Tor, with no need for external scripts. 1.2. Visuals Here is how a hidden service rendezvous circuit currently looks like: -> middle_1 -> middle_A -> middle_2 -> middle_B -> middle_3 -> middle_C -> middle_4 -> middle_D HS -> guard -> middle_5 -> middle_E -> middle_6 -> middle_F -> middle_7 -> middle_G -> middle_8 -> middle_H -> ... -> ... -> middle_n -> middle_n this proposal pins the two middle positions into a much more restricted sets, as follows: -> guard_2A -> guard_3A -> guard_1A -> guard_2B -> guard_3B HS -> guard_3C -> guard_1B -> guard_2C -> guard_3D -> guard_3E -> guard_2D -> guard_3F Additionally, to avoid linkability, we insert an extra middle node after the third layer guard for client side intro and hsdir circuits, and service-side rendezvous circuits. This means that the set of paths for Client (C) and Service (S) side look like this: C - G - L2 - L3 - R S - G - L2 - L3 - HSDIR S - G - L2 - L3 - I C - G - L2 - L3 - M - I C - G - L2 - L3 - M - HSDIR S - G - L2 - L3 - M - R 1.3. Threat model, Assumptions, and Goals Consider an adversary with the following powers: - Can launch a Sybil guard discovery attack against any node of a rendezvous circuit. The slower the rotation period of the node, the longer the attack takes. Similarly, the higher the percentage of the network is compromised, the faster the attack runs. - Can compromise any node on the network, but this compromise takes time and potentially even coercive action, and also carries risk of discovery. We also make the following assumptions about the types of attacks: 1. A Sybil attack is observable by both people monitoring the network for large numbers of new nodes, as well as vigilant hidden service operators. It will require either large amounts of traffic sent towards the hidden service, multiple test circuits, or both. 2. A Sybil attack against the second or first layer Guards will be more noisy than a Sybil attack against the third layer guard, since the second and first layer Sybil attack requires a timing side channel in order to determine success, whereas the Sybil success is almost immediately obvious to third layer guard, since it will be instructed to connect to a cooperating malicious rend point by the adversary. 3. As soon as the adversary is confident they have won the Sybil attack, an even more aggressive circuit building attack will allow them to determine the next node very fast (an hour or less). 4. The adversary is strongly disincentivized from compromising nodes that may prove useless, as node compromise is even more risky for the adversary than a Sybil attack in terms of being noticed. Given this threat model, our security parameters were selected so that the first two layers of guards should be hard to attack using a Sybil guard discovery attack and hence require a node compromise attack. Ideally, we want the node compromise attacks to carry a non-negligible probability of being useless to the adversary by the time they complete. On the other hand, the outermost layer of guards should rotate fast enough to _require_ a Sybil attack. See our vanguard simulator project for a simulation of the above adversary model and a motivation for the parameters selected within this proposal: https://github.com/asn-d6/vanguard_simulator https://github.com/asn-d6/vanguard_simulator/wiki/Optimizing-vanguard-topol… 2. Design When a hidden service picks its guard nodes, it also picks an additional NUM_LAYER2_GUARDS-sized set of middle nodes for its `second_guard_set`, as well as a NUM_LAYER3_GUARDS-sized set of middle nodes for its `third_guard_set`. When a hidden service needs to establish a circuit to an HSDir, introduction point or a rendezvous point, it uses nodes from `second_guard_set` as the second hop of the circuit and nodes from `third_guard_set` as third hop of the circuit. A hidden service rotates nodes from the 'second_guard_set' at a random time between MIN_SECOND_GUARD_LIFETIME hours and MAX_SECOND_GUARD_LIFETIME hours. A hidden service rotates nodes from the 'third_guard_set' at a random time between MIN_THIRD_GUARD_LIFETIME and MAX_THIRD_GUARD_LIFETIME hours. Each node's rotation time is tracked independently, to avoid disclosing the rotation times of the primary and second-level guards. 2.1. Security parameters We set NUM_LAYER2_GUARDS to 4 nodes and NUM_LAYER3_GUARDS to 6 nodes. We set MIN_SECOND_GUARD_LIFETIME to 1 day, and MAX_SECOND_GUARD_LIFETIME to 45 days inclusive, for an average rotation rate of 29.5 days, using the max(X,X) distribution specified in Section 3.3. We set MIN_THIRD_GUARD_LIFETIME to 1 hour, and MAX_THIRD_GUARD_LIFETIME to 48 hours inclusive, for an average rotation rate of 31.5 hours, using the max(X,X) distribution specified in Section 3.3. See Section 3 for more analysis on these constants. 2.2. Path restriction changes In order to avoid information leaks and ensure paths can be built, path restrictions must be loosened. In particular, we allow the following: 1. Nodes from the same /16 and same family for any/all hops 2. Guard nodes can be chosen for RP/IP/HSDIR 3. Guard nodes can be chosen for hop before RP/IP/HSDIR. The first change prevents the situation where paths cannot be built if two layers all share the same subnet and/or node family. It also prevents the the use of a different entry guard based on the family or subnet of the IP, HSDIR, or RP. The second change prevents an adversary from forcing the use of a different entry guard by enumerating all guard-flaged nodes as the RP. The third change prevents an adversary from learning the guard node by way of noticing which nodes were not chosen for the hop before it. 3. Rationale and Security Parameter Selection 3.1. Sybil rotation counts for a given number of Guards The probability of Sybil success for Guard discovery can be modeled as the probability of choosing 1 or more malicious middle nodes for a sensitive circuit over some period of time. P(At least 1 bad middle) = 1 - P(All Good Middles) = 1 - P(One Good middle)^(num_middles) = 1 - (1 - c/n)^(num_middles) c/n is the adversary compromise percentage In the case of Vanguards, num_middles is the number of Guards you rotate through in a given time period. This is a function of the number of vanguards in that position (v), as well as the number of rotations (r). P(At least one bad middle) = 1 - (1 - c/n)^(v*r) Here's detailed tables in terms of the number of rotations required for a given Sybil success rate for certain number of guards. 1.0% Network Compromise: Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen 10% 11 6 4 3 3 2 2 2 2 1 1 15% 17 9 6 5 4 3 3 2 2 2 2 25% 29 15 10 8 6 5 4 4 3 3 2 50% 69 35 23 18 14 12 9 8 7 6 5 60% 92 46 31 23 19 16 12 11 10 8 6 75% 138 69 46 35 28 23 18 16 14 12 9 85% 189 95 63 48 38 32 24 21 19 16 12 90% 230 115 77 58 46 39 29 26 23 20 15 95% 299 150 100 75 60 50 38 34 30 25 19 99% 459 230 153 115 92 77 58 51 46 39 29 5.0% Network Compromise: Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen 10% 3 2 1 1 1 1 1 1 1 1 1 15% 4 2 2 1 1 1 1 1 1 1 1 25% 6 3 2 2 2 1 1 1 1 1 1 50% 14 7 5 4 3 3 2 2 2 2 1 60% 18 9 6 5 4 3 3 2 2 2 2 75% 28 14 10 7 6 5 4 4 3 3 2 85% 37 19 13 10 8 7 5 5 4 4 3 90% 45 23 15 12 9 8 6 5 5 4 3 95% 59 30 20 15 12 10 8 7 6 5 4 99% 90 45 30 23 18 15 12 10 9 8 6 10.0% Network Compromise: Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen 10% 2 1 1 1 1 1 1 1 1 1 1 15% 2 1 1 1 1 1 1 1 1 1 1 25% 3 2 1 1 1 1 1 1 1 1 1 50% 7 4 3 2 2 2 1 1 1 1 1 60% 9 5 3 3 2 2 2 1 1 1 1 75% 14 7 5 4 3 3 2 2 2 2 1 85% 19 10 7 5 4 4 3 3 2 2 2 90% 22 11 8 6 5 4 3 3 3 2 2 95% 29 15 10 8 6 5 4 4 3 3 2 99% 44 22 15 11 9 8 6 5 5 4 3 The rotation counts in these tables were generated with: def num_rotations(c, v, success): r = 0 while 1-math.pow((1-c), v*r) < success: r += 1 return r 3.2. Rotation Period As specified in Section 1.2, the primary driving force for the third layer selection was to ensure that these nodes rotate fast enough that it is not worth trying to compromise them, because it is unlikely for compromise to succeed and yield useful information before the nodes stop being used. From the table in Section 3.1, with NUM_LAYER2_GUARDS=4 and NUM_LAYER3_GUARDS=6, it can be seen that this means that the Sybil attack on layer3 will complete with 50% chance in 12*31.5 hours (15.75 days) for the 1% adversary, ~4 days for the 5% adversary, and 2.62 days for the 10% adversary. Since rotation of each node happens independently, the distribution of when the adversary expects to win this Sybil attack in order to discover the next node up is uniform. This means that on average, the adversary should expect that half of the rotation period of the next node is already over by the time that they win the Sybil. With this fact, we choose our range and distribution for the second layer rotation to be short enough to cause the adversary to risk compromising nodes that are useless, yet long enough to require a Sybil attack to be noticeable in terms of client activity. For this reason, we choose a minimum second-layer guard lifetime of 1 day, since this gives the adversary a minimum expected value of 12 hours for during which they can compromise a guard before it might be rotated. If the total expected rotation rate is 29.5 days, then the adversary can expect overall to have 14.75 days remaining after completing their Sybil attack before a second-layer guard rotates away. 3.3. Rotation distributions In order to skew the distribution of the third layer guard towards higher values, we use max(X,X) for the distribution, where X is a random variable that takes on values from the uniform distribution. Here's a table of expectation (arithmetic means) for relevant ranges of X (sampled from 0..N-1). The table was generated with the following python functions: def ProbMinXX(N, i): return (2.0*(N-i)-1)/(N*N) def ProbMaxXX(N, i): return (2.0*i+1)/(N*N) def ExpFn(N, ProbFunc): exp = 0.0 for i in xrange(N): exp += i*ProbFunc(N, i) return exp The current choice for second-layer guards is noted with **, and the current choice for third-layer guards is noted with ***. Range Min(X,X) Max(X,X) 40 12.84 26.16 41 13.17 26.83 42 13.50 27.50 43 13.84 28.16 44 14.17 28.83 45 14.50 29.50** 46 14.84 30.16 47 15.17 30.83 48 15.50 31.50*** The Cumulative Density Function (CDF) tells us the probability that a guard will no longer be in use after a given number of time units have passed. Because the Sybil attack on the third node is expected to complete at any point in the second node's rotation period with uniform probability, if we want to know the probability that a second-level Guard node will still be in use after t days, we first need to compute the probability distribution of the rotation duration of the second-level guard at a uniformly random point in time. Let's call this P(R=r). For P(R=r), the probability of the rotation duration depends on the selection probability of a rotation duration, and the fraction of total time that rotation is likely to be in use. This can be written as: P(R=r) = ProbMaxXX(X=r)*r / \sum_{i=1}^N ProbMaxXX(X=i)*i or in Python: def ProbR(N, r, ProbFunc=ProbMaxXX): return ProbFunc(N, r)*r/ExpFn(N, ProbFunc) For the full CDF, we simply sum up the fractional probability density for all rotation durations. For rotation durations less than t days, we add the entire probability mass for that period to the density function. For durations d greater than t days, we take the fraction of that rotation period's selection probability and multiply it by t/d and add it to the density. In other words: def FullCDF(N, t, ProbFunc=ProbR): density = 0.0 for d in xrange(N): if t >= d: density += ProbFunc(N, d) # The +1's below compensate for 0-indexed arrays: else: density += ProbFunc(N, d)*(float(t+1))/(d+1) return density Computing this yields the following distribution for our current parameters: t P(SECOND_ROTATION <= t) 1 0.03247 2 0.06494 3 0.09738 4 0.12977 5 0.16207 10 0.32111 15 0.47298 20 0.61353 25 0.73856 30 0.84391 35 0.92539 40 0.97882 45 1.00000 This CDF tells us that for the second-level Guard rotation, the adversary can expect that 3.3% of the time, their third-level Sybil attack will provide them with a second-level guard node that has only 1 day remaining before it rotates. 6.5% of the time, there will be only 2 day or less remaining, and 9.7% of the time, 3 days or less. Note that this distribution is still a day-resolution approximation. 4. Security concerns and mitigations 4.1. Mitigating fingerprinting of new HS circuits By pinning the middle nodes of rendezvous circuits, we make it easier for all hops of the circuit to detect that they are part of a special hidden service circuit with varying degrees of certainty. The Guard node is able to recognize a Vanguard client with a high degree of certainty because it will observe a client IP creating the overwhelming majority of its circuits to just a few middle nodes in any given 31.5 day time period. The middle nodes will be able to tell with a variable certainty that depends on both its traffic volume and upon the popularity of the service, because they will see a large number of circuits that tend to pick the same Guard and Exit. The final nodes will be able to tell with a similar level of certainty that depends on their capacity and the service popularity, because they will see a lot of handshakes that all tend to have the same second hops. The most serious of these is the Guard fingerprinting issue. When proposal 254-padding-negotiation is implemented, services that enable this feature should use those padding primitives to create fake circuits to random middle nodes that are not their guards, in an attempt to look more like a client. Additionally, if Tor Browser implements "virtual circuits" based on SOCKS username+password isolation in order to enforce the re-use of paths when SOCKS username+passwords are re-used, then the number of middle nodes in use during a typical user's browsing session will be proportional to the number of sites they are viewing at any one time. This is likely to be much lower than one new middle node every ten minutes, and for some users, may be close to the number of Vanguards we're considering. This same reasoning is also an argument for increasing the number of second-level guards beyond just two, as it will spread the hidden service's traffic over a wider set of middle nodes, making it both easier to cover, and behave closer to a client using SOCKS virtual circuit isolation. 5. Default vs optional behavior We suggest this torrc option to be optional because it changes path selection in a way that may seriously impact hidden service performance, especially for high traffic services that happen to pick slow guard nodes. However, by having this setting be disabled by default, we make hidden services who use it stand out a lot. For this reason, we should in fact enable this feature globally, but only after we verify its viability for high-traffic hidden services, and ensure that it is free of second-order load balancing effects. Even after that point, until Single Onion Services are implemented, there will likely still be classes of very high traffic hidden services for whom some degree of location anonymity is desired, but for which performance is much more important than the benefit of Vanguards, so there should always remain a way to turn this option off. In the meantime, a reference implementation is available at: https://github.com/mikeperry-tor/vanguards/blob/master/vanguards/vanguards.… Appendix A: Full Python program for generating tables in this proposal #!/usr/bin/python import math ############ Section 3.1 ################# def num_rotations(c, v, success): i = 0 while 1-math.pow((1-c), v*i) < success: i += 1 return i def rotation_line(c, pct): print " %2d%% %6d%6d%6d%6d%6d%6d%6d%6d%6d%6d%8d" % \ (pct, num_rotations(c, 1, pct/100.0), num_rotations(c, 2, pct/100.0), \ num_rotations(c, 3, pct/100.0), num_rotations(c, 4, pct/100.0), num_rotations(c, 5, pct/100.0), num_rotations(c, 6, pct/100.0), num_rotations(c, 8, pct/100.0), num_rotations(c, 9, pct/100.0), num_rotations(c, 10, pct/100.0), num_rotations(c, 12, pct/100.0), num_rotations(c, 16, pct/100.0)) def rotation_table_31(): for c in [1,5,10]: print "\n %2.1f%% Network Compromise: " % c print " Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen" for success in [10,15,25,50,60,75,85,90,95,99]: rotation_line(c/100.0, success) ############ Section 3.3 ################# def ProbMinXX(N, i): return (2.0*(N-i)-1)/(N*N) def ProbMaxXX(N, i): return (2.0*i+1)/(N*N) def ExpFn(N, ProbFunc): exp = 0.0 for i in xrange(N): exp += i*ProbFunc(N, i) return exp def ProbUniformX(N, i): return 1.0/N def ProbR(N, r, ProbFunc=ProbMaxXX): return ProbFunc(N, r)*r/ExpFn(N, ProbFunc) def FullCDF(N, t, ProbFunc=ProbR): density = 0.0 for d in xrange(N): if t >= d: density += ProbFunc(N, d) # The +1's below compensate for 0-indexed arrays: else: density += ProbFunc(N, d)*float(t+1)/(d+1) return density def expectation_table_33(): print "\n Range Min(X,X) Max(X,X)" for i in xrange(10,49): print " %2d %2.2f %2.2f" % (i, ExpFn(i,ProbMinXX), ExpFn(i, ProbMaxXX)) def CDF_table_33(): print "\n t P(SECOND_ROTATION <= t)" for i in xrange(1,46): print " %2d %2.5f" % (i, FullCDF(45, i-1)) ########### Output ############ # Section 3.1 rotation_table_31() # Section 3.3 expectation_table_33() CDF_table_33() ---------------------- 1. https://onionbalance.readthedocs.org/en/latest/design.html#overview

3 2

proposal: new log severity level: trace
by Simon 01 Jun '18

01 Jun '18

Hello tor developers, I've had limited contact with nickm and dmr and I was encouraged to solicit interest and comments via the tor-dev mailing list... I'm interested in contributing a new feature to little-t tor in the form of a new log severity level called 'trace'. Currently there are 5 severity levels [1]; debug, info, notice, warn, and err. trace would be more verbose than debug, and trace function calls at runtime. It would also be configurable -- perhaps by environment variables and/or command line options -- regarding which functions get traced and when at runtime. Because introducing function level tracing likely also introduces a performance penalty, I'm suggesting that this feature would be optionally compiled in at build time. The use of the new log severity level 'trace' would be for new developers to better comprehend the tor source code by giving them a further resource -- in addition to the source code, tests, documentation, and IRC chat -- to learn from. The debug log will be more useful in the context of the function call tree, and function usage is easier to grasp than battling through the ~ 165k LOC. In addition, any developer who likes to debug via the log files will appreciate having the extra function call tree context. I have a basic, generic working proof of concept which produces output when running tor. Here is a snippet of the output: ... T125580 + directory_initiate_command_routerstatus_rend() { // #63 T125580 + node_get_by_id() { // #278 T125580 } T125580 + directory_initiate_command_rend() { // #63 T125580 + directory_command_should_use_begindir() { // #63 T125580 + fascist_firewall_allows_address_or() { // #5814 T125580 + compare_tor_addr_to_addr_policy() { // #6009 T125580 } T125580 } T125580 + directory_fetches_from_authorities() { // #126 T125580 + server_mode() { // #6859 T125580 } T125580 + router_my_exit_policy_is_reject_star() { // #128 T125580 + router_get_my_routerinfo() { // #130 T125580 } T125580 } T125580 } T125580 } ... Explanation of the snippet: '<thread ID> <indent> + <function>() { #<calls>' means <function> has been called <calls> times. <indent> represents the function call tree indent level. '}' means the function returns. One can introduce extra info not implemented yet such as timestamps, calling parameters, return value, and extra info specified by the developer. Regarding regular tor log output: This could be mixed in with the trace output, e.g.: ... T125580 + router_get_my_routerinfo() { // #130 T125580 - info 1 of 2: abc <-- non trace T125580 - info 1 of 2: def <-- non trace T125580 } ... This email is mainly to determine if there is a interest for such a tor feature to be implemented further. AFAIK it does not seem to be implemented already and does not seem to exist as a documented helpful tool [2]. And I'm not aware of a third party tool which would 'just work' with tor. Strategies for implementing the function trace: I'll now discuss the strategies which I know about for implementing the function trace, including the one I want to use: 1. Manual instrumentation: Here each function is manually instrumented in the tor source code with entry and exit macros. This is time consuming and error prone. And it can make the source code less readable. 2. Using the gcc -finstrument-functions [3] command line switch: There are many examples [4] [5] of using this to generate a runtime function call tree. But this mechanism causes each function to make two extra calls whether you want that or not, so performance might be poor. Plus getting hold of the actual function names and displaying them can be tricky; only the function address is given to the entry and exit functions. Also, there is no way to access the function parameters or return value. 3. Using the llvm xray [6] [7] feature: This was originally contributed to llvm by Google but is more designed for inspecting very high performance call trees in a production environment. A sort of dtrace for user level functions. However, it also doesn't log function parameters or the return value AFAIK. And logging happens via an intermediate binary file which must get converted to something ascii / human friendly. This also means it's tricky to mix in the existing tor log output, for one nice seemless log file. 4. Using gcc compile to assembler command line switch: AFAIK this technique was first developed by myself. The idea is to replace gcc with an own script which pretends to be gcc and invokes the real gcc after making subtle changes. If a makefile tries to compile a .c file to a .o file then the pretend gcc will change the behaviour so that an intermediate assembler file will be generated. However, the assembler file gets changed so that every function call becomes an indirect function call via a pointer. This means we can change the pointer to execute either the original function (with the overhead of an indirect function call), or a wrapper function with the same declaration. The wrapper function has access to all the function parameters and return value, can log the entry and exit, while calling the original function which got wrapped. I have chosen implementation strategy #4 because it provides the most flexibility without changing any existing source code or makefile. A limitation is that it only works currently with gcc on Intel. However, msvc & llvm might have a similar compile to assembly feature. And in theory the same technique could be implemented for non-Intel chips if they have an indirect call assembly instruction. An interesting side effect of strategy #4 is that it could possibly be used to enhance testing in two ways: 1. If the test is for a particular function or set of functions then trace could be preconfigured to provide more detailed output for just those functions, and any functions they call. 2. The indirect function pointer can be changed at runtime if desired to create a kind of general purpose function mocking facility for testing. However, I believe tor tests already do their own mocking. Here is an example of the proof of concept auto generated C code for the function firewall_is_fascist_or(): extern unsigned long long cwrap_count_call_firewall_is_fascist_or; extern int (* cwrap_indirect_orig_firewall_is_fascist_or) (void); extern int (* cwrap_indirect_wrap_firewall_is_fascist_or) (void); extern int (* cwrap_indirect_mock_firewall_is_fascist_or) (void); static int cwrap_wrap_firewall_is_fascist_or (void) { cwrap_count_call_firewall_is_fascist_or ++; // todo: add per binary/file/function verbosity checking // todo: show function parameters for simple types, e.g. foo=123, bar=7 if (cwrap_count_call_firewall_is_fascist_or <= 10000) cwrap_log(1, "+ firewall_is_fascist_or() { // #%llu\n", cwrap_count_call_firewall_is_fascist_or); int cwrap_result = (* cwrap_indirect_orig_firewall_is_fascist_or)(); if (cwrap_count_call_firewall_is_fascist_or <= 10000) cwrap_log(-1, "}\n"); // todo: show return value for simple types return cwrap_result; } So the pretend gcc doubles the number of functions, creating a 'wrap' version of each regular function. While the changed assembler files change the assembler call function into an indirect call function which uses the newly created indirect function pointer. In theory the makefile just works and is unmodified. However, extra files get created during make. Looking forward to comments, suggestions, and/or votes for and against, even if it's only to point out that something with similar functionality exists already. -- Simon [1] https://www.torproject.org/docs/tor-manual.html.en [2] https://gitweb.torproject.org/tor.git/tree/doc/HACKING/HelpfulTools.md [3] https://stackoverflow.com/questions/6176284/why-doesnt-finstrument-function… [4] https://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-w… [5] https://mcuoneclipse.com/2015/04/04/poor-mans-trace-free-of-charge-function… [6] https://www.youtube.com/watch?reload=9&v=jyL-__zOGcU [7] https://llvm.org/docs/XRay.html

1 0

[release] Onionoo 6.0-1-14-0, ExoneraTor 2.1.0, metrics-web 1.1.0
by iwakeh 31 May '18

31 May '18

Hi there! three new releases are available: https://dist.torproject.org/onionoo/6.0-1.14.0/ https://dist.torproject.org/exonerator/2.1.0/ https://dist.torproject.org/metrics-web/1.1.0/ This is the second batch of releases of Metrics products, which now use a to a better performing JSON processing library. Other details can be found in the respective change logs [0], [1], and [2]. All releases are already deployed on all respective tp.o instances. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-6.0-1… [1] https://gitweb.torproject.org/exonerator.git/tree/CHANGELOG.md?h=exonerator… [2] https://gitweb.torproject.org/metrics-web.git/tree/CHANGELOG.md?h=metrics-w… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

(no subject)
by abhinav chowdary 31 May '18

31 May '18

Iam in or out

2 2

(no subject)
by abhinav chowdary 30 May '18

30 May '18

Join me pls

1 0

(no subject)
by abhinav chowdary 30 May '18

30 May '18

Join to u r org

1 0

(no subject)
by abhinav chowdary 30 May '18

30 May '18

Hai need to be member

1 0

[TSoP 2018] Ahmia status update #1
by Stelios Barberakis 27 May '18

27 May '18

Hello all, This is an update report for ahmia project, as part of the Tor Summer of Privacy 2018. The first two weeks I have been working on updating and slightly improving the codebase of *ahmia-site, ahmia-index, ahmia-crawler* subprojects. More specifically: * Updating python packages and adding python3 support (default version from now on), to have a clean building process. * Prettifying the code towards pep8 compliance * Fixing some minor issues, like unresolved references, substitude deprecated methods, etc * Separating code from configuration by introducing environment variables approach through python-decouple. The already pushed commits can be found at the corresponding github repositories [1] <https://github.com/ahmia/ahmia-site/commits/tsop18>, [2 <https://github.com/ahmia/ahmia-crawler/commits/tsop18>], [3 <https://github.com/ahmia/ahmia-index/commits/tsop18>]. I am going to discuss tomorrow with the mentors and anyone else that might be interested, on #ahmia channel at OFTC, on how to proceed (what to implement next). Best Regards, Stelios -- PGP key: http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xBF6EA91B7CBE3998

2 1

[release] CollecTor 1.6.0, metrics-lib 2.4.0
by iwakeh 26 May '18

26 May '18

Hi there! two new releases are available: https://dist.torproject.org/collector/1.6.0/ https://dist.torproject.org/metrics-lib/2.4.0/ This is the start of a series of releases for all Metrics products, which are a move to a better performing JSON processing library. Other details can be found in the respective change logs [1] and [2]. The CollecTor release is already deployed on all CollecTor tp.o instances. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [1] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [2] https://gitweb.torproject.org/metrics-lib.git/tree/CHANGELOG.md?h=metrics-l… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Abort in test_bridges.c
by Gisle Vanem 24 May '18

24 May '18

Running 'test.exe bridges/clear_bridge_list' causes this assertion: bridges/clear_bridge_list: May 23 17:12:53.714 [err] tor_assertion_failed_(): Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed; AFAICS, since 'sweep_bridge_list()' caused all entries in 'bridgelist' to get deleted, an index of zero is illegal. Don't ask me why. And since 'smartlist_get(bridgelist,0)' should be compiled with '-DDEBUG_SMARTLIST' in all tests/*.c sources. No? I'm on Win-10, tor.exe + libs was built with MSVC 2017. -- --gv

2 1