tor-dev March 2014

tor-dev@lists.torproject.org

84 participants
103 discussions

Re: [tor-dev] Torbirdy
by mujnabed＠gmail.com 18 Mar '14

18 Mar '14

Hi, Thanks for the feedback. I have done some work in javacript and c++ and am comfortable coding in both, which is one of the reasons I chose the project. So I'll go ahead and submit my application at the max by tomorrow. Also can I edit the final project proposal once its submitted to melange ? Anyway thanks for all the help. Regards D

1 0

Another weekly tor dev meeting, 19:00 UTC on Wednesday 3/19
by Nick Mathewson 18 Mar '14

18 Mar '14

Hi, friends! This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday. The meeting time will be: Wednesday March 12, 19:00 UTC. (That's 3pm EST and 12:00 noon PST) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. peace, -- Nick

1 0

[RELEASE] Torsocks 2.0.0-rc5/6
by David Goulet 17 Mar '14

17 Mar '14

Hi everyone! Here is the release candidate 5 *and* 6 for Torsocks 2.x. Unfortunately, right after the release 5, I've noticed a critical issue that made the new allow inbound option misbehaved quite badly so I'm immediately releasing rc6 containing that fix. Basically, you can ignore rc5 if you prefer. Sorry for that! A new option has been introduced to allow inbound connections (that were previously blocked in rc4). The torsocks.conf new option is "AllowInbound 0|1" set to 0 by default meaning listen/accept is *blocked* for remote connections only so the localhost is *alway* allowed. This fixes the "ssh -L/-D" use cases to open a listening socket. Again, *by default* any localhost socket will work so this example out of the box should work properly: $ ssh -D8080 yourserver.com You will notice a "listen: Operation not permitted" with the above command because by default ssh tries to connect to IPv6 localhost but fail somehow. I'm aware of the issue but will need much more investiguation to fix but it's not a show stopper. Furthermore, whois was not working because fclose() is used to close the socket and torsocks was not tracking that call thus failing to see the close connection. This was NOT triggering any leak but whois was simply not working. This has been fixed which is an important use case for Tails. Here is the change log for both versions. 2014-03-17 torsocks 2.0.0-rc6 * Fix: set addr len for getsockname in accept * Fix: use socket fd and NOT sockaddr in accept 2014-03-17 torsocks 2.0.0-rc5 * Fix: strict aliasing in library * Add fclose() support * Fix: add torsocks.conf option type * Add option to allow inbound connections * Fix: handle NULL node in getaddrinfo Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Git: https://github.com/dgoulet/torsocks.git (mirror: https://gitweb.torproject.org/user/dgoulet/torsocks.git) Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc6.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2.asc) Cheers! David

2 1

A simple HTTP transport and big ideas
by David Fifield 17 Mar '14

17 Mar '14

Here is a repository containing a simple HTTP-based transport. git clone https://www.bamsoftware.com/git/meek.git cd meek/meek-client export GOPATH=~/go go get go build tor -f torrc Usually when you think of an HTTP transport, you think of something that steganographically tries to make something look like plain HTTP requests and responses. Try and forget that idea for now, because that's not what I have in mind. The protocol is simple. The client generates a random string to serve as a session id. It puts this session id in a POST to the server. The server has a map from session ids to ORPort connections; if the POST's id is not in the map, the server creates a new ORPort connection, otherwise it uses an existing one. The server copies the POST body to the ORPort, and copies a block of data from the ORPort to the HTTP response. The client receives the response, and when it has more to send, it does another POST (with the same session id). Then repeat. How do we prevent 1) fingerprinting of the HTTP requests and 2) blocking of the HTTP server? The answer to (1) is that the HTTP requests are really HTTPS: the censor gets to see where they are going but not what is inside them. The answer to (2) is hinted at by the Bridge line: Bridge meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com We use Google App Engine as a middleman, using a trick to make it look as if we're talking to www.google.com. This transport can get through as long as https://www.google.com/ is unblocked, even if App Engine is blocked. (Up to things like TLS fingerprinting and traffic analysis, which we need to think about.) Like flash proxy, this transport doesn't need bridge distribution. The torrc has everything you need to make it work. Unlike flash proxy, it works without any port forwarding games. Now for the big ideas. This transport is similar to https://trac.torproject.org/projects/tor/wiki/doc/GoAgent in its use of App Engine. However, GoAgent requires every user to upload their own instance of the app server. I propose that we run a server for use by the public and see how much it costs. (App Engine's free tier gives you 1 GB a day and above that it costs money.) If the cost is comparable to that of running a fast relay, it might make sense to fund on an ongoing basis. As a student I have $1000 in App Engine credit that I wouldn't mind burning on the experiment. A simple PHP script can do the work of the App Engine server component: all it does is copy HTTP requests and responses. By using PHP as a middleman, you lose Google's too-big-to-fail unblockability, but you gain an easy way to set up lots of bridges. Such a PHP bridge would not even require a shell account, just a PHP web host. Conceivably such bridges could even be distributed through BridgeDB. Thinking about transport composition, scramblesuit|meek could be an interesting thing. What this would mean is that your client makes an HTTP request to some server, containing a POST body with the beginning of a ScrambleSuit conversation. If you have the shared secret, the server replies with 200 and you start communication. If you don't have the shared secret, the server replies with a 404 (or even 200 with an ordinary web page). What it means is that there can be a magic URL that only you (holder of the shared secret) can use as a bridge. It could even be on a real web site with real pages and everything. ScrambleSuit would additionally provide some diversity of packet lengths and timing. The Google fronting trick, it turns out, also works on CloudFlare sites, which are many. If we ran a bridge as a web app on CloudFlare, even if our web app is blocked, a censored user could access it through the name of any CloudFlare site that supports HTTPS. There may be other CDN-like systems that work similarly. The software is working (try it!) though of course there are always lots of things to do. I'd like the client to be able to pin the certificate of www.google.com. We need the client to use TLS that looks like that of a browser (now it is just using Go's built-in HTTPS support). There are some constant buffer sizes and polling timeouts; they can probably be tuned for better performance. David Fifield

1 2

Re: [tor-dev] Torbirdy
by D 17 Mar '14

17 Mar '14

Hi Sukhbir, Thanks for the quick reply and clarification. > We already have code ready for generating random > message-IDs Yeah I saw the SHA-512 based random message-ID insertion in your Thunderbird+Tor paper. >> 3. And using extension hooks with explicit calls instead of checking user >> set configurations flags for removing timestamp data from header. This it's >> suggested will allow better handling of messages received/sent in the >> background by Thunderbird. > Yes, that's correct. Figuring out how to do this and doing it properly > is the only blocker Right, so start with fixing the preference setting system using extension hooks instead of preference flags. Then work with the new preference system on issues #6314, #6315. Finally, verify stability across different MUA's,MTA's for the updated patches, submit the patch request to #902573 & #902580 and work with Mozilla for patch request acceptance. Does this process flow sound reasonable ? Should I give a more elaborate write-up on the it for you to proof-read or should I just give you the final project proposal for proof-reading ? The only prior experience I have with extension development was on Gnome and it was minimal. But I've started reading up on extension development in Thunderbird and the Torbirdy code. Should be able to run by you a more detailed project proposal soon. Thanks D

2 1

GsoC - Interested in "Revamp GetTor"
by Israel Leiva 17 Mar '14

17 Mar '14

Hi! My name is Israel Leiva, I'm a computer science student at University of Santiago, Chile. More info about me in [1]. I'm interested in the 'Revamp GetTor' project for the Google summer of code. I think that GetTor has a huge impact on how to avoid censorship, and therefore it could be expanded to do a lot more of what it does now. Here is my idea: i) A modular design, with a core module in charge of transmitting data to the others modules, each one of them would represent a different "service" (e.g. SMTP) ii) The core module will be in charge of receiving requests from the other modules and answer them. For example, the SMTP module will say "Give me the URL links for TBB in this language" and the core module will answer with the desired links. These links could be retrieved from several locations, my proposal is that the links could be stored in a private git repository available only to trusted Tor developers, so the links and other data could vary with time according to the different censorship behaviours. iii) As I said, the other modules will each represent a different "service". I propose the following three for starting: * SMTP: Enhance the current bot. I tried it a couple of days ago and it didn't work as I expected (sent me a windows link when I asked for linux). * Twitter: this module will answer requests via twitter, either via mentions or via direct messages. It will ask for the corresponding links to the core module. There are lots of bots implemented out there, no need to reinvent the wheel. * Skype: this module will listen for calls or chats and will answer with a file transfer or message with the links. I believe this can be done using the sevabot [2] in Python or the Skype::Any [3] in Perl. The main idea is that this new design would allow for new services to be implemented in the future. ** OTHER IDEAS ** Here are some minor ideas that could also be considered: a) Most OS bring tools to make DNS requests, and an (experimented) user could make custom requests for TXT records that contain links. I know this isn't the case for most people, but it could be helpful. b) Users could send formatted mails with their public PGP keys to the SMTP service, and the bot will answer them with encrypted content. c) Users could notify services with censored links, this means that if, for example, a user requests the links via SMTP and one of them has been blocked, he/she could send a message notifying this to the SMTP service. This info along with stats about which services are more popular will be saved in a log file (I think this is how is working now) and/or a database. The purpose of this data will be to enhance GetTor, no info about users will be recorded. d) Other option to storage could be Github (as you may know, repos can be downloaded as ZIP files). e) For all the above, GetTor will need official twitter/github accounts. f) Comunication between modules could be done via system commands, but I'm open to any other suggestions. This communication will involve sending links (trusted servers, github repo, dropbox accounts) or local uris (~/tbb/latest.tgz). A basic diagram representing what I've tried to explain can be found on [4]. I think the best way to achieve this is to rewrite GetTor, but if you choose extend the current code to do it I'm okay with it. If you choose the former, I could do it in Python, eventhough I have a lot more experience in Perl (I've coded a module to automate the grading of programming tasks [5]). This is just a draft, please let me know if you find this is the way to go and I'll work in the details and a possible timeline to see how much can be done in 4 months. [1] http://ileiva.github.io [2] https://github.com/opensourcehacker/sevabot [3] http://search.cpan.org/~akiym/Skype-Any-0.06/lib/Skype/Any.pm [4] https://raw.github.com/ileiva/Tor/master/revamp-gettor-simplediagram.txt [5] https://metacpan.org/author/ILV best. -- israel

