- tor-dev - lists.torproject.org

WTF is going on? An evolutionary biology approach to the human condition
by Hugo Maxwell Connery 24 Mar '16

24 Mar '16

Dr. E. O. Wilson. 40 mins + 20 mins questions. https://www.youtube.com/watch?v=DWLoluq-HCo How and why. /Hugo PS: Sorry, this may be completely outside of the normal channel of this space. I hope that some members are shocked by this presentation. I believe in tech, but more importantly I believe in the informed.

2 1

Request for feedback/victims: cfc
by Yawning Angel 24 Mar '16

24 Mar '16

Hello, Inspired by https://trac.torproject.org/projects/tor/ticket/18361 I've been working on way to improve the situation. My "proof of concept" tech demo is what I consider good enough for use by brave people that aren't me, so I have put up an XPI package at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ The source: https://git.schwanenlied.me/yawning/cfc (Requires the Firefox SDK aka Jetpack to package). By default the addon will: * Rewrite the CloudFlare captcha error page with messages that reflect my perception of reality[0]. * Rewrite imgur ".gifv" links to ".gif". Under "Tools->Addons->Extensions" you can configure the addon to: * Automatically fetch a cached copy of pages hosted on CloudFlare infrastructure from archive.is. * Automatically fetch a cached copy of pages that present a CloudFlare captcha from archive.is. * Pop up a UI widget asking if you want to fetch a cached copy of the page from archive.is each time you encounter a captcha. * Disable the snarky error message replacement (Requires a restart to take effect, because I'm lazy). * Disable the gifv URL rewrite. TODO: * Support a user definable blacklist (eg: If you want to always use archive.is to access gawker.com or other clickbait bullshit, you should be able to easily do so). * Add more general quality of life things. * Think about making it work on Fenec (It currently will not because PopUpNotifications are handled differently, among other things). * Rewrite the internals to prepare for e10s. WARNING: * If archive.is is evil, they can track you across page fetches trivially, because this sort of use case is outside of Tor Browser's current threat model (Yes, CloudFlare/Google can also do the same thing currently, who do you trust more?). * PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL SHOULD NOT USE THIS. If you don't know how to install addons given as XPI files, you shouldn't be using this. This is only tested on 6.0a4 (Linux/64 bit). It *should* work on everything that isn't Orfox that's relatively modern, YMMV. Regards, -- Yawning Angel [0]: A very cynical/adversarial take on things. Opinions are my own, etc, and I don't care if you're offended.

7 8

Urgent fixes for 0.2.8.2-alpha
by Tim Wilson-Brown - teor 24 Mar '16

24 Mar '16

Hi All, I think I've completed the urgent fixes assigned to me for 0.2.8.2-alpha and mentioned in the network team meeting yesterday. If we merge the following patches into the upcoming 0.2.8.2-alpha, we'll know: #18616 - whether AccountingMax still breaks relay bootstrap (master - not in any released version) #18351 - whether log messages are too frequent, or whether there are actual outgoing connection issues (0.2.8.1-alpha) #18517 - whether meek and bridges on private addresses are still broken (0.2.8.1-alpha) #18489 - whether extrainfo descriptors are still broken with fallback directory mirrors (0.2.8.1-alpha / 0.2.4.7-alpha) The release in brackets is when each issue was introduced. I don't know of any other patches (assigned to me) that are urgent enough to hold up the next alpha. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 0

GSOC'16
by Ahmet Fatih Çamaltı 24 Mar '16

24 Mar '16

Hi, I'm Ahmet. I'm a senior undergraduate Computer Science student at Turgut Ozal University, Turkey. I'm interested Expand the OS and Server Support of the Let's Encrypt Client project for GSOC'16 and I would like to work on this. I will write proposal draft and upload to the system soon. Should I need to do anything else? Can you provide a little bit more details for this project for the proposal? Thank you for your interest.

1 0

GSoC proposal: Panopticlick
by Akito Ono 24 Mar '16

24 Mar '16

Hello! I'm writing a proposal for the Panopticlick project. Would you advise me about this proposal? https://gist.github.com/ak1t0/1bf1b6bd4e3fc99e2097 Best regards, Akito

2 3

GSoC proposal Review
by Pushkar Pathak 24 Mar '16

24 Mar '16

Hi, Please review my proposal to Improve Ahmia-Hidden Search Service https://docs.google.com/document/d/1VylEqQBdFPe-ev_naT9qA4ycNM1_U5j8OhMLATD… Thanks, Pushkar.

1 0

(no subject)
by Huy Vu Quoc 24 Mar '16

24 Mar '16

