- tor-dev - lists.torproject.org

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