2 2

GSoC Submission Deadline is Friday (3/21)
by Damian Johnson 17 Mar '14

17 Mar '14

Hi all. Just a friendly reminder that we're fast approaching the deadline for student applications for Google Summer of Code. If you're procrastinating until the last minute then please don't! It's better to get an application in early so we can iterate on it with you. Cheers! -Damian

1 0

Torbirdy
by mujnabed sol 16 Mar '14

16 Mar '14

Hello everyone, I'm in my final year of B.E in Electronics & Instrumentation Engineer and M.Sc in Mathematics from BITS Pilani, India. I was hoping to get a chance to work with the Tor community through this years GSOC. I was reading the projects list and was interested in contributing to the Torbirdy project as I have some experience in coding in Javascript. I wanted to clarify my understanding of the current status of the project. The project requires resolving two issues related to location anonymity weakening due to local timestamp leakage specifically in the MessageID & Date header fields. >From reading issues #6314, #6315 mentioned and the patch requests submitted for bugs #902573 and #902580 at bugzilla.mozilla.org, It seems that the current hold up by Mozilla to accepting the patch request are: 1. Establishing how well Thunderbird & other mail clients handle the date not being inserted by the sender in the mail header 2. Finding which MTA/MSA's automatically insert date headers on their own and if most/all don't, finding a workaround to that. Gmai, Mail.com, Gmx, Yandex and the now dead Lavabit had been tested successfully for automatic date header insertion 3. And using extension hooks with explicit calls instead of checking user set configurations flags for removing timestamp data from header. This it's suggested will allow better handling of messages received/sent in the background by Thunderbird. If someone can let me know if this is the current status of the project or if there are some details I'm missing or even if I've completely missed the point it would be great. Thanks and sorry for the longish mail D

