tor-dev March 2017

tor-dev@lists.torproject.org

51 participants
41 discussions

GSoC 2017 Project Idea
by Sakchham Sharma 13 Mar '17

13 Mar '17

Greetings Tor Community, I am Sakchham Sharma a CS Undergrad student, I intend to participate in GSoC 2017 and contribute to the Tor Project. The Tor Project as so now is quite well known among the people with a technical background, but however, the people who don't belong to this category have little or no idea about Tor, they are perhaps the people that would benefit the most from Tor. So in order to help people better understand about Tor, that how it is different from their VPN or Proxy service, I intend to an UI Redesign of the Orbot app for android, as of now it has a minimalistic UI and several UI glitches, an UI that also gives the users a subtle idea as to how tor works with be informative and should help more people know more about Tor, I would be grateful if I could get suggestions/improvements on the above idea. Thank you. <https://mailtrack.io/> Sent with Mailtrack <https://mailtrack.io/install?source=signature&lang=en&referral=sakchhams@gm…>

3 3

GSOC Contribution Into and Help
by Anshul Malik 12 Mar '17

12 Mar '17

Hi there! I am Anshul, computer science undergrad from NIT, Kurukshetra, India. I really like using tor, always wanted to contribute somhow, and here google gives me a chance. I am a good programmer, have been doing projects with node, recently also started with python django. I have also contributed to firefox devtools. I wish to contribute to *Ahima- Hidden Service Search* I saw ideas list on the page, I can definitely work on - Automate blacklisting - Add hidden services function - Elastic Search Just need a headstart, Please let me know where can I find contribution guide and some more information about Ahima, I am currently studying the architecture and codebase from github. Thanks

2 1

GSoC 17- Intro
by Pasan Chamikara 12 Mar '17

12 Mar '17

Hi, I am Pasan Chamiekara, a final year undergraduate in BSc in Biological Science at University of Colombo and a final year undergraduate at Sri Lanka Institute of Information Technology (BSc Hons in IT specializing in Cyber Security). (Simply a dual degree expectee) . I do pocess 7 months of completed internship at Sri Lanka CERT | CC as an Intern - Information Security. My main research interests are in automated malware analysis, Intrusion detection and Neural Networking. I do pocess strong skills in html, css, php, javascript, python, C, C++ ,java, ASM and intermediate level skills in Android,scala. I am interested in the following components, *Ahmia - Hidden Service Search* Regards Pasan

2 1

Re: [tor-dev] Flashproxy has been Deactivated by Stanford? Why?
by David Fifield 12 Mar '17

12 Mar '17

