- tor-dev - lists.torproject.org

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]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> [View Less]

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 … [View More]

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) … [View More]

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 | … [View More]

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 … [View More]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! [View Less]

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 … [View More]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 [View Less]

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 … [View More]

1 0