- tor-dev - lists.torproject.org

Re: [tor-dev] [tor-talk] Mobile Anonymity and Circumvention seems not working
by Nathan Freitas 28 Mar '13

28 Mar '13

Does the "check.torproject.org" site return a connected message in the default browser? chandra mohan <rkchandramohan(a)gmail.com> wrote: >Hi, > > I tried Trasparent proying of Orbot as mentioned >https://guardianproject.info/apps/orbot/->OTHER >*APPS* and observed all web (traffic built-in Browser, Gmail, YouTube, >Maps and any other application >that uses standard web traffic)and all DNS requests from my Android >mobile >are not following Tor >encryprtion. > > Observed with wireshark and above mentioned application traffics >are having DNS request and DNS >response packets and followed by large number of HTTP packets. > > My Mobile is running on Android 2.2 Kernel which is already root >and I also gave super user >permission for Tor installation. > > what is possibe issue here? > >Regards, >Chandramohan >_______________________________________________ >tor-talk mailing list >tor-talk(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Tor Exit Images
by Griffin Boyce 24 Mar '13

24 Mar '13

Hey all, After talking to Wendy Seltzer, I decided to bring this up on the list. I frequently talk to people who would like to run an exit node, but who aren't as good a sysadmin as they'd like to be. It would be great if there were server images that could be fairly easily installed and then configured. All of these people so far have had the means to spend $150ish a month on the required hosting, they just felt that getting it running was a stumbling block. Thoughts? ~Griffin -- "What do you think Indians are supposed to look like? What's the real difference between an eagle feather fan and a pink necktie? Not much." ~Sherman Alexie PGP Key etc: https://www.noisebridge.net/wiki/User:Fontaine

3 5

Basics of Developing #newbie
by Ashish Patil 24 Mar '13

24 Mar '13

