- tor-dev - lists.torproject.org

Support for clients using shutdown(SHUT_WR)
by Rob Jansen 16 Apr '19

16 Apr '19

Hello! I'm in the process of re-writing Shadow's traffic generation tool called tgen [0], which now depends on shutdown() for two communicating tgen nodes to inform each other that they have no more to send (i.e. to perform graceful connection shutdowns). The shutdown() functionality is useful now that tgen uses Markov models to generate more realistic Tor traffic [1]. Currently, it appears that when the tor client receives a FIN on the AP connection (because the tgen client calls shutdown(SHUT_WR)), the tor client sends a RELAY_END cell to the exit relay to instruct it to close() the exit TCP connection to the server. The behavior I expected was something more like what is described in tor-spec in Section 6.3 (search for "RELAY_FIN") [2], where the tor client sends a RELAY_FIN cell to the exit to instruct the exit to perform a shutdown(SHUT_WR) on the exit TCP connection to the server. Is there any plan to support shutdown(SHUT_WR) using RELAY_FIN cells now that Tor is itself using shutdown()? (I didn't see any tickets about it after a brief search.) Thanks! Peace, love, and positivity, Rob [0] https://github.com/shadow/tgen [1] https://tmodel-ccs2018.github.io/ [2] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt

2 1

ICLab testing of default bridges
by David Fifield 11 Apr '19

11 Apr '19

At the anti-censorship meeting today you mentioned talking to ICLab about testing the default bridges. I believe that ICLab is already testing at least a portion of the default bridges; they may have data that you just have to ask for. OONI and ICLab test the default bridges as a result of my, Lynn's, and Qi's asking them to while we were studying default bridge blocking. The data exist but we never carefully analyzed them. You can see what little analysis we did at https://arxiv.org/abs/1709.08718 Figure 1 and Section 5.9. The data we used is in data/iclab/tor_jsons.tar.bz2 in https://repo.eecs.berkeley.edu/git-anon/users/fifield/proxy-probe-paper.git. It's a lot of JSON files that have TCP connect, TLS certificate fetch, HTTP fetch, and TCP traceroute for each destination. We sent them the list of bridges in September 2016 and they started measuring shortly after that. The most recent update to the bridge list we sent them was in August 2017 for https://bugs.torproject.org/23166.

1 0

Scripts and VMs for helping people setup a relay or bridge
by Alessandro Fiori 09 Apr '19

09 Apr '19

Hi, since i have released some Docker images for help people to run their own service or relays, i'm releasing some Virtualbox images and scripts for who want to run their relays. Virtual machines are in importable OVA format, and are based on Ubuntu Command Line Install, for a very light-weight system. I have released, for now, a Script and Virtual Machine for Tor middle relay, next days i will release bridge scripts for bridge with pluggable transports pre-installed. The Script repository is located here: https://github.com/randomtable/ChimeraOS/tree/master/Scripts The Virtual Machines repository is located here: https://github.com/randomtable/ChimeraOS/tree/master/VMs I'm writing to "dev" mailing list, because a very expert eye is always needed. I hope this can be useful for everyone. Alessandro Fiori

2 1

Re: [tor-dev] New revision: Proposal 295: Using ADL for relay cryptography (solving the crypto-tagging attack)
by Jeff Burdges 08 Apr '19

08 Apr '19

If I understand, proposal 295 looks similar to either BEAR or LION from the LIONNESS. I vaguely recall both BEAR and LION being "broken" in some setting, although I cannot site the paper. Anyone? I suppose the BEAR and LION break originates from using them for authentication while proposal 295’s separate SVer function fixes this? Jeff

1 1

Tor Directory Meta-Format + Line Wrapping?
by Iain Learmonth 03 Apr '19

03 Apr '19

Hi, Looking at the specification for the Tor directory protocol's meta-format, it has some text on line wrapping: > When line wrapping, implementations MUST wrap lines > at 64 characters. Upon decoding, implementations MUST > ignore and discard all linefeed characters. I can't work out how an implementation is meant to know if a linefeed character is meant to be for line-wrapping or if it's meant to be the end of a keyword line. Are there any implementations that actually do line wrapping? Thanks, Iain.

3 2

Re: [tor-dev] Docker images for help people to run Tor (teor) (teor)
by Alessandro Fiori 01 Apr '19

01 Apr '19

Hi, thanks for your support! I've modified Dockerfiles to properly install the right Tor version and starting two relays with both scripts. The images have been released on Docker Hub too. Next step for me is preparing script and image for easily setting up a bridge. Since all containers created are Linux containers, and since all my Dockerfiles are "one shot configurations", I will release bash scripts soon. I will contact the community very soon for more advices on relays, and promote-review the project (since the project is newborn, I want to spread for find issues and fix them). If you want to control all the released code and images, the two principal repositories are: https://github.com/randomtable/ChimeraOS https://hub.docker.com/u/alessandrofiori Many thanks Il giorno lun 1 apr 2019 alle ore 14:00 < tor-dev-request(a)lists.torproject.org> ha scritto: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Docker images for help people to run Tor (teor) (teor) > 2. Next Network Team Meeting Time (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Apr 2019 12:57:35 +1000 > From: teor <teor(a)riseup.net> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Docker images for help people to run Tor (teor) > Message-ID: <EBC8EE49-155E-4B26-BC19-E2B0642FF2DB(a)riseup.net> > Content-Type: text/plain; charset="utf-8" > > Hi, > > > On 1 Apr 2019, at 07:55, Alessandro Fiori <alefiori3(a)gmail.com> wrote: > > > > Hi, > > I would like to share with the community some tests I've made for > setting up a "swarm" of Tor relays. > > > > I setted up 3 exit relays and 3 middle relays on the same IPv4 address, > to make some testing, and the entire swarm works like a charm. > > > > Due to Tor limitation, I have decided to build a template for preparing > the cluster, and upload it to GitHub. > > > > You can find the example mini-cluster here: > > https://github.com/randomtable/ChimeraOS/tree/master/TorSwarm > > > > I have tested the exit capabilities on another network with different > public IP address. > > > > All the relays have published their own descriptors, I have prepared the > containers as a single, separated machines. > > > > The process is different from preparing a single relay, because of > Docker build process. > > > > I have disabled caching during the cluster process, so i have been able > to modify torrc without issues. > > > > Because its very interesting, attached to this e-mail there is the > console Logs from the 6 relays. > > > > All containers are read-only, so the entire relay will destroy at the > end of session. > > > > I hope this can be useful. > > Tor clients will only see 2 of your 6 relays, because the Tor directory > authorities only publish 2 relays per IPv4 address. > > Also, please use the deb.torproject.org repositories to get the latest > version of tor: > Mar 31 19:57:08.000 [warn] Please upgrade! This version of Tor (0.3.3.9) > is not recommended, according to the directory authorities. Recommended > versions are: > 0.2.9.15,0.2.9.16,0.2.9.17,0.3.4.10,0.3.4.11,0.3.5.7,0.3.5.8,0.4.0.1-alpha,0.4.0.2-alpha,0.4.0.3-alpha > > https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntu > > T >

1 0

Next Network Team Meeting Time
by teor 01 Apr '19

01 Apr '19

Hi, The next network team meeting is at 2300 UTC on Tuesday 2 April. Here is our full April schedule: * Tuesday 2 April at 2300 UTC * Monday 8 April at 1700 UTC * Monday 15 April at 1700 UTC * Tuesday 23 April at 1700 UTC (Monday 22 April is the Easter Monday public holiday) * Monday 29 April at 1700 UTC Daylight saving changed recently, so at least one of these meetings will be at a different local time for you. Our 1700 UTC meeting tracks north american daylight saving time. Our 2300 UTC meeting does not change for daylight saving time. T -- teor ----------------------------------------------------------------------

1 0

Re: [tor-dev] Docker images for help people to run Tor (teor)
by Alessandro Fiori 01 Apr '19

01 Apr '19

Hi, I would like to share with the community some tests I've made for setting up a "swarm" of Tor relays. I setted up 3 exit relays and 3 middle relays on the same IPv4 address, to make some testing, and the entire swarm works like a charm. Due to Tor limitation, I have decided to build a template for preparing the cluster, and upload it to GitHub. You can find the example mini-cluster here: https://github.com/randomtable/ChimeraOS/tree/master/TorSwarm I have tested the exit capabilities on another network with different public IP address. All the relays have published their own descriptors, I have prepared the containers as a single, separated machines. The process is different from preparing a single relay, because of Docker build process. I have disabled caching during the cluster process, so i have been able to modify torrc without issues. Because its very interesting, attached to this e-mail there is the console Logs from the 6 relays. All containers are read-only, so the entire relay will destroy at the end of session. I hope this can be useful. Alessandro Fiori Il giorno sab 30 mar 2019 alle ore 13:00 < tor-dev-request(a)lists.torproject.org> ha scritto: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Docker images for help people to run Tor (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 30 Mar 2019 13:08:53 +1000 > From: teor <teor(a)riseup.net> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Docker images for help people to run Tor > Message-ID: <3D4905AF-1C10-47BF-8823-EB3228FF990F(a)riseup.net> > Content-Type: text/plain; charset="utf-8" > > Hi, > > (Please try to reply to the thread, not the digest!) > > > On 30 Mar 2019, at 11:51, Alessandro Fiori <alefiori3(a)gmail.com> wrote: > > > > Because the images are built separately, and Containers doesn't have > persistent data by default, i'm testing the launch of a "relay swarm", > which isn't the "Docker Swarm". > > The concept of a "Relay swarm" is to have multiple running relay > containers on the same user machine, without any conflict. > > > > The idea (i will testing it very soon) is possible, by pulling an image > and running it multiple times, creating intermetiate containers. > > > > A function like the "relay swarm" can be very useful, i don't know if > this approach can be risky, so i'm preparing a script for launching only > one type of relay swarm (middle or exit relays). > > > > If there is no security concerns, this function will be a very key > function for grow up the Network, because a user can run multiple relays at > a time. > > Tor only allows 2 relays per IPv4 address. > > T >

2 1

Re: [tor-dev] tor-dev Digest, Vol 98, Issue 18
by Alessandro Fiori 30 Mar '19

30 Mar '19

Hi, and thanks for replying! I have built another image, for Non-Exit relays. Essentially, the Dockerfile is the same to the Dockerfile for build an Exit Relay, i have added the command for uncomment "ExitRelay 0" line in the torrc file. I have modified the Hidden Service image too, providing only the Hidden Service without opening ports, reducing the attack surface. Because the images are built separately, and Containers doesn't have persistent data by default, i'm testing the launch of a "relay swarm", which isn't the "Docker Swarm". The concept of a "Relay swarm" is to have multiple running relay containers on the same user machine, without any conflict. The idea (i will testing it very soon) is possible, by pulling an image and running it multiple times, creating intermetiate containers. A function like the "relay swarm" can be very useful, i don't know if this approach can be risky, so i'm preparing a script for launching only one type of relay swarm (middle or exit relays). If there is no security concerns, this function will be a very key function for grow up the Network, because a user can run multiple relays at a time. I'm presenting this project to the large community, so i can receive feedback and take actions in case of issues. Kind regards, Alessandro Fiori Il giorno ven 29 mar 2019 alle ore 13:00 < tor-dev-request(a)lists.torproject.org> ha scritto: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Docker images for help people to run Tor > (Chelsea Holland Komlo) > 2. Re: Docker images for help people to run Tor (Alessandro Fiori) > 3. Re: Docker images for help people to run Tor (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Mar 2019 05:46:57 -0700 > From: Chelsea Holland Komlo <me(a)chelseakomlo.com> > To: tor-dev(a)lists.torproject.org > Cc: Alessandro Fiori <alefiori3(a)gmail.com> > Subject: Re: [tor-dev] Docker images for help people to run Tor > Message-ID: <554cdbb2a021c08e08faef91d3bcb9a2(a)chelseakomlo.com> > Content-Type: text/plain; charset=US-ASCII > > Hi, > > Thanks for this information and putting this together! Making relays > easier to run is always a helpful thing to us. > > We have a wiki page to aggregate relay infrastructure projects such as > this. If you can add your projects to this page (and any required > instructions), that would be great. > > > https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure > > Thanks for the contribution! > Chelsea > > On 2019-03-27 21:18, Alessandro Fiori wrote: > > Hi, I'm an Italian developer who want to help development and grow up > > the Tor network. > > I would like to share with you an idea to grow up the Tor Network. > > Working with Docker, i have released two images, a Tor Exit Relay > > image (named "tor-relay") and an image (named "torworld-template"). > > The idea is to use Docker and build images for facilitate users to run > > a Tor Relay or an Hidden Service. > > The two images are located on Docker Hub in this locations: > > > > Tor Exit Relay: https://hub.docker.com/r/alessandrofiori/tor-relay > > Tor Machine Template: > > https://hub.docker.com/r/alessandrofiori/torworld-template > > > > If you want to see how the images are built, please check the > > following Dockerfile > > > > Tor Exit Relay: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > Tor Machine Template: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > > > If you want to see how i automate the build and push process, please > > check the following script: > > > > Process with system cleanup: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-script… > > Process for rolling release: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-rollin… > > > > Actually i'm working in a Windows environment, i will release ubuntu > > scripts soon. > > > > I would like to share with everyone, so if this can be helpful, this > > can be a starting point for build up images for help people to run > > relays or hidden services. > > > > This kind of approach can be reduce costs for people who want to run a > > relay or an hidden service, and can be an help for building a more > > censorship-resistant platform, by using a Docker Swarm, and > > replicating instances. > > > > Waiting for your reply as soon as possible, i'm very curious if this > > project can be helpful for Tor Project! > > > > Kind regards (and thanks for your hard work) > > Alessandro Fiori > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Mar 2019 23:57:46 +0100 > From: Alessandro Fiori <alefiori3(a)gmail.com> > To: Chelsea Holland Komlo <me(a)chelseakomlo.com> > Cc: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Docker images for help people to run Tor > Message-ID: > <CAP6e1PnzqMRXdGmnF1U=oZqA2s69gdY= > Wc+D4LSzPsygbYckNw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, and thanks for reply! > I added a line in the dedicated page, and modified the README.md on GitHub > for more specific informations to the users. > > I've decided to release two scripts (I'm releasing for Ubuntu too), for run > an Exit Relay or Hidden Service then, with Docker image. > > If needed, let me know if there would be useful releasing an image of a > Non-Exit-Relay. > > I will add more informations in the following days, for more explanations > and specific infos about building process. > I have decided to release only scripts or text file (for build process and > pull process), and no binaries, to keep processes transparent and > controllable. > > The next step for me is writing to forums and IRC, so people can review the > configurations. > I would like to meet the best practices to provide a robust and secure > service under all aspects. > > Another further step will be to contact Docker and try to achieve the > "Verified Publisher" or "Official Image" status, to keep the User Trust up. > > Official Images have automated security scans, so it can be a benefit to > community. > > I hope this can be useful, let me know! > > Kind regards (and thanks for your hard work... really!) > > Il giorno gio 28 mar 2019 alle ore 13:46 Chelsea Holland Komlo < > me(a)chelseakomlo.com> ha scritto: > > > Hi, > > > > Thanks for this information and putting this together! Making relays > > easier to run is always a helpful thing to us. > > > > We have a wiki page to aggregate relay infrastructure projects such as > > this. If you can add your projects to this page (and any required > > instructions), that would be great. > > > > > > > https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure > > > > Thanks for the contribution! > > Chelsea > > > > On 2019-03-27 21:18, Alessandro Fiori wrote: > > > Hi, I'm an Italian developer who want to help development and grow up > > > the Tor network. > > > I would like to share with you an idea to grow up the Tor Network. > > > Working with Docker, i have released two images, a Tor Exit Relay > > > image (named "tor-relay") and an image (named "torworld-template"). > > > The idea is to use Docker and build images for facilitate users to run > > > a Tor Relay or an Hidden Service. > > > The two images are located on Docker Hub in this locations: > > > > > > Tor Exit Relay: https://hub.docker.com/r/alessandrofiori/tor-relay > > > Tor Machine Template: > > > https://hub.docker.com/r/alessandrofiori/torworld-template > > > > > > If you want to see how the images are built, please check the > > > following Dockerfile > > > > > > Tor Exit Relay: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > > Tor Machine Template: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > > > > > If you want to see how i automate the build and push process, please > > > check the following script: > > > > > > Process with system cleanup: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-script… > > > Process for rolling release: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-rollin… > > > > > > Actually i'm working in a Windows environment, i will release ubuntu > > > scripts soon. > > > > > > I would like to share with everyone, so if this can be helpful, this > > > can be a starting point for build up images for help people to run > > > relays or hidden services. > > > > > > This kind of approach can be reduce costs for people who want to run a > > > relay or an hidden service, and can be an help for building a more > > > censorship-resistant platform, by using a Docker Swarm, and > > > replicating instances. > > > > > > Waiting for your reply as soon as possible, i'm very curious if this > > > project can be helpful for Tor Project! > > > > > > Kind regards (and thanks for your hard work) > > > Alessandro Fiori > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > >

2 1

Docker images for help people to run Tor
by Alessandro Fiori 28 Mar '19

28 Mar '19

Hi, I'm an Italian developer who want to help development and grow up the Tor network. I would like to share with you an idea to grow up the Tor Network. Working with Docker, i have released two images, a Tor Exit Relay image (named "tor-relay") and an image (named "torworld-template"). The idea is to use Docker and build images for facilitate users to run a Tor Relay or an Hidden Service. The two images are located on Docker Hub in this locations: Tor Exit Relay: https://hub.docker.com/r/alessandrofiori/tor-relay Tor Machine Template: https://hub.docker.com/r/alessandrofiori/torworld-template If you want to see how the images are built, please check the following Dockerfile Tor Exit Relay: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… Tor Machine Template: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… If you want to see how i automate the build and push process, please check the following script: Process with system cleanup: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-script… Process for rolling release: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-rollin… Actually i'm working in a Windows environment, i will release ubuntu scripts soon. I would like to share with everyone, so if this can be helpful, this can be a starting point for build up images for help people to run relays or hidden services. This kind of approach can be reduce costs for people who want to run a relay or an hidden service, and can be an help for building a more censorship-resistant platform, by using a Docker Swarm, and replicating instances. Waiting for your reply as soon as possible, i'm very curious if this project can be helpful for Tor Project! Kind regards (and thanks for your hard work) Alessandro Fiori

3 3

How to see the translated strings from Release_tweets.md in use
by scootergrisen 23 Mar '19

23 Mar '19

How/Where do i se the translated strings from Transifex Release_tweets.md in use?

1 0

Orbot and Tor on Android Q
by Nathan Freitas 22 Mar '19

22 Mar '19

Orbot 16.0.6-BETA-1-tor-0.3.5.8 <https://github.com/n8fr8/orbot/releases/tag/16.0.6-BETA-1-tor-0.3.5.8> https://github.com/n8fr8/orbot/releases/tag/16.0.6-BETA-1-tor-0.3.5.8 is out (binaries on Github for now) for testing, specifically on Android Q. It is built on a new release of: tor-android-binary-tor-0.3.5.8-rc <https://github.com/n8fr8/tor-android/releases/tag/tor-android-binary-tor-0.…> https://github.com/n8fr8/tor-android/releases/tag/tor-android-binary-tor-0.… This now uses the method of bundling the tor executable as a tor.so library, allowing the Android runtime to unpack them into the /data/libs read-only space within the app's private directory. We then can just execute it there, without needing to unpack it, copy it, etc. The word is that this will work on Android Q still. I have tested on an emulator, but not a real device yet. I don't have a Pixel of any kind, at the moment, so please let me know if you do and can test. Otherwise, we are working to move tor and other important binaries, like obfs4proxy, into actual in-process libraries. We've recently made great progress with this on our iOS work with Onion Browser, and so it should now be possible on Android. New commits below.... *** ATTENTION ANDROID Q / PIXEL TEST USERS: We've made changes just for you! WARNING: Meek/Obfs4 bridges WILL NOT work on Android Q yet, just plain Tor fb14c76 <https://github.com/n8fr8/orbot/commit/fb14c76c3a75977af9e86887b54dad5d15ae2…> fixed strings with two many \ escapes 4557577 <https://github.com/n8fr8/orbot/commit/455757726d519ac56cd53eaed29c3abef2570…> updating to tor-0.3.5.8-rc to add support for Android Q 22d5ffd <https://github.com/n8fr8/orbot/commit/22d5ffdf8bc3d51bb014e319d9f1e6b2ecb3e…> update gradle tools 76796fe <https://github.com/n8fr8/orbot/commit/76796fea83ef7efe3e33f6f5862fd71171a70…> Merge pull request #200 <https://github.com/n8fr8/orbot/pull/200> from eighthave/fastlane-supply 6ba0cec <https://github.com/n8fr8/orbot/commit/6ba0ceccbde67310c22fc9fa4e0dc88d93274…> add .gitlab-ci.yml setup with errorprone 3face00 <https://github.com/n8fr8/orbot/commit/3face00a66874afb793470922e381a9e463b1…> build gradle to 4.4.1, and make gradlew verify the download 69bd7fe <https://github.com/n8fr8/orbot/commit/69bd7fe9e6fd0fcde92ea53dd6236e50f7b37…> move app store graphics into fdroid/fastlane file layout f93c11e <https://github.com/n8fr8/orbot/commit/f93c11e74599cc24c7467d58ba0fc81c38c3c…> Merge pull request #190 <https://github.com/n8fr8/orbot/pull/190> from SkewedZeppelin/master 8ab13f6 <https://github.com/n8fr8/orbot/commit/8ab13f63a6f529d97816568170e02a1bced3c…> Fixup bad indentation from 6e4b700 <https://github.com/n8fr8/orbot/commit/6e4b7008035b2bf1a9035b730aad178bfd424…> 12b91c4 <https://github.com/n8fr8/orbot/commit/12b91c44f3af675dd0db5a3bacbf232c0f8d6…> Expose PreferIPv6 and NoIPv4Traffic options 8ad7668 <https://github.com/n8fr8/orbot/commit/8ad7668013a7291b98cf8689cd99961db69f8…> Move Google repo above jcenter d4befad <https://github.com/n8fr8/orbot/commit/d4befad117f3485f0aa67b2ce44d3f1b13de2…> cleanup and binary loading fixes

1 0

Testing Tor bridge assignments
by Jodi Spacek 20 Mar '19

20 Mar '19

Hi! I'm seeking advice on simulating Tor's consistent hashing, bridge ring distributor. I'm finishing up my Master's thesis on proxy distribution :) I run BridgeDB through my Python simulator to analyze the https distributor's bridge assignments over multiple bridge pool sizes and trials. So far, it follows a uniform random distribution (as expected). I'm using https distributor's prepopulateRings() example as a guideline on how the rings should be populated. Besides the default ring settings, are there any other test scenarios that I should cover? For instance, is there a possibility that the behaviour might change if there are quality of service limitations? Aside from the reserved set, are there any cases where it may not assign bridges uniform randomly that I should consider? I attempted to use the descriptors from leekspin, but ran into some hurdles integrating it with my simulator. My simulator doesn't need to persist or store state, since I only need the assignment information of proxies to clients until all proxies are enumerated. I hope the pared down version using the test data from generateFakeBridges() in test/util.py is adequate. Any advice is greatly appreciated!

1 0

Tor Friendliness Scanner
by Kevin Gallagher 18 Mar '19

18 Mar '19

Hello tor-dev! My name is Kevin and I'm a PhD student at NYU. Recently I've been working on creating a "Tor Friendliness Scanner" (TFS), or a scanner that will measure what features of a given website are broken (non-functional) when accessed on the Tor Browser (TB), along with actionable suggestions to improve it. In order to do this, we first must get an approximation of ground-truth data of how a given website should work. We then need to compare it to how the website works on the TB to determine any changes. To generate a method of determining ground-truth, we decided to modify* the Firefox (FF) browser to log all of the steps of the creation of the Content Tree (also called the DOM tree), and to log the execution of all JavaScript functions (currently underway). We then will apply these changes to the TB as well, and run a scan of popular Web sites using the modified FF and the modified TB on all three of the TB security slider settings. We will then compare the resulting logs to determine where the tree creation processes differed* and why. These differences could potentially help us illuminate two things: 1. what functionality issues the Tor Browser encounters on popular Web sites, and 2. what threats (beyond metadata surveillance) the TB is protecting its users from in-the-wild. As far as I have considered, this method seems to capture a lot, but it's far from complete. For one thing, it obviously won't detect any difference that's spawned from user interaction or input (such as a script launched by an OnClick event). However, it does seem to make automation of scanning for Tor Friendliness possible, and can allow for wide-scale use. We have moved ahead with development (though have not yet finished it) and are (hopefully) very close to a working prototype. I was wondering if there was feedback on this method, or if anyone can consider an angle we have not that would either make the TFS more robust, easier to create, or both. Thanks for your time and consideration! Kevin *Note 1: Unfortunately we cannot just rely on JavaScript for examining the content tree, since this needs to work on all 3 security settings of the TB's security slider, and the "safest" setting deactivates JavaScript by default on all Web pages. *Note 2: There can be non-functional differences in Web pages, such as different ads showing or the display of the current time. We are working on methods to distinguish these from functional differences, such as using ad blacklists to determine if a given request or script is part of an ad, and ignoring it as part of the difference between the two trees. -- Kevin Gallagher Ph.D. Candidate Center For Cybersecurity NYU Tandon School of Engineering Key Fingerprint: D02B 25CB 0F7D E276 06C3 BF08 53E4 C50F 8247 4861

8 10

Proposal: Don't include package fingerprints in consensus documents
by Iain Learmonth 13 Mar '19

13 Mar '19

Hi All, #28465 [0] needed a proposal. Feedback is welcome and encouraged. I've not written a proposal before, so if someone could let me know if I'm following the process OK (or not) then that is useful too. Thanks, Iain. [0] https://trac.torproject.org/projects/tor/ticket/28465

3 8

#3600 tech doc
by Richard Pospesel 13 Mar '19

13 Mar '19

Hey y'all, For the past little while I've been working on a technical overview doc for #3600 (Prevent redirects from transmitting+storing cookies+identifiers) detailing the problems, scenarios and possible solutions. Please take a look and feel free to comment, edit or add! Link: https://storm.torproject.org/grain/X4nhdNqR9fGRc7sgTefFkg/ best, -Richard

3 7

Updating Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count)
by Neel Chauhan 12 Mar '19

12 Mar '19

Hi tor-dev@ mailing list, I have Proposal 299, also known as "Preferring IPv4 or IPv6 based on IP Version Failure Count" which makes ClientAutoIPv6ORPort take into account IPv4 and IPv6 failures. An older version of this document is available here: https://gitweb.torproject.org/torspec.git/tree/proposals/299-ip-failure-cou… I have attached an updated copy of this proposal to this message. This includes the changes recommended by teor at https://lists.torproject.org/pipermail/tor-dev/2019-February/013673.html. Would someone be able to update torspec to include the updated (and attached) proposal? Also, if any of you have opinions on this proposal, please share them with me. -Neel === https://www.neelc.org/

2 5

download consensus from mirrors based on frequency options in torrc
by Pouya Miralaee 08 Mar '19

08 Mar '19

Hello to the community. according to these frequency options below, how should i specify that tor does not or if it has to, only in necessary times downloads consensus from directory servers and in all other cases, download them from mirrors or fallbacks. "ClientBootstrapConsensusAuthorityDownloadSchedule": "6, 11, 3600, 10800, 25200, 54000, 111600, 262800", "ClientBootstrapConsensusFallbackDownloadSchedule": "0, 1, 4, 11, 3600, 10800, 25200, 54000, 111600,262800", "ClientBootstrapConsensusAuthorityOnlyDownloadSchedule": "0, 3, 7, 3600, 10800, 25200, 54000, 111600,262800", I just intend to complete the decentralized situation in here. but i can not figure out how these frequency options work together. thanks in advance. Cheers. -- *Pouya Miralayi* -- *Pouya Miralayi*

2 1

March Network Team Meeting Schedule
by teor 01 Mar '19

01 Mar '19

Hi, Next week's network team meeting is at a different time. We'll be meeting at Tuesday 5 March at 2300 UTC on #tor-meeting on OFTC. Here is our March schedule: * Tuesday 5 March at 2300 UTC * Monday 11 March at 1800 UTC * Monday 18 March at 1800 UTC * Monday 25 March at 1800 UTC We'll have a similar schedule in April, except for the company holiday on April 22. T -- teor ----------------------------------------------------------------------

1 0

Anti-censorship discussion with Briar devs
by Cecylia Bocovich 28 Feb '19

28 Feb '19

Hi, I just had a really great conversation with some of the developers at Briar about the recent work they've done in integrating some pluggable transports into their messaging application. I thought I would summarize some key points from the conversation here. In particular, this information might prove useful for both the metrics and anti-censorship teams to know how other projects are using our tools and what they would like help with. This summary is organized as follows: I. How they used metrics data II. Independent reachability tests they performed III. What they did to integrate pluggable transports into Briar IV. What they want help with I. How they used metrics data One goal the Briar project had was to automatically detect where bridges are needed so they can be enabled automatically and for Briar to "work out of the box" with minimal developer overhead as they do not currently have dedicated anti-censorship funding. Here is the related ticket with a lot of useful discussion: https://code.briarproject.org/briar/briar/issues/1266 They wrote a collection of analytics scripts that use both OONI and Tor Project metrics data to determine where bridges are being blocked. Source code for the scripts: https://code.briarproject.org/briar/tor-circumvention-analytics/ Results (outdated): https://grobox.de/tor/bridges.html They rely mostly on OONI data but also use some Tor metrics to look at the ratio of bridge users in a country. Their reasoning being that while OONI shows what doesn't work, Tor metrics data shows what is currently working. Source code for Tor metrics script: https://code.briarproject.org/briar/tor-circumvention-analytics/blob/master… The ticket linked above has more discussion that might be useful to the metrics team as well. II. Independent reachability tests they performed To validate some of the results from OONI and Tor metrics, they ran a private bridge and did some reachability tests to it from China. They found that the bridge was not blocked, however they did not perform bandwidth tests to determine whether or not obfs4 bridges are being throttled. This makes sense as briar produces probably fairly low bandwidth traffic. When I asked them about it they suggested performing the following test: Set up obfs4 to forward connections to a local http server that servers a large, static file. Have a contact in China set up a cron job that periodically downloads the file from the bridge via obfs4. Their original reachability test was not running for very long, so it's still possible that prolonged use would result in its discovery but the fact that it wasn't blocked suggests that China might be enumerating bridges through the distribution mechanism rather than by something identifiable from obfs4 itself. We should perform our own tests to verify this, and to check for throttling. III. What they did to integrate pluggable transports into Briar My understanding from the issue text and commit messages about how briar decides whether to use pluggable transports is to use the output of their reachability analysis to determine user needs by country. If Tor is not blocked, users just use vanilla Tor If it is they use obfs4. If obfs4 is blocked, then they use meek (meek lite). Right now the countries that use meek in briar are: China, Iran, Egypt, Belarus, Turkey, Syria, and Venezuela. As far as the integration, they wrote some code that makes reproducible builds of obfs4 and meek and spits out a java/android library: https://code.briarproject.org/briar/go-reproducer Briar already uses Tor, so they configure these bridges in the usual way using a torrc file and a hardcoded, shipped file of bridge information (which I believe are also the default bridges used by Tor Browser). They decided they didn't want to maintain any private bridges like the one they used for their reachability tests. One of the concerns there was the ability to fingerprint Briar traffic by bridge connection and differentiate it from other Tor traffic. IV. What they want help with Because they do not have dedicated anti-censorship funding, they mentioned a few things that would help them maintain their pluggable transport use going forward and ease the integration of pluggable transports. The main thing they would like on the metrics side is up-to-date information about which PT works in which country and where PTs are needed at all in order to make quick and easy decisions based on location about which transports to use. They started to work with OONI to expand their tests but it turned out to be too much work for their time/funding: https://code.briarproject.org/briar/briar/issues/1414 It's on our roadmap to work with OONI and other censorship measurement tools (like Censored Planet) to expand our tests so we should get into contact with them again once we have gotten farther with this. On the PT development side, they expressed a desire to transfer maintenance of their reproducible builds of obfs4 and meek to someone else (that's the go-reproducer code linked above).

5 6

Speeding up your Tor Appveyor Builds
by teor 27 Feb '19

27 Feb '19

Hi, We have made some changes to speed up Tor's Appveyor builds: https://bugs.torproject.org/29601 They should be merged soon. If you have Appveyor set up on your personal tor git repository, you can change Appveyor's configuration so that it's a bit faster. (We can't make these changes in the .appveyor.yaml config.) 0. Log in to Appveyor: https://ci.appveyor.com/ I use GitHub to log in to Appveyor. 1. Go to Appveyor's project settings page. Mine is: https://ci.appveyor.com/project/teor2345/tor/settings 2. Set "Build timeout, minutes" to 30. The default timeout is 60 minutes. Tor's jobs usually take about 10 minutes, unless they hang. 3. Set the "Rolling builds" checkbox. The default is: "build all versions of a branch/pull request". Rolling builds means: "when a branch or pull request is updated, cancel the previous build, and start a build with the latest changes." That's it. Your builds will be a bit faster! T -- teor ----------------------------------------------------------------------

1 0

Sending multiple streams throuh a single Tor circuit
by Piyush Kumar Sharma 26 Feb '19

26 Feb '19

Hello all, I am a PhD student, and am working on some measurements in Tor. I am stuck at a point where i need to send multiple applications(streams) traffic through a single circuit. I am currently using torsocks/torify to send traffic of these multiple applications through Tor. The main problem is that, despite trying many different ways to achieve the same (sending multiple streams through a single circuit), i am not successful. Things i have tried : 1.) Force Tor process to create only a single circuit at a time preventing any new circuit creation, so that any new stream would be attached to this only available circuit. To acheive this i have set the following Tor options : set __DisablePredictedCircuits to 1 set MaxClientCircuitsPending to 1 set newcircuitperiod to 999999999 set maxcircuitdirtiness to 999999999 The problem with the above method is that it seems to work sometimes randomly. But most of the times for some reason, a new circuit is still created. 2.) Next, i assumed that maybe running torify multiple times for each application is the culprit, as it may try to create new circuit for each run. So i created a new bidirectional stream using socat, which listens on a local TCP port, and forwards the data to the Tor SOCKS port assuming that it will lead to a singe connection to local SOCKS. Even this did not work and still new circuits were created randomly. 3.) Next i tried to attach streams to circuits manually, using the stem library following the link : https://stem.torproject.org/tutorials/to_russia_with_love.html#custom-path-… . This seemed to work initially, but then after every 4-5 runs, the streams seemed to detach automatically. Moreover, the original circuit crashed too. It would be great, if someone could tell a simple way to achieve the same, or would point me to any mistakes that can be improved in the above methodologies to make them work. Regards Piyush

4 8

xp + T
by Gedropi 26 Feb '19

26 Feb '19

I would like to continue to get Tor updates but intend to keep Windows XP. How can I do it? Thanks

4 4

GSOC 2019 tor project participation
by ＠usernamedt 26 Feb '19

26 Feb '19

Hello everyone, Can someone confirm that tor project is participating at GSOC 2019? I am a Mathematics and Computer Science student (Russia, Ural Federal University). Privacy violation and internet censorship became serious problems for me personally and for many people in my country. I am looking forward to contribute to tor project by implementing OONI Encore style test in browser. Thanks!

2 2

Testing Network: Circuit buildup errors and missing guards
by Katharina Kohls 21 Feb '19

21 Feb '19

Hey guys, currently I am working on a private Tor setup and I repeatedly run into issues with the circuit buildup procedure (it's Tor 0.3.5.7 on linux, the setup consists of several debian jessie VMs). The setup is as follows: 1 Client, 2 V3 Authorities, 6 Relays of which 3 have the ExitRelay 1 option set. In the torrc configs of all relays I define a list of fixed exits TestingDirAuthVoteExit and fixed guards TestingDirAuthVoteGuard and I use DirAuthority to fix the two V3 authorities of my setup. All nodes bootstrap properly and reach 100%, the authorities both manage to vote and exchange information. Also the relays and the client bootstrap to 100%. Nevertheless, the consensus seems to lack relays with guard flags: Feb 12 10:35:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2/2, and can only build 0% of likely paths. (We have 0% of guards bw, 100% of midpoint bw, and 100% of end bw (no exits in consensus, using mid) = 0% of path bw.) Because of this, no default circuits can be built in the client or the relays in all logs the following message appears every second: [warn] Failed to find node for hop #1 of our path. Discarding this circuit. Google says it might be an ntp-sync problem. The VMs are not connected to the Internet (but can talk to each other), so I made sure that all machines are in sync and use the firewall as NTP server. Sync shouldn't be the problem. In the data_dir/state file I see several guard entries: Guard in=default rsa_id=[...] nickname=auth01 sampled_on=2019-01-17T18:33:12 sampled_by=0.3.5.7 listed=1 Guard in=default rsa_id=[...] nickname=relay03 sampled_on=2019-01-22T17:17:10 sampled_by=0.3.5.7 unlisted_since=2019-01-27T11:00:36 listed=0 Guard in=default rsa_id=[...] nickname=relay02 sampled_on=2019-01-24T22:19:10 sampled_by=0.3.5.7 unlisted_since=2019-01-29T09:08:59 listed=0 Guard in=default rsa_id=[...] nickname=relay03 sampled_on=2019-02-06T21:07:36 sampled_by=0.3.5.7 listed=1 Guard in=default rsa_id=[...] nickname=relay05 sampled_on=2019-01-27T16:37:38 sampled_by=0.3.5.7 listed=1 The client also seems to receive a complete consensus, at least all fingerprints of my setup show up if I fetch the file manually. Please find below an example of the configs I use for the different nodes. Any help or hints would be great :) Thanks, Katharina # DIRECTORIES, LOGGING SafeLogging 0 ProtocolWarnings 1 DisableDebuggerAttachment 0 DataDirectory /var/lib/tor PidFile /var/lib/tor/pid Log notice file /var/lib/tor/notice.log Log info file /var/lib/tor/info.log # CONTACT ContactInfo ... # GENERAL RunAsDaemon 1 AssumeReachable 1 ConnLimit 60 MaxMemInQueues 1507 MB ShutdownWaitLength 0 HashedControlPassword ... # FIXED AUTH DirAuthority auth01 orport=5000 no-v2 v3ident=... ...:7000 B218B78864CEF4397CEE0AEF61703459EEE64E38 DirAuthority auth02 orport=5000 no-v2 v3ident=... ...:7000 431E50CDBB0B6FFDD0284A45ABEC875136D980E8 TestingDirAuthVoteExit 2B74825BE33752B21D17713F88D101F3BADC79BC,E4B1152CDF0E5FE697A3E916716FC363A2A0ACF3,7353D324677B9E7A9A50240339C2C7366B381F64 TestingDirAuthVoteGuard 911EDA6CB639AAE955517F02AA4D651E0F7F6EFD,C122CBB79DC660621E352D401AD7F781F8F6D62D,8E574F0C428D235782061F44B2D20A66E4336993 # PORTS OrPort 5000 ControlPort 9051 SocksPort 9050 # FLAGS ExitRelay 1 Nickname ... Address ...

2 5