2 1

TBB for Chromebooks?
by Griffin Boyce 16 Mar '14

16 Mar '14

Hello all, Is there a plan to port TBB for chromebooks?

2 1

Feasibility of using a Tor Browser plugin as a PT component?
by David Fifield 16 Mar '14

16 Mar '14

We're making progress on meek (https://trac.torproject.org/projects/tor/wiki/doc/meek), the transport that hides your traffic in HTTPS requests to an unblockable web site. It's already doing a good job at reliably transfering bits. What we'd like to do next is remove trivial means of blocking it based on network fingerprinting. We're currently using the golang HTTPS library, and at https://trac.torproject.org/projects/tor/wiki/doc/meek#Distinguishability you can see meek's TLS differs from Chromium's in its ciphersuites and extensions. It seems the right thing to do is mimic a browser, and I can think of at least three ways to do that: 1. Try really hard, using NSS or some other library, to look like a particular browser. 2. Run a second browser, apart from Tor Browser, that receives commands from a client PT program and makes the HTTPS requests it is commanded to. 3. Run a browser plugin *inside* Tor Browser, that makes HTTPS requests *directly on the Internet, without going through Tor*. That is, the plugin receives commands from the client PT program, and then bypasses all of Tor Browser's proxy settings in order to send HTTPS requests to the web site fronting the circumvention. It's the third option I want to ask about. The first option puts us on the parrot treadmill. The second has the usability and distribution problems of running two browsers at once. The third is slightly crazy, but more usable and easier to deploy. The third option is definitely what I would do if I were using a browser other than Tor Browser and designing purely for circumvention and not anonymity. Is it even possible to run a plugin that bypasses the proxy settings? (I know a binary plugin like Flash can do it--but does that use the browser's HTTP engine or do they cook up their own HTTP with sockets?) Would Tor Browser's customizations, for example the modified User-Agent string, defeat the purpose of looking like an ordinary browser? Anything else I'm missing? This is just brainstorming; negative answers won't be the end of the project. The first option might not be too bad if we use NSS directly. David Fifield

6 10

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev March 2014