Hello! I am new to Tor-Dev & am looking forward to contributing as much as I can. My question is, after resolving any bug in my local copy of the source code, what are the next steps? Basically, do I have to build again? Run tests? And other similar tasks in what order? Hope you got my question. I went through this in the wiki & FAQs but did not find anything detailed. (Hopefully I'll write one when I know it all) --Ashish

1 0

[Stegotorus] Stegotorus stuff
by vmonmoonshine＠gmail.com 24 Mar '13

24 Mar '13

Hello TorDev, Here, I'm reporting my recent progress on Stegotorus as well as answering some questions from past. During past month, I mainly worked in "retransmit = false" mode trying to restore reliable browsing. I have resolved quite few bugs. Some of them where due to incomplete implementation of "retransmit = false" mode after implementing retransmission. But the major one seems to be the flush_interval implementation: if server had transmitted data to the client, the client opens a new connection, "probably" in near future, to retrieve more data. The probability follows geometric distribution to simulate user browsing behavior. This is OK most of the time. But when you transmit 1000s of packets, inevitably it happens that it samples delays such 40-60 seconds. Unfortunately, Firefox isn't patient enough to wait so long to receive the rest of the data and judge the connection as dead. I changed this now that if it real data came from the server on previous connection, the client opens a new connection 100msec which I know isn't the point but I wanted to restore reliability. The better way might be to schedule opening few connections at a time (instead of one). In this way it is very improbable that all of them sample unacceptable delays. I am going to debug retransmission in the next step. Now few questions, that I was putting off partialy cause I was tired talking and I wanted to do something practical before talking more: From: Roger Dingledine <arma(a)mit.edu> on Sun, 13 Jan 2013 13:04:23 -0500: > 3) What's the overhead of putting your Tor traffic through each of the > steg modules? Now the chopper is measuring the efficiency of the steg modules based on the following measure for each circuit: (no of byte transmitted from upstream)/(no of bytes transmitted downstream ino order to transmit upstream bytes) The summary of the results measured using speedtest.net: |-------------+----------+---------+------+------| | | Mb/s | Mb/s | Efficiency | |-------------+----------+---------+------+------| | Steg module | Download | Upload | S->C | C->S | |-------------+----------+---------+------+------| | Direct | 19.52 | 2.08 | 1 | 1 | | nosteg | 12.98 | 2.26(!) | 0.98 | 0.98 | | http | 0.28 | 0.31 | 0.03 | 0.07 | | http_apache | 1.43 | 0.47 | 0.65 | 0.52 | |-------------+----------+---------+------+------| (!) The faster upload of nosteg than the direct connection with Stegotorus is persistent and I can't figure out why. it might be a bug with speedtest.net algorithm or a their weird notion of speed. If you are downloading, the server->client efficiency is like this: |-------------+-----------------| | Steg module | S->C Efficiency | |-------------+-----------------| | Direct | 1 | | nosteg | 0.98 | | http | 0.10 | | http_apache | 0.65 | |-------------+-----------------| The efficiency of course varies depending on the cover texts. These are measured for http module using the fake cover generated by zack and for http_apcahe using random javascripts that I have downloaded plus the pdf files I had on my computer. The advantage of http_apache over http steg module is due to http_apache always chooses the most efficient cover possible verses http module which randomly chooses 10 candidates and then chooses the best one among them. The http_apach approach, however, isn't security-wise plausible. The best solution seems to be hybrid of the two with user having a say how efficient/secure wants it to be. With all my cat and mouse with curl, it still manages to steal data from libevent and I lose 1 in 100 packets or so. In presence of retransmission this is not a big deal but I have to solve it in more fundamental way. From: George Kadianakis <desnacked(a)riseup.net> on Wed, 30 Jan 2013 14:09:35 +0200: > The code monkey inside me doesn't see any code-quality-related tickets > in that URL. stegotorus boasts 12k LoC of C++ and some of that code > was written in haste. You can divide the ST code into three major parts. Network, chopper and the steg modules. The network is basically, obfsproxy. For the chopper, beside Zack's obsession with overloading functions with the same name by changing type/no of parameters, I think the rest is a pretty good standard code and well commented (I suspect it is very similar to a typical TCP implementation). It lacks is a flow chart that explain what exactly happens when data is received or sent. The ugly code are the steg modules, (partially because it is in C rather than C++), but then the steg modules are not innate part of Stegtorus and are meant to be re-implemented by interested party. Having said that, Zack has mentioned that hardening the code is number 1 priority. Just because he mentioned it later, I haven't included it in the track list yet. > Looking at this from a deployment point of view, > I feel much more relaxed and easygoing with deploying programs written > in a high-level language (like Flashproxy or pyobfsproxy) than with > deploying an unaudited C++ program with many bad code moments. I suspect that python inefficiency will break Stegotorus completely. Now when I run Stegotorus it eats all CPU time. I know this is partially due to heavy logging and partially because I compile it with zero optimization and full debug but I can only imagine how it would look like if it was written in python. There are lots of exact timing there in scope of msec. These are not important when you are running nosteg module which is basically obfsproxy with variable packet size. But when you turn to simulating http with multi-connections and constant negotiation of chopper with steg modules, I doubt if python is an option. Beside, the steg algorithms can get quite complicated. > I think that a trac ticket with a bit of research on how painful would > be to write a deployable <high-level language>-port of stegotorus > would be a good idea. I know that Zack is also interested in exploring > this avenue. I haven't looked into pyobfsproxy, but translating the chopper into python over pyobfsproxy doesn't seems to be an impossible task (you are looking at around 3000 LoC). But then you still need some steg module to get something more than pyobfsproxy (if we close our eyes on the preformance doubts I raised). Maybe, having a cython/c interface to steg module be a middle way compromise. Wow I talk too much! I'll spare everybody for now. Vmon

1 0

Does anyone need python 2.5 support in stem?
by Damian Johnson 22 Mar '13

22 Mar '13

Hi all. Will anyone be sad if I drop python 2.5 support from stem (just supporting 2.6 and higher, including the 3.x series)? If all goes well stem will be having its first release this next weekend and my thinking is this... * Python itself considers python 2.5 to be obsolete, having dropped docs for everything below 2.6. * Every OS I can think of except maybe CentOS has at least 2.6, and more likely 2.7. * I have a dozen dirty hacks throughout the codebase just for 2.5 compatability and I'd love to get rid of them. I'm presently working on a bug that needs the io module which was introduced in 2.6, so I'll need another gross hack for 2.5 support after this too... :( * Testing with 2.5 is a pita for me, so in general I don't (only when a 2.5 bug is reported or prior to a release). * I've never heard of someone actually using stem with python 2.5, so maintaining backward compatability this far back is likely a waste of time. Cheers! -Damian

2 1

Stem Tutorials
by Damian Johnson 19 Mar '13

19 Mar '13

Hi all. Stem is having its initial release later this month, and in anticipation of it I've been expanding its tutorials... https://stem.torproject.org/tutorial.html Are there any rough spots in these tutorials? Other categories that we should cover? Suggestions welcome! -Damian

3 3

Proposal: Capturing Traffic Statistics from Exit Relays
by Zack Weinberg 18 Mar '13

18 Mar '13

[This draft proposal is also available at git.torproject.org:users/zwol/torspec.git/proposals/ideas/xxx-exit-statistics.txt.] Filename: xxx-exit-statistics.txt Title: Capturing Traffic Statistics from Exit Relays Author: Zack Weinberg Created: 04-Feb-2013 Status: Draft 1. Motivation We propose to collect additional aggregate traffic information from exit nodes which will be of use to researchers, similar to how the project already collects statistics about its user population. We also propose to bring existing entry and exit statistics under the same umbrella so that anonymity protection can be applied in a principled fashion to the entire data set. There is some prior discussion in tickets #6002 and #6003. Exit nodes currently collect statistics on the destination TCP ports of exiting traffic, but this is insufficient information for research; in particular, there have been repeated requests for information about destination hosts. Individual researchers have instrumented exit nodes on an ad-hoc basis (e.g. [1]) but the project has historically been skeptical about both the value and the safety of doing so (e.g. [2] warns of running afoul of wiretapping statutes; I understand that the [1] paper was met with severe criticism, but I can't find that right now). A principled, network-wide policy and mechanism for collecting exit metrics can satisfy the demand for data for research purposes while protecting our users and minimizing additional legal risk to exit node operators. 2. Design At each exit node, we propose to measure the number of exiting TCP connections and total bytes transferred in each direction, per day, categorized three different ways: * TCP port * "Public suffix" + 1 domain component of destination (example.com, example.co.uk) * Country of IP address of destination * possibly: ASN of destination and ASN of exit (this may reveal potential traffic-correlation attackers that would not be visible any other way, but may also be too fine-grained to be safe). These are sufficiently coarse-grained that we believe they can be safely measured without damaging the network's anonymity guarantees; see below for further measures that will be taken to preserve anonymity. At the same time, they will enable interesting analyses of what the network is used _for_, in much the same way that the existing entry-side metrics enable analysis of _who_ uses the network. At the same time, we propose to rationalize entry-side data collection, which currently relies on directory queries rather than actual traffic to actual entry nodes. This will improve accuracy and will also allow us to apply an anonymity-protection algorithm consistently to the entire data set available from the Metrics server. Entry nodes (including bridges) should record entering TCP connections and traffic volume, per day, categorized by: * Country of IP address of traffic source * ASN of IP address of traffic source, and ASN of entry node (subject to same caveat as above) * "I am a bridge" flag (I think this is a superset of the information currently collected via directory queries. If I am mistaken, please let me know.) All collected data should be passed through a differential-privacy sanitization algorithm before it leaves the Tor process's memory, and should then be uploaded to a central server (probably via a write-only hidden service API) which applies a second layer of sanitization. See below for further discussion. 3. Security implications Any collection of information about the operation of the Tor network requires careful analysis to ensure that the anonymity of its users is preserved. In this case, we are contemplating adding to what is publicly available about what the network is used _for_, and we must ensure that this does not lead to a correlation attack that would reveal _who_ did a particular thing. For instance, suppose the adversary knows that _someone_ posted a "sensitive" document on a particular site on a particular date. They also have reason to suspect that the poster hails from a particular country. If our published metrics reveal that only one person used Tor to access that site on that date, and/or that only one person from that country made use of Tor on that date, the adversary's case against their suspect has now gotten considerably stronger. The theoretical framework that deals with this class of exposure is called _differential privacy_. It rests on two observations. First, it is impossible to guarantee that _no one's_ privacy will be compromised via the release of statistics -- consider the somewhat contrived but still evocative case where the adversary already knows that Alice is 6cm shorter than the average citizen of Ruritania; publication of the Ruritanian average height reveals Alice's actual height. Note that Alice _does not_ have to be included in the average for this to work! But the adversary had to know something about Alice already. This leads to the second observation, which is that we _can_ make a reasonable privacy guarantee by changing the model. Instead of trying to protect everyone _whether or not_ they are in the database, we guarantee that, with high probability, the _released statistics_ would not be changed by the inclusion or removal of any one individual from the underlying data set. (This can be generalized to groups of N individuals, although of course the statistics get less and less accurate as N goes up.) Differential privacy prevents the example scenario described above: the adversary would only learn a _range_ of possible values for 'how many people visited site X today via Tor' and would therefore not be able to draw new conclusions about their suspect. The basic technique of differential privacy is to add "noise" to the aggregate statistics before publishing them. There are a wide variety of "mechanisms" for doing so, of which the most basic is simply to add "independent samples from a Laplace distribution" to each statistic. Research in this area focuses on finding mechanisms that minimize the amount of noise required to provide a given level of privacy (according to a security parameter, 'epsilon' as usual). [3] is a good overview of the field and [4] proposes a particular algorithm that seems well-suited for the data set we're looking at here. We must also consider the security of the reporting process. The Metrics server is already trusted, and applying "noise" there will allow us to minimize the overall amount of noise applied for the same level of differential privacy. However, if this is the only place noise is applied, a malicious node operator could capture the 'raw' statistics by reconfiguring their node to report to a server that doesn't sanitize (but perhaps forwards the report to the real server, avoiding suspicion). If each node applies some level of noise before the statistics ever leave the Tor process's memory, this class of attack is much harder, although not impossible (by modifying code or extracting raw statistics from process memory with a debugger). There is at least one proposal [5] for distributed sanitization of a data set. It is Byzantine fault-tolerant and therefore _may_ be overkill for our purposes ... but we're talking about malicious node operators here, so maybe it isn't! 4. Specification TBD 5. Compatibility should be moot 6. Implementation TBD 7. Performance and Scalability minor overhead at each exit (and entry); additional load on Metrics; if reporting is via hidden service, additional load on the network 8. References [1] "Shining Light in Dark Places: Understanding the Tor Network". McCoy, Bauer, Grunwald, Kohno, Sicker. PETS 2008. http://freehaven.net/anonbib/cache/mccoy-pet2008.pdf [2] https://www.torproject.org/eff/tor-legal-faq.html.en [3] "Differential Privacy for Statistics: What we Know and What we Want to Learn". Dwork and Smith. Journal of Privacy and Confidentiality, 2009. http://repository.cmu.edu/jpc/vol1/iss2/2/ [4] "Optimizing [Linear/Histogram] Counting Queries under Differential Privacy". Li, Hay, Rastogi, Miklau, McGregor. Principles of Database Systems, 2010. http://arxiv.org/abs/0912.4742 [5] "Our data, ourselves: Privacy via distributed noise generation". Dwork, Kenthapadi, McSherry, Mironov, Naor. EUROCRYPT 2006. http://www.truststc.org/pubs/101/ourDataOurselves.pdf

2 2

Obfs Links on dist are Suddenly Gone
by Nima 15 Mar '13

15 Mar '13

Hi, I've largely distributed mirror links to pyobfsproxy specially for Windows in Iran. Like this: http://torproject.ph3x.at/dist/torbrowser/tor-flashproxy-pyobfsproxy-browse… Simply because this is the only thing that works. But suddenly they're all gone!!! Is this on purpose or it's just an accident? People are asking for new links. what should we do now? :/ -- Nima 0x1C92A77B "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

4 4

Interested in contributing to Tor-Dev through GSoC
by Ashish Patil 10 Mar '13

10 Mar '13

Hello! I am a newbie & very eager to contribute to Tor development. I have been using tor since a year and a half & I have been looking around the website & the source codes since past month. The upcoming GSoC has provided a very nice opportunity for me contribute to whatever extent I can. I have interest towards Stem & Obfsproxy due to their applications & would like some beginner's guidance for the same. Also, I would appreciate if anyone could provide me some online references that would help me understand networking better (in order to understand the source code fully, also is that completely necessary?) PS - I am very well acquainted in Python & have also contributed to it's development but only in Documentation aspect, hence have good knowledge of revision control, building, etc. Thanks! -Ashish Patil

3 6

Interested in contributing to tor through GSoC
by Anirudh Vemula 09 Mar '13

09 Mar '13

Hi, I use tor everyday in my college as we have a http proxy which blocks specific sites. It has been a huge help for me and I would like to improve it by contributing to it by implementing new ways and resolving bugs. I would like to do this year's GSoC with the tor organisation and I felt it would be better for me if i get acquainted with the source code well beforehand. I need suggestions on how to start going about understanding the source code. I would love if there are bugs and mini-projects that a beginner could resolve and improve my understanding of the source code. Thanks Anirudh V Anirudh Vemula | Junior Undergraduate | Computer Science & Engineering | vvanirudh.blog.com | Alumni Secretary Hostel 2 | IIT Bombay

2 1