On Tue, Dec 20, 2016 at 01:21:04AM +0800, tomli(a)riseup.net wrote: > It turned out that the entire code has been commented out and apparently > Flashproxy became > out of service. Why? Has the project discontinued, or just down for > maintenance? Flash proxy is basically retired now. It was removed from Tor Browser a year ago (https://bugs.torproject.org/17428) after it had been supplanted by more effective transports. I don't know why there was a blog post on December 16 promoting flash proxy, because it's no longer used. Even when flash proxy was part of Tor Browser, it had very few users (less than 100; see https://metrics.torproject.org/userstats-bridge-transport.html?start=2013-0…), probably because of the difficulty of running it as a client (https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/Flash…). Compare those user numbers to meek (current about 10K) or obfs4 (30K). The reason I haven't asked people to stop running the flash proxy badge is we're working on a new pluggable transport along the same lines but without the usability challenges: https://trac.torproject.org/projects/tor/wiki/doc/Snowflake. I was thinking about adapting existing flash proxy badges to provide capacity to Snowflake instead. This would go for Cupcake as well. The need to get the badge running again hasn't been pressing because Snowflake isn't deployed yet, but we're getting close. The badge was deactivated by Stanford (without my knowledge, but I found out a while ago). I arranged with them to move it to alternate hosting and have them install a redirect, but that has been a low priority behind other work on Snowflake. I'm sorry about the confusion. If I get some time I'll add a notice to the flash proxy main page saying that it's been retired.

2 2

Flag blocked websites
by Boter42 11 Mar '17

11 Mar '17

Hi, I think it would be important to have a way to flag/report those websites that can't be access by the users while they're using the tor browser. Is there already a solution to do this? Do you think it would be a good tool? It would be great to have an updated records of this kind of websites so that we can push website owners to make the Tor user-experience as smooth as possible. Thanks

3 7

[PATCH] prop224: Trivial improvements to HS ntor section
by George Kadianakis 09 Mar '17

09 Mar '17

Hey David, please check my `prop224-ntor` torspec branch for some basic improvements to the HS ntor section that came up while implementing it. Here it is: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-ntor Let me know if you like them and I will merge them ASAP. Cheers!

1 1

Tor Arch Diagrams
by chelsea komlo 09 Mar '17

09 Mar '17

Hello All, I've published object diagrams created from a conversation with Nick at the last Tor meeting, along with the original sketches (hopefully very similar). github.com/chelseakomlo/tor_arch The plan for these is to include them into documentation. These should definitely evolve along with tor's architecture, so please don't think of them as set in stone. A couple questions/comments: - What else should be included? The most important thing is that these are good visual assets for future discussions on topics such as modularization, where code/responsibility should belong, if any new structures are needed, etc. - Some of these may need more information. For example, the scheduler diagram. - If object diagrams do not capture tor's architecture accurately, we can also look at event modeling. This would model what happens as different events occur from start to finish in the tor network. - If it is useful for these to be UML, I can do that. But more importantly is that they are useful. Feedback welcome! Chelsea

2 2

Tor in Google Summer of Code 2017
by Damian Johnson 07 Mar '17

07 Mar '17

Interested in coding on Tor and getting paid for it by Google? If you are a student, we have good news for you: we have been accepted as a mentoring organization for Google Summer of Code 2017! https://summerofcode.withgoogle.com/organizations/5675829762719744/ Here's the facts: GSoC gives you the opportunity to work on your own Tor-related coding project with one of the Tor developers as your mentor. Your mentor will help you when you're stuck and guide you in becoming part of the Tor community. Google pays you for the three months of your project, so that you can focus on coding and don't have to worry about how to pay your bills. https://www.torproject.org/getinvolved/volunteer.html.en#Projects Did we catch your attention? These are your next steps: Go look at the Google Summer of Code FAQ [1] to make sure you are eligible to participate. Have a look at our ideas list [2] to see if one of those projects matches your interests. If there is no project on that list that you'd want to work on, read the documentation on our website [3] and make up your own! Come to #tor-dev on OFTC [4] or let us know about your project idea here. Communication is essential to success in the summer of code, and we're unlikely to accept students we haven't heard from before reading their application. So really, speak up on this list or come to our IRC channel and talk to us! Finally, write down your project idea using our template [5] and submit your application to Google before March 25th [6]. We are looking forward to discussing your project idea with you! [1] https://developers.google.com/open-source/gsoc/faq [2] https://www.torproject.org/getinvolved/volunteer.html.en#Coding [3] https://www.torproject.org/docs/documentation.html.en#UpToSpeed [4] https://www.torproject.org/about/contact.html.en#irc [5] https://www.torproject.org/about/gsoc.html.en#Template [6] https://developers.google.com/open-source/gsoc/timeline

2 2

Proposal: Directory Compression Scheme Negotiation
by Alexander Færøy 06 Mar '17

06 Mar '17

Hello, Here's my draft proposal for extending the directory protocol to support compression scheme negotiation using the semantics of the HTTP protocol. This is part of the work that Nick and I are looking into for our Sponsor4 design. All feedback is highly appreciated :-) Cheers, Alex. Filename: xxx-directory-compression-scheme-negotiation.txt Title: Directory Compression Scheme Negotiation Author: Alexander Færøy Created: 2017-03-06 Status: Draft Target: N/A 0. Overview This document describes a method to provide and use different compression schemes in Tor's directory specification[0] and let it be up the client and server to negotiate a mutually supported scheme using the semantics of the HTTP protocol. Furthermore this proposal also extends Tor's directory protocol with support for the LZMA2 and Zstandard compression schemes. 1. Motivation Currently Tor serves each directory client with its different document flavours in either an uncompressed format or, if the client adds a ".z"-suffix to the URL file path, a zlib-compressed document. This have historically been non-problematic, but it disallows us from easily extending the set of supported compression schemes. Some of the problems this proposal is trying to aid: - We currently only support zlib-based compression schemes and there is no way for directory servers or clients to announce which compression schemes they support. Zlib might not be the ideal compression scheme for all purposes. - It is not easily possible to add support for additional compression schemes without adding additional file extensions or flavours of the directory documents. - In low-bandwidth and/or low-memory client scenarios it is useful to be able to limit the amount of supported compression schemes to have a client only support the most efficient compression scheme for the given use-case and have the directory servers support the most commonly available compression schemes used throughout the network. - We add support for the LZMA2 compression scheme, which yields better compressed size and decompression time at the expensive of higher compression time and higher memory usage. - We add support for the Zstandard compression scheme, which yields better compression ratio than GZip, but slightly worse than LZMA2, but with a smaller CPU and memory footprint than LZMA2. 2. Analysis We investigated the compression ratio, memory usage, memory allocation strategies, and execution time for compression and decompression of the GZip, BZip2, LZMA2, and Zstandard compression schemes at compression levels 1 through 9. The data used in this analysis can be found in [1] and the `bench` tool for generating the data can be found in [2]. During the preparation for this proposal Nick have analysed compressing consensus diffs using both GZip, LZMA2, and Zstandard. The result of Nick's analysis can be found in [3]. We must continue to support both "gzip", "deflate", and "identity" which are the currently available compression schemes in the Tor network. Further to enhance the compression ratio Nick have also worked on proposal #274 (Rotate onion keys less frequently), #275 (Stop including meaningful "published" time in microdescriptor consensus), #276 (Report bandwidth with lower granularity in consensus documents), and #277 (Detect multiple relay instances running with same ID) which all aid in making our consensus documents less dynamic. 3. Proposal We extend the directory client requests to include the "Accept-Encoding" header as part of its request. The "Accept-Encoding" header should contain a comma-separated list of names of the compression schemes of which the client supports. For example: GET / HTTP/1.0 Accept-Encoding: zstd, xz, gzip, deflate When a directory server receives a request with the "Accept-Encoding" header included it must decide on a mutually supported compression scheme and add the "Content-Encoding" header to its response and thus notifying the client of its decision. The "Content-Encoding" header can at most contain one supported compression scheme. If no mutual compression scheme can be negotiated the server must respond with an HTTP error status code of 415 "Unsupported Media Type". For example: HTTP/1.0 200 OK Content-Length: 1337 Connection: close Content-Encoding: zstd Currently supported compression scheme names includes "identity", "gzip", and "deflate". This proposal adds two additional compression scheme named "xz" (LZMA2) and "zstd" (Zstandard). All compression scheme names are case-insensitive. The "deflate", "gzip", and "identity" compression schemes must be supported by directory servers for backwards compatibility. Additionally, when a client, that supports this proposals, makes a request to a directory document with the ".z"-suffix it must send an ordered set of supported compression schemes where the last elements in the set contains compression schemes that are supported by all of the currently available Tor nodes ("gzip", "deflate", "identity"). In this way older relays will simply respond with the document compressed using zlib deflate without any prior knowledge of the newly added compression schemes. The "Content-Length" header contains the number of compressed bytes sent to the client. The new compression schemes will be available for directory clients over both clearnet and BEGIN_DIR-style connections. 4. Security Implications 4.1 Compression and Decompression Bombs We currently detect compression and decompression "bombs" and must continue to do so with any additional compression schemes that we add. The detection of compression and decompression bombs are handled in `is_compression_bomb()` in torgzip.c and the same functionality is used both for compression and decompression. These functions must be extended to support LZMA2 and Zstandard. 4.2 Detection of Compression Algorithms To ensure that we do not pass compressed data through the incorrect decompression handler, when we have received data from another peer, Tor tries to detect the compression scheme in `detect_compression_method()`` in torgzip.c. This function should be extended to also detect the LZMA2 and Zstandard formats. Possible methods of applying this detection is looking at xz-tools, zstd's CLI, and the libmagic 'compress' module. 4.3 Fingerprinting All clients should aim at supporting the same set of supported compression schemes to avoid fingerprinting. 5. Compatibility This proposal does not break any backwards compatibility. Tor will continue to support serving uncompressed and zlib-compressed objects using the method defined in the directory specification[0], but will allow newer clients to negotiate a mutually supported compression scheme. 6. Performance and Scalability Each newly added compression scheme adds to the compression cache of a relay, which increases the memory requirements of a relay. The LZMA2 compression scheme yields better compression ratio at the expense of higher memory and CPU requirements for compression and slightly higher memory and CPU requirements for decompression. The Zstandard compression scheme yields better compression ratio than GZip does, but does not suffer from the same high CPU and memory requirements for compression as LZMA2 does. Because of the high requirements for CPU and memory usage for LZMA2 it is possible that we do not support this scheme for all available documents or that we only support it in situations where it is possible to pre-compute and cache the compressed document. 7. References [0]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt [1]: https://docs.google.com/spreadsheets/d/1devQlUOzMPStqUl9mPawFWP99xSsRM8xWv7… [2]: https://gitlab.com/ahf/tor-sponsor4-compression [3]: https://github.com/nmathewson/consensus-diff-analysis -- Alexander Færøy

1 0

Unable to Join the IRC Channel #tor.
by Siddharth Bhayana 01 Mar '17

01 Mar '17

It's my first time entering an IRC channel and after having read the documentation for ChatZilla, I'm still unable to find my way. These are the steps I've been following: 1) Open ChatZilla extension on Firefox. 2) Click on IRC -> Join Channel. 3) The two fields that appear are - Network and Channel. From this point on, I have no idea as to how to proceed. Any help would be appreciated. -- Thanks and regards Siddharth Bhayana

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev March 2017