Hi Arlo, > It may be prudent to consider a memory-managed language (I'll suggest golang here as popular choice) for the server component. It is good to know that I can use golang to develop the server component. I am going to rewrite this part. > Wherever possible, we'd like to avoid modals and use the notification bar. There's also a suggestion to grey out the conversation window and use a throbber here, https://github.com/arlolra/ctypes-otr/issues/20 Since the monitoring protocol is done periodically so there certainly exist a case of an unexpected key change whereas there are not any conversation windows. In such a case, how do we show the message using the notification bar? I think that a popup modal is a good choice for this situation. Btw, I also added a timeout enforcement for responding to events in my proposal. Timeout for requests is 100ms and this can be changed based on some surveys and tests during development phase (may the registration request take a longer time than other requests?). Best Regards, Vu Huy

1 0

Query regarding GSOC '16 - txtorcon
by Akash Mishra 24 Mar '16

24 Mar '16

Hi all, I am Akash Mishra, an undergraduate from India and if given an opportunity, I would love to participate in GSOC with the TOR project. This will be my first time contributing to an open source project. I have been using python for all my college projects for over a year. Due to my familiarity with python, I would like to work on txtorcon - Convert txtorcon to txaio - during the summers. The requirements state that I should be very familiar with asynchronous programming and with one of twisted or asyncio. I have only basic familiarity with asyncio - having explored it once after watching a pycon talk on it. But I am very enthusiastic to learn and bridge the skillgap that will be needed to complete the project. I have already started with the krondo tutorials on twisted to gain familiarity with the twisted framework. How should i get started with txtorcon project ? Are there any minor issues that i can work on as of now ? Thanks, Akash Mishra

2 7

Notes from network team meeting Wed 3/23/2016
by Isabela 23 Mar '16

23 Mar '16

tl;dr; important updates related to triage process and important discussion topics related to release guidelines draft. Also, help needed to get 0.2.8 out. Pay attention to next meeting time! It's new! == Notes from little t Tor team - Wed March 23rd @ #tor-dev == Participants + updates: * nickm - working on modularity documentation + reviewing, merging, fixing bugs. Got coverity autobuilds to happen 3 times a week, we can have others if desired (up to 8 a week). This link might be useful: https://people.torproject.org/~nickm/tor-auto/ - next week: more triage and planning things. Finish up modularity ideas and v1 implementation for most of them; release 0282rc * isabela - I migrated all the info you added into the spreadsheet back to trac (thanks for doing it); worked on the release guidelines first draft with nick and y'all has it now; trying to organize the next step on triagging (need some answers to help guide it / email I sent yesterday); * asn - did some guard research, also did some hackerone triaging. Finally I also did some work on prop224 specifically on the cell formats. i have a torspec branch with initial changes here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010561.html - I also started a thread about more singificant changes to the cell, here it is https://lists.torproject.org/pipermail/tor-dev/2016-March/010560.html * armadev - I actually wrote a tiny bit of Tor code lately (#18332). I mostly have questions though (from thinking this morning): a) Where is the 0.2.8 timeline posted? Maybe it should be on the network team trac page? Or somewhere else? b) I see athena mentioning backporting the #18570 patch. Do we (you) have consensus on what is worth backporting? Should we (you)? (i would argue that the patch doesn't want a backport) (i see the questions for me about prop224. i am being a bad person and not being able to keep the 224 design in my head. that makes it hard to usefully answer questions. :/ ) * dgoulet - code review and a bit of patches last week, got sucked in LibrePlanet during friday/weekend/monday and I basically catched up on things yesterday. I plan to continue prop224 implementation today as I'm moving to do the cache work for HSDir. so I still need to answer bunch of people on email including GsoC stuff for HS but hoping to jump back in the coding arena * athena - merged #18570 past week (but it needs code review for backport to 0.2.7; on it); now digging into some code reviews (working on #7478) == Discussion topics and action items: Backport strategy Athena will take over 0.2.7 (and any other previous release if she can) - this means doing the backports / merges / releases. Athena could start by going over all the tickets in maint-0.2.7 and saying which should get backported, which not? armadev and weasel will have opinions. About backport policy in general, here is a draft: http://paste.debian.net/418364/ Isabela will look in the wiki for any old notes related to this topic and create a new page for our policy on Network Team's wiki. #idea: two-person approval to backport? #commnet: a nice side effect of a good backport policy is that it saves time and effort 0.2.8 timeline Timeline was freeze-start-of-march, then rc mid-march, we did the freeze ontime and now the rc is late. And we are concerned about when it will be ready to go out. Folks should prioritize 0.2.8 release and 0.2.9 *triage*. If everybody else jumps into 0.2.9 without nick, and/or without triage, bad stuff will happen. Most obviously, 0.2.8 will be slow, and everything else will get off track with 0.2.9. Tickets that we are waiting on a decision are market with the tag: 'must-fix-before-028-rc', we will probably ignore those marked as 'needs-info'. During discussion people took tickets to review and we will follow up in the next meeting. About timelines in general we are trying to build guidelines (timeline) for all releases. once is finalize we will add it to the wiki Summarize promising gsoc students for network team topics? We decided on the both actions items: * get quick list of network-team-related projects * somebody ask atagar if there are network team projects without enough adequate associated possible mentors Discuss draft plans for 029 release/triage/etc. We reviewed priority list and capacity formula in the pad: https://storm.torproject.org/shared/71UUCvDgDA6q9lfdndAtRZoWQdjz4Wb8EoX0eLy… Most important thing to do from now till Friday is to make sure tickets on 0.2.9.x-final milestone has the following information: * points - small == <1 day (a task you can get done in a day)| medium == <1 week | large == +1week * owner (assign a ticket to yourself if you are the one doing the task) * priority * sponsor -must and -can information If you want to suggest a ticket to be part of 0.2.9 now is the time to add it to the milestone. The above will give us the necessary information to organize our release until it has a good size for the team. Discussion about tickets workflow We will send an email to tor-dev talking about adding a step to the workflow ("need_merge", "ready_merge") to indicate that it has been reviewed and someone did Acked it. Check if other dev teams objects against havingt his step. Milestones discussion We decided to talk about the "Making traige stick" in the pad We discussed how we can have control of what goes in and out of a release after we are done triaging it. One thing could be by chaning the permissions for the milestone, so there must be a team agreement for things to be added. We discussed about creating a bucket (milestone or keyword) to know what are the tickets people would like us to consider for the release. This discussion is part of the team routines discussion. These buckets will help us organize tickets we will be looking at during our check in moments on irc. See in the pad the team routine to see what check ins we are planning to do weekly, monthly and by release. Action Items ------------ asn publish the latest prop259 revision nickm publich the modularity document as it stands examine/merge asn's changes in https://lists.torproject.org/pipermail/tor-dev/2016-March/010561.html send new prop224 to mailing list when it's done asn explains the prop224 questions to arma? :) athena bangs on 0.2.7 isabela to add backport policy to the wiki somebody needs to go over this with the devs who weren't here. isabela asks about ready_for_merge == Next meeting and other updates: STARTING ON MARCH 28 our meeting times will move: Primary meeting Monday 1700 UTC Monday 7:00pm CEST Monday 1:00pm EDT Monday 10:00am PDT Patch party! Tuesday 2300 UTC Wednesday 1:00am CEST Tuesday 07:00pm EDT Tuesday 4:00pm PDT -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa

1 0

Re: [tor-dev] tor-dev Digest, Vol 62, Issue 38
by Hugo Maxwell Connery 23 Mar '16

23 Mar '16

Hi, Hats off to Yawning Angel for doing work to address this "CAPTCHA" challenge. The idea of using archive.somewhere to fetch cached versions of walled garden internet zones seems sensible. More points to YA with the ALL CAPS warning about "big nasty adversary in you threat model dont go here" and "who do you trust ? archive.somewhere or Google/Cloudflare/other internet dominant organisation". I use TBB because I dont believe that others have a right to know what I am reading, rather than because I face a specific threat. But, the act of deanonymizing to gain content access is a very slippery slope and I congratulate YA for putting effort into addressing this slightly obscure but very important challenge. With respect, Hugo

1 0

Re: [tor-dev] Tor 0.2.8 and Fallback Directory Mirrors
by Nathan Freitas 22 Mar '16

22 Mar '16

On Mon, Mar 21, 2016, at 02:16 PM, Tim Wilson-Brown - teor wrote: > Just a heads' up that tor 0.2.8 includes a fallback directory mirrors > feature, where tor clients bootstrap from a set of hard-coded long-lived > directory mirrors. This makes bootstrap more reliable, and makes it > harder to block tor. The wiki has an entry with more details. [0] > > We're currently trying to finalise a list of around 100 fallback > directory mirrors by the time tor 0.2.8-stable is released. [1] Thanks for the heads up on this. It sounds like an excellent feature. Is there any randomization to the selection of which mirror to use? Any events or info notice when the fallback is being used? +n

2 1

GSoC'16 proposal: the Torprinter project (a Panopticlick-like website)
by Pierre Laperdrix 22 Mar '16

22 Mar '16

Hi Tor Community, My name is Pierre and I'm really interested in participating in a GSoC project this year with the Tor organization. Since I've been working on browser fingerprinting for the past two years, I'd love to build a Panopticlick-like website to improve the fingerprinting defenses of the Tor browser. I've included below my proposal in case anyone has ideas or suggestions, especially on the technical section or on some of the open questions that I have. (It should be noted that the Torprinter name is subject to change). ****************************************************** Summary - The Torprinter project: a browser fingerprinting website to improve Tor fingerprinting defenses The capabilities of browser fingerprinting as a tool to track users online has been demonstrated by Panopticlick and other research papers since 2010. The Tor community is fully aware of the problem and the Tor browser has been modified to follow the "one fingerprint for all" approach. Spoofing HTTP headers, removing plugins, including bundled fonts, preventing canvas image extraction: these are a few examples of the progress made by Tor developers to protect their users against such threat. However, due to the constant evolution of the web and its underlying technologies, it has become a true challenge to always stay ahead of the latest fingerprinting techniques. I'm deeply interested in privacy and I've been studying browser fingerprinting for the past 2 years. I've launched 18 months ago the AmIUnique.org website to investigate the latest fingerprinting techniques. Collecting data on thousands of devices is one of the keys to understand and counter the fingerprinting problem. For this Google Summer of Code project, I propose to develop the Torprinter website that will run a fingerprinting test suite and collect data from Tor browsers to help developers design and test new defenses against browser fingerprinting. The website will be similar to AmIUnique or Panopticlick for users where they will get a complete summary with statistics after the test suite has been executed. It can be used to test new fingerprinting protection as well as making sure that fingerprinting-related bugs were correctly fixed with specific regression tests. The expected long-term impact of this project is to reduce the differences between Tor users and reinforce their privacy and anonymity online. In a second step, the website could open its doors to more browsers so that it could become a platform where vendors can implement significant changes in their browsers with regards to privacy and see the impact first-hand on the website. With the strong expertise I have acquired on the fingerprinting subject and the experience I have gained by developing the AmIUnique website, I believe I'm fully qualified to see such a project through to completion. Website features The main feature of the website is to collect a set of fingerprintable attributes on the client and calculate the distribution of values for each attribute like Panopticlick or AmIUnique. The set of tests would not only include known fingerprinting techniques but also ones developed specifically for the Tor browser. The second main feature of the website would be for Tor users to check how close their current fingerprint is from the ideal unique fingerprint that most users should share. A list of actions should be added to help users configure their browser to reach this ideal fingerprint. The third main feature would be an API for automated tests as detailed by this page : https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… . This would enable automatic verification of Tor protection features with regard to fingerprinting. When a new version is released, the output of specific tests will be verified to check for any evolution/changes/regressions from previous versions. The fourth main feature I'd like to include is a complete stats page where the user can go through every attribute and filter by OS, browser version and more. The inclusion of additional features that go beyond the core functionnalities of the site should be driven by the needs of the developers and the Tor community. Still, a lot of open questions remain that should be addressed during the bonding period to define precisely how each of these features should ultimately work. Some of these open questions include: - How closed/private/transparent should the website be about its tests and the results? Should every tests be clearly indicated on the webpage with their own description? or should some tests stay hidden to prevent spreading usable tests to fingerprint Tor users? - Should a statistics page exist? Should we give a read access to the database to every user (like in the form of a REST API or other solutions)? - Where the data should be stored? How long should the data be kept? If tests are performed by versions, should the data from an old TBB version be removed? Should the data be kept a week, a month or more? - How new tests should be added: A pull request? A form where submissions are reviewed by admins? A link to the Tor tracker? - Should the website only be accessible through Tor? Technical choices In my opinion, the website must be accessible and modular. It should have the ability to cope with an important number of connections/data. With this in mind and the experience gained from developing AmIUnique, I plan on using the Play framework with a MongoDB database. Developing the website in Java opens the door to many developers to make the website better and more robust after its initial launch since it is one of most used programming language in the world. On the storage and statistics side, MongoDB is a good fit because it is now a mature technology that can scale well with an important number of data and connections. Moreover, the use of SQL databases for AmIUnique proved to be really powerful but the maintenance after the website was launched became a tedious task, especially when modifying the underlying model of a fingerprint to collect new attributes. The choice of a more flexible and modular database seems a better choice for maintenance and for adding/removing tests. Estimated timeline You will find below a rough estimate of the timeline for the three months of the GSoC. Community bonding period - Discuss with the mentors and the community the set of features that should be included in the very first version of the website and clarify the open questions raised in one of the previous paragraphs. 23 May - 27 June : Development of the first version of the website with the core features Week 1 - Development of the first version of the fingerprinting script with the core set of attributes. Special attention will be given so that it is fully compatible with the most recent version of the Tor browser (and older ones too). Week 2 - Start developing the front-end and the back-end to store fingerprints with a page containing data on your current fingerprint (try adding a view to see how close/far you are from the ideal fingerprint). Week 3 - Start developing the statistics page with the necessary visualization for the users. Modification of the back-end to improve statistics computation to lessen the server load. Week 4 - Finishing the front-end development and refining the statistics page to get back the most relevant information. Adding and testing an API to support automated tests. Week 5 - Finishing the first version so that it is ready for deployment. Start developing additional features requested by the community (rest API? account management?) 27 June - Mid July : Deployment of the first version online for a beta-test with bug fixing. Finishing development of additional features requested by the mentors/community. Defining the list of new features for the second version. Mid July - 23th August : Adding a system to make the website as flexible as possible to add/remove tests easily (A pull-request system? A test submission form where admins review tests before they are included in the test suite?) Developing additional features for the website. Making sure that the website can be opened to more browsers (work done at design time to support any browsers will be tested here) Bug fixing Code sample In 2014, I developed the entire AmIUnique.org website from scratch. Its aim is to collect fingerprints to study the current diversity of fingerprints on the Internet while providing full details to users on this subject. It was the first time that I built a complete website from the design phase to its deployment online. One of the first challenge that I encountered was to build a script that would not only use state-of-the-art techniques but that could simply work on the widest variety of browsers. Testing a script for a recent version of a major browser like Chrome and Firefox is an easy task since they implement the latest HTML and JavaScript technologies but making sure that the script runs correctly on older browsers like Internet Explorer is another story. Juggling with a dozen different virtual machines was necessary to obtain a bug-free and stable version of the script. A small beta-test was required to make sure that everything was good to go for what is now the foundations of the AmIUnique website. The totality of the source code for AmIUnique and my other projects can be found on GitHub. A second challenge that I faced was to deal with the increasing load of users so that the server could return personalized statistics to visitors in a timely manner (less than 2/3s). By having a separate entity that updates statistics in real time on top of the database, I managed to drastically reduce the server load. With the number of Tor users around the world, the website needs from the get go to handle a high load of visitors and statistics computation and my previous experience on that specific task will prove useful. For the very first version of Torprinter, I plan on testing well-known and widespread fingerprinting techniques to make sure that there is no variation among Tor users. These include HTTP headers and known JavaScript objects. There should be no need for any Flash attributes since plugins are not present in the Tor browser (thus removing complex code in charge of correctly loading the Flash object). For this proposal, I have also developed a special page with 7 different tests that are mainly targeted at the Tor browser to give an idea of what tests can be included that are more suited to the Tor users. Tests n°5, n°6 and n°7 are broader and also concerns the Firefox browser. You can found a working version of the script on a special webpage (need to scroll to make the results appear): https://plaperdr.github.io/torScript.html The script can be found here: https://plaperdr.github.io/assets/tor/tor.js Test n°1 Test the size of the current window - As reported by ticket n°14098 https://trac.torproject.org/projects/tor/ticket/14098 Test n°2 Test the support of emoji - As reported by ticket n°18172 https://trac.torproject.org/projects/tor/ticket/18172 Test n°3 Analysis of the "scroll" behavior of the window - As investiagted by http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprin… Test n°4 Test the size of current fallback font by using the canvas API to render some text (no need for user permission like canvas extraction) - Custom test Test n°5 Test the difference between OS on the maximum font size - Custom test Test n°6 Test the difference between OS on the Date API - As reported by ticket n°15473 https://trac.torproject.org/projects/tor/ticket/15473 Test n°7 Test the difference between OS on the Math class - As reported by ticket n° 13018 https://trac.torproject.org/projects/tor/ticket/13018 ****************************************************** Any remarks, suggestions or ideas are very welcome! Pierre

5 14

New weekly IRC tor development/network team meeting times start next week
by Nick Mathewson 22 Mar '16

22 Mar '16

Hello! Starting on March 28, we will have two weekly meetings in #tor-dev to talk about developing Tor stuff. NETWORK TEAM MEETING: * Please make this one if you can, and if you work on Tor or some other network team project. It'll be fun. * It is Monday, at 1700 UTC. (That's 1pm EDT and 10am PDT.) * This replaces the old Wednesday meetings. We'll each check in briefly, then discuss stuff that we need to discuss. * The meeting time has been chosen by picking the time at which the most folks could make it. PATCH PARTY: * Patch Party will be extra fun. We'll talk about code and tickets. It will be later in the day for a lot of us, and some will still be waking up, so we'll try to have a pretty chill atmosphere. * If Patch Party is not fun, we are doing something wrong. * It'll be Tuesday, at 2300 UTC. (That's 7pm EDT and 4pm PDT.) * This replaces the old Monday meetings. We'll have a freewheeling chat about patches and upcoming stuff. * If you come and feel like talking about Tor stuff, I'll do my best to make sure it is fun. This all starts next Monday. For this week, we are on the same old times. cheers, -- Nick

1 1

How to build a Router that will only allow Tor users
by Martin Kepplinger 20 Mar '16

20 Mar '16

Hi, I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself. A first test setup (onionoo document, ipset and iptables) kind of worked. It's definitely doable, but not totally trivial in the end. What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to * Guard, * Authority, * and HSDir flagged relays (do I *need* them? that's a different question probably) I don't restrict ports for now, even though I really should, and it's all only IPv4 addresses I care about for now, and I easily could just have OpenWRT configured wrongly, but: DNS is not an issue I think, what else could be? So far I only see Torbrowser talking to one Authority while starting. thanks martin

6 9

Scheduling next proposal discussion meetings
by Isabela 20 Mar '16

20 Mar '16

Hello there, on today's irc meeting we choose 2 proposals to discuss: #224 and #267. I took a look at people's availability in the wiki and picked the following date&time for both meetings: * Proposal 224: Next-Generation Hidden Services in Tor o Wednesday, March 16th 2200 UTC (teor can join) o Must-have attendees: special, dgoulet, asn, teor o Conflicts: (If you are noting a conflict, please include a big bunch of times when you COULD make it.) + ??? o Can-attend: * Proposal 267: Tor Consensus Transparency o Friday, March 18th 1600 UTC o Must-have attendees: ln5, leif o Conflicts: (If you are noting a conflict, please include a big bunch of times when you COULD make it.) + ???? o Can-attend: Please update in the wiki with your options for them. If this date and time does not work, let me know what is a good one in the 'conflicts' notes. https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Meeting… Let me know if you have any questions! cheers, Isabela -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa

5 8

Core Tor / Network Team meeting time updates.
by Nick Mathewson 19 Mar '16

19 Mar '16

Hi, all! I've got a doodle poll open on http://doodle.com/poll/nvx26m4cxspryf3e to try to find the best time for a network team meeting. So far, it looks like our options are somewhat constrained, since we have people who are living from UTC-7 through UTC+11, and a wide range of time zones in between. (Karsten has said he's okay with us picking a time he can only-sorta make. Isabela claims she has no sleep schedule and can meet whenever.) In particular, we're going to have a hard time having both George and Teor on the same meeting, since whenever they're both available, all the west-coast-US people are asleep. Asking people to start meetings before 0800 or after 2200 in their personal time zones is not IMO nice or okay, so let's not try to do that. So, my favorite option ("Find some magical time when everybody can make it") is out. So, as I see it here are our options: A. Pick a time when as many people as possible can attend. Include people who can't make that time by doing one or more of these: A1. Encourage everybody to catch up informally with everybody who can't attend. A2. Work with the people who can't attend, and whoever has a schedule closest to theirs, to make sure that there is a supplemental topic meeting on topics of their joint interest. A3. In addition to meetbot logs, keep minutes of the meetings and send them to tor-dev. B. Try to pick two or more times such that everybody can make one or the other. Try to solve disconnectedness by doing one or more of these: B1. Encourage everybody who can attend both to do so. B2. Make Nick and Isabela attend both. B3. Try to make sure there are at least 3 times, with several people shared pairwise between each. B4. Minutes as above. C. We all move to a nice tropical island. Thoughts? Especially from regular attendees or would-be-regular attendees? peace, -- Nick

3 2

Meeting about the new guard algorithm proposal (prop259)
by George Kadianakis 19 Mar '16

19 Mar '16

Hello there, seems like the prop259 algorithm has kind of stabilized and you guys have jumped into implementation. That's great! A small problem in this process is that I'm probably the only person in Tor who understands the new algorithm right now. We could fix this by doing a small proposal IRC meeting where you guys could summarize the current state of the algorithm, as well as provide some simulation results. I think that folks like Nick, Mike and isis could provide valuable feedback at this point. Would you guys be interested in something like this? I'm fine with doing it next week at some point. Maybe Wednesday or Thursday? Maybe at 15:00 UTC? Let me know if that's convenient for you. Cheers!

4 6

Introducing Snowflake (webrtc pt)
by Serene 18 Mar '16

18 Mar '16

Hi all, Snowflake is a webrtc pluggable transport inspired by flashproxy. (https://gitweb.torproject.org/pluggable-transports/snowflake.git) Arlo, David, and I have made lots of progress on it lately, and it now appears to have reached minimum viability. The following should result in a 100% bootstrap over WebRTC: ``` git clone https://git.torproject.org/pluggable-transports/snowflake.git cd snowflake/client go get go build tor -f torrc ``` In case you have a moment, it'd be cool if you tried it out and let us know whether it works for you. I'd really appreciate hearing about all the thoughts / concerns / issues before we move forward. -- More info -- Q: What are the benefits of this PT compared with other PTs? Snowflake combines the advantages of flashproxy and meek. Primarily: - It has the convenience of Meek, but can support magnitudes more users with negligible CDN costs. (Domain fronting only used for brief signalling / NAT-piercing to setup P2P webrtc which handles the actual traffic) - Arbitrarily high numbers of volunteer proxies are possible like in flashproxy, but NATs are no longer a usability barrier - no need for manual port forwarding! Q: How does it work? 1. Volunteers visit websites which host the "snowflake" proxy. (just like flashproxy) 2. Tor clients automatically find available browser proxies over the domain fronted signaling channel. 3. Tor client and browser proxy establish a WebRTC peer connection. 4. Proxy connects to some relay. 5. Tor occurs. Q: Why is it called Snowflake? There's a bunch of "ICE" negotiation happening for WebRTC, and it also involves a great abundance of ephemeral and short-lived (and special!) volunteer proxies... Anyhow, if Snowflake seems like it would be useful / desired here, it would be awesome if we had more help getting it stable, polished, audited, deployable, etc... Plenty of work to do! <3, ~serene P.S. Make sure you're using a recent version of Go (1.5+) P.P.S. The repo is available in these locations: - https://gitweb.torproject.org/pluggable-transports/snowflake.git - https://github.com/keroserene/snowflake

8 15

[GSoC '16] Exitmap project - Introduction and request for comments
by Mridul Malpotra 18 Mar '16

18 Mar '16

Hi everyone! I'm Mridul. I wish to apply for the Exitmap improvements project mentored by Dr. Philipp Winter for the Google Summer of Code 2016. My current IRC handle is mtyamantau. Contents -------- 1. Introduction - About myself and experience with Tor 2. Exitmap - Current progress and questions 3. GSoC - Rough proposal structure and questions 1. Introduction - About myself and experience with Tor ------------------------------------------------------ I'm Mridul Malpotra, currently in my senior year pursuing bachelors in Computer Science from IIIT Delhi, India. My interests primarily lie in computer networks and network security, specifically anonymous networks like Tor and I2P. Through my now 1-year long undergraduate thesis work under Dr. Sambuddho Chakravarty, I have had exposure to the Tor network, relevant literature and some related projects, which helped me better understand and appreciate the current research and development going on. My work involved manually setting up testbeds through testing Tor networks on our institute intranet as well as on PlanetLab (for those wondering, I had recommended Chutney and Shadow). The current private testing Tor network is running on a PlanetLab slice (iiitd_mridul2) with ~170 nodes globally and 3 directory authorities. I used the control protocol through the Stem library to help in multiple circuit creation and stream attachments for measuring performance of a software over Tor. I have also had experience with open source software, by contributing to the Non intrusive load-monitoring toolkit (NILMTK) which is based on Python and Pandas. While working there, I helped contribute code for additional features, fixed a few bugs and also worked with a few of Python's package management and documentation systems. Relevant links: github.com/nilmtk/nilmtk/commits?author=mridulmalpotra 2. Exitmap - Current progress and questions ------------------------------------------- I recently read about Exitmap in the 'Differential Treatment of Anonymous Users' paper by Khattak et. al. The use case for fast automated scanning through Exitmap to evaluate ~1000 exit nodes was really interesting. On top of that, it fitted my use case of testing a particular software's performance over Tor. Familiarizing myself with the source code, I think I understand the basic layout for how the scanner works and appreciate the modularity of task executions. I followed the project's progress on github and have read the 'Spoiled Onions' paper by Winter et. al. In the coming 2 days, I plan to tinker around more with the code, discuss concerns, issues and/or suggestions if any, and get myself properly familiarized with the codebase. I also have certain ideas regarding what modules could be added and improvements made, some of which I have mentioned in the next section. I will also be reading the tech report on Exitmap and would be grateful if you can recommend any other resource(s) that I should be referring to. Lastly, I had a few queries related to the project and/or paper and apologize for the naivety in the questions if any. a. How was the bifurcation between stand-alone and same-process modules decided? Are there any advantages to allow for multiple forked processes for specific modules? b. For testing active attacks, can there be modules developed keeping other cleartext protocols like SNMP and Telnet in mind? Alternatively, is there a way to determine what protocols are being used over Tor and their popularity? c. How is Exitmap being crowdsourced currently? I'm interested to know how data is being collected from volunteers running the scanner. 3. GSoC - Rough proposal structure and questions ------------------------------------------------ Here I am listing the possible objectives that my project will be focusing on. I request your feedback and comments on the chosen topics and their descriptions. 1. Achieve autonomous scanning in Exitmap with periodic scans that, based on a certain algorithm, fetches relay descriptors and automates various subtasks for consistent data collection and verification. The main challenges that I expect will be intelligently recognizing which tasks to automate and when, and making the entire background process execution efficient in resource consumption. 2. Emulating multiple user interaction in individual modules and in Exitmap overall to provide indistinguishability to Exitmap from regular users. I will try to explore libraries for this purpose like Splinter with Selenium or BeautifulSoup with Requests that help dynamically interaction with the web resource. The main challenges that I expect will be to scale this automated testing alongside the running asynchronous jobs and making the entire scans look like genuine user interactions. Any suggestions on better ways to do this will be helpful. 3. Making the codebase more robust by adding unit test cases. I plan on using either the plain unittest/unittest2 framework or nose/nose2/pytest tools or any other alternatives that I may find or be recommended. I plan to simultaneously write the unit test cases for new code added and improve upon the exiting testing programs. 4. (Optional) I read from the mail threads on the tor-dev mailing list that the code needs to be converted to be Python3 compatible. Would like your opinion on whether it is a viable option and if it is possible, would like to include this in my list of tasks. 5. (Optional) If I can spare time in the milestone timeline and if discussion leads to some clarity, I would like to add another module for more cleartext protocols that could be implemented like SNMP or Telnet. I am also looking at possible local to remote attacks that are active at the application layer and could be tested in Exitmap. I'll update if I find anything. Next, I am drafting a week-wise timeline of what I plan to do over the duration of ~3 months. I will be dividing task 1 and 2 before and after the mid-term, with the optional tasks done in either of the slots and testing done alongside for everything. This is to ensure incremental milestones that can be useful to the community as I develop. Also, as I gain clarity on my objectives, I plan to refine this timeline to a week-wise format with buffers placed accordingly and present it in 2 days time. Lastly, I would appreciate any suggestions, criticism or feedback on this proposal regarding content, volume or specificities. I am looking forward to contributing to the Tor Project organization and interacting with developers here. Thanking you, (long mail I know, sorry) Sincerely, -- Mridul Malpotra Undergrad @ IIIT-Delhi <https://www.iiitd.ac.in/> mridulmalpotra.github.io ============================= PGP keyID: 0xb716e33ab6d0a653 <http://pgp.mit.edu/pks/lookup?op=get&search=0xb716e33ab6d0a653>

3 2

"Not our bug" bugs
by Griffin Boyce 18 Mar '16

18 Mar '16

Hey all, There have been quite a few bug reports that discuss incompatibility with various Firefox extensions and with websites. In most cases, I can't replicate these bugs -- either because the extension in question has been patched, the website reported no longer exists, or the issue can't be replicated (which could be due to site updates and past Firefox incompatibility). Occasionally, the issue is real and still in effect, but isn't really a Tor bug (such as #7279, where a forum restricts logins by Tor users). We've all worked very hard to reduce overly-restrictive blacklist policies, but can't be everything for everyone. In these cases, I'd propose rejecting these bugs as either invalid or `not a bug`. These are all varying degrees of "not our bug" or "actually not a bug at all." Open to more thoughts on this. ~Griffin

2 1

Notes from the prop267 meeting 2016-03-17
by Linus Nordberg 18 Mar '16

18 Mar '16

Hi, Here's a summary of what happened in the prop267 meeting in #tor-dev yesterday with Nick, Tom, Sebastian and myself. Sebastian started by summarising the proposal nicely. Topics discussed: - for bootstrap reasons we can't mandate using tor for all communication - SCT's or not: using SCT's instead of inclusion proofs would lower the burden on operating a log and save bytes on the wire - pushback on suggestion of turning all relays into auditors, reason being increased (code) complexity - there are some differences between "MITM:ing tor" and "MITM:ing on the internet", one being that a tor mitm is the controlling of a majority of the dirauth keys, which in many cases is more persistent than an IP layer MITM - the "eventually you escape a MITM" hand waving is problematic - we need a story on how a perfectly tor-MITM:ed TAILS user get back to the real network - relays and clients must check consensus documents the same way - hard fail or not when consensus isn't shown to be in a log? - handling of changes in the set of dirauths Identified next steps: - add text about what needs to be and what should be anonymised, taking bootstrapping issues into account - decide on replacing SHA2-256 with SHA3-512 or SHA2-512||SHA3-512 (taking availability of implementations into account) - decide on using SCT's or not - analyse the "TAILS user under MITM" case - analyse "set of dirauths changing" What did I miss? Full logs can be found at http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-03-17-14.58.log.html

1 0

What does TorBulkExitList.py return?
by Linus Nordberg 17 Mar '16

17 Mar '16

Hi, I'm trying to figure out why a list from [TorBulkExitList.py] is so much larger than what is seen in [exit-addresses]. Point in case: Earlier today the list from TorBulkExitList.py contained 58% more addresses than exit-addresses: --8<---------------cut here---------------start------------->8--- $ curl-tor -q 'https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8' | egrep -v ^# | wc -l 1554 $ curl-tor -q https://check.torproject.org/exit-addresses | egrep ^ExitNode | wc -l 985 --8<---------------cut here---------------end--------------->8--- Counting relays with the Exit flag in a consensus of roughly the same time gives 912: --8<---------------cut here---------------start------------->8--- $ curl-tor -q http://171.25.193.9:443/tor/status-vote/current/consensus | egrep '^s.*Exit' | wc -l 912 --8<---------------cut here---------------end--------------->8--- If I read the code [check.py][exitips.py] correctly, we include the following IP addresses in what is served from [TorBulkExitList.py]: - all routers in the current consensus - with exit addresses from TorDNSEL file(s) added - for which stem's exit_policy.is_exiting_allowed() returns true I haven't read any TorDNSEL code and don't know exactly what above mentioned TorDNSEL file(s) are but I think they include results from active testing of what address exit relays really use for exiting. [exit-addresses] seems to be from TorDNSEL too but holding more of a snapshot while the files mentioned above supposedly cover some period of time. Before I dig further, perhaps someone here already know why the numbers differ so? I wouldn't expect the churn of addresses used for exiting to be high enough to explain the difference. [TorBulkExitList.py] https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 [exit-addresses] https://check.torproject.org/exit-addresses [check.go] https://gitweb.torproject.org/check.git/tree/check.go [exitips.py] https://gitweb.torproject.org/check.git/tree/scripts/exitips.py Thanks, Linus

2 1

Revisiting prop224 cells
by George Kadianakis 16 Mar '16

16 Mar '16

Hello, I took a look at proposal 224 again, with the aim of revisiting the cell logic and format. Here are some matters that require discussion: 1) Should we keep backwards compability with old introduction and rendezvous points? Currently, proposal 224 actually tries to maintain backwards compatbility but at the cost of complicating the design. Specifically, to achieve backwards compatibility we need at least the following functionality: - Hidden services need to generate and publish an extra encryption key for each legacy introduction point (legacy enc-key). - Hidden services need a new cell subtype to register themselves to legacy introduction points (LEGACY_EST_INTRO). - Clients need a new cell to introduce themselves through legacy introduction points (LEGACY-INTRODUCE1) The above features are not extremely hard to implement, but because of their hacky backwards-compatible nature they do complicate the protocol and the code. Also, at some point when the network has upgraded we will have to rip this code off our codebase, otherwise it will just rot there. Also also, we will have to write non-trivial chutney tests to ensure the correctness of the backwards compatibility logic. Alternatively, we could choose to completely drop backwards compatibility with old introduction and rendezvous points. This means, that we will have to wait till a good part of the network has upgraded before we enable prop224 support for clients and services. This means that we will probably have to wait a whole release cycle (till the relay-side prop224 code becomes stable; is that 6 months?) before we can globally enable the client/HS prop224 functionality (although we can use the network ourselves for testing prop224 till then). What do you people think we should do here? Paradoxically, I'm currently thinking of _keeping_ the backwards compatibility design. Looking at the spec it seems like a medium difficulty engineering issue for us (maybe an 8% of the total prop224 task size), which sucks, but at least we don't have to worry about doing proper incremental deployment of prop224 on the network and worrying about release cycles. Also, as we move towards implementing prop224 cells, we can reevaluate our position here. I'm not confident about my position here, so feedback would be helpful. 2) I'd like to simplify the ESTABLISH_INTRO logic. Currently, ESTABLISH_INTRO seems like a needlessly _complex_ cell that is also _incomplete_. It's _complex_ because it takes 3 different forms depending on the value of its first byte. This complexity is caused partially by our backwards compability needs (see above), but also because we tried to cram the MAINT_INTRO message into this cell. It's _incomplete_ because it does not actually contain the "introduction point encryption key", so hidden services are forced to send the encryption key right after the initial ESTABLISH_INTRO cell using a second ESTABLISH_INTRO cell that is actually a MAINT_INTRO/UPDATE-KEYS-SUBCMD message. I have two suggestions here: * Let's include the intro point encryption key in the ESTABLISH_INTRO cell, so that hidden services can establish intro with a single cell (not for performance, but for simplicity). * Let's introduce a new cell type for MAINT_INTRO instead of cramming it into ESTABLISH_INTRO. Or at least, let's make it an extension of ESTABLISH_INTRO instead of using the first byte of the cell to get the cell subtype. What do you think? Also, this brings me to the next topic which is: 3) What is UPDATE-KEYS-SUBCMD good for? And why do intro points need to know the intro point encryption key? UPDATE-KEYS-SUBCMD seems to be the only use of MAINT_INTRO currently. It seems to be able to update the encryption keys of an introduction point circuit on the fly. But why does the introduction point need to know the encryption key in the first place? That key is only used by clients and hidden services to encrypt stuff end-to-end to each other. After discussing with dgoulet, the only reason I can think of is that so that the IP is aware of the encryption key, and if an incoming client Alice does not know the correct encryption key, then the IP can send it to her using an INTRODUCE_ACK message with [00 02] (and then Alice does not need to refetch the descriptor). But why would a client know the authentication key but not the encryption key? Do they have different rotation times? Why would the encryption key rotate before the authentication key? Maybe all these things are not necessary for now and we can just ditch UPDATE-KEYS-SUBCMD completely, assuming that both of those keys have the same rotation lifetime? And maybe even the IP does not need to know the encryption key at all? Am I missing something? Cheers!

3 2

Notes from network team meeting Wed 3/16/2016
by Isabela 16 Mar '16

16 Mar '16

Hello there, this is something new we are trying out. The goal is to improve communication between team members, since we are spread out through many different time zones and is hard to get everyone together at the same time for discussions and updates. == Notes from little t Tor team - Wed March 16th 13:30 UTC @ #tor-dev == Participants + updates: * nickm - trying to get 028 done, getting ready to help with 029 triage, fixing that old 027-authorities bug, and trying to make sure that all the sponsorS EOM items get done, special focus on module isolation right now * isabela - sent a few emails with exercise to start triaging for 029 / working on a proposal for our release process * dgoulet - working on prop#224 (#17238, dev branch ticket17238_029_01) / reviewed 028 tickets and cleaned up the "tor-hs" ticket queue also / plan on triaging for 029 by Friday then PlanetLibre * asn - worked mostly on prop224 - wrote a thread about design issues (https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html) / working on GSoC preparations and review queue is empty so can help review code if needed * special - nothing much to report, been busy with travel and auxiliary responsibilities :< * Sebastian - helped implement 'sponsor' field on Trac / has ~8hrs next week to work on something that needs help * karsten - tried to find 028 tickets that need review, found one that's actually mine and that needed work, worked on that (#18460) == Discussion topics and action items: Triage 029 - first triage exercise is to mark sponsor tickets as: * 'sponsorY-must' means "We have promised this to sponsorY." * 'sponsorY-can' means "We can bill this to sponsorY, but we haven't promised this specifically." We will be looking into sponsor S, U and R tickets. Isabela sent a spreadsheet via email for people to use and mark the tickets. We should get it done by Friday EOM so we can move on with another triage exercise. If you have any questions, please reach out to isabela via irc or email. Meeting time discussion: Is impossible to have something that will work perfectly for everyone. We discussed a few possible solutions that Nick will compile and email the list to continue the discussion with other members of the team. We also decided on sharing meeting notes beyond the meet bot log. Triagging 'must-fix-before-028-rc': During this discussion we also ended up deciding on creating a new state for the review process 'need-merge', so when a ticket is done with the review process goes to this state. This is the equivalent to 'needs-nick-review' state we discussed during the Dev Meeting discussion. Some of the action items from the discussion are listed below. Mostly for folks to review tickets so we can close them and move one with 028-rc. Action Items ------------ * everybody look at https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html * nickm and dgoulet see if they have time to hang out when dgoulet is around for libreplanet * isabela to write her thoughts on release-engineering this stuff, and making broken things easier to revert * somebody open a ticket for a network-team mailing list : #18563 [DONE] * nickm will send an email about meeting times. * if you think something is in must-fix-before-028-rc and we can let it slip, please comment on the ticket. [people worked on it after the meeting] * dgoulet, Sebastian, teor: please take another look at the ed25519 patch and see if I fixed the issues in #18318 and #17668 ? * let's see if we can get weasel (or somebody else) to review or test my fix for #18253 * nickm asks athena for ETA on bugfix. == Next meeting and other updates: * I guess next meeting will depend on the results of the meeting time poll - we will keep the list updated. * We are having a proposal discussion meeting tomorrow, Thursday March 17th at 1500UTC - prop#267 * We had a proposal discussion meeting today as well, Wednesday March 16yh, on prop#224. You can check the log here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-03-16-15.03.html -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa

1 0

Come work on Tor at Freedom of the Press Foundation!
by Garrett Robinson 16 Mar '16

16 Mar '16

Hello tor-devizens, Freedom of the Press Foundation is hosting a Mozilla-Ford Open Web Fellow for 2016. We have a lot of potential projects for our fellow to work on, depending on their skill set, but we have our fingers crossed for an applicant who is interested in working on Tor! SecureDrop, our flagship project, depends heavily on Tor and Tor Hidden Services to protect the communications of journalists and anonymous sources. If we end up accepting such an applicant, we would like to have them work with the Tor Project on issues that are pertinent to SecureDrop, particularly Next Generation Hidden Services and the proposed padding defenses for website fingerprinting attacks. The deadline for applications is *March 20th* (this Sunday). More info on our blog: https://freedom.press/blog/2016/01/apply-be-freedom-press-foundations-open-… Apply: https://advocacy.mozilla.org/open-web-fellows/ Let me know if you have any questions! You can reply to this email on the list, or email me directly. Cheers, Garrett

1 0