December 2014 - tor-dev - lists.torproject.org

Internet-wide scanning for bridges
by Vlad Tsyrklevich 31 Dec '14

31 Dec '14

Hello, while taking a looking at TorCloud I it used static OR and obfs2+obfs3 ports making them trivial to discover by scanning EC2's IP address space. This led me to consider the more general attack of internet-wide scanning to discover Tor bridges. Most Tor relays run their ORPorts on port 443 or 9001 so I began investigating there. I began by looking at Project Sonar's port 443 SSL certificate database looking for certificates matching the tor certificate pattern. In talking with Eric … [View More]Wustrow about ZMap, I discovered that he and the other ZMap authors had already published about this attack in their original paper. Eric mentioned that in his discussion with Roger that the response to the attack was going to be the soon-to-be-deployed obfuscated transports which were intended to be run on random high ports; however, the eventual roll out of obfsproxy did not change the fact that bridge's ORPorts continue to be publicly accessible. While I was analyzing Internet-wide survey-data for port 443 and 9001 (helpfully provided by Project Sonar/H D Moore) I found the Onionoo data set. I was able to quantify the impact of the attack using the Onionoo data and verify it using the ZMap scans. There are 4267 bridges, of them 1819 serve their ORPort on port 443 and 383 serve on port 9001. That's 52% of tor bridges. There are 1926 pluggable-transports enabled bridges, 316 with ORPort 443 and 33 with ORPort 9001. That's 18% of Tor bridges. 203 (64%) of PT-enabled bridges with ORPort 443 were TorCloud. I was able to approximately verify these figures using the Internet-wide scans. By grabbing bridge's certificates and calculating their hashed fingerprint I realized I was also discovering a fair amount of private bridges not included in the Onionoo data set. The results aren't too awful, just under 20% of PT-enabled bridges are affected. It's unclear to me if the low number of PT-enabled bridges (and corresponding high number of vulnerable non-PT-enabled bridges) is a historical artifact or a consequence of out-of-date documentation like https://www.torproject.org/docs/bridges.html.en not setting up pluggable transports. Eliminating the ORPort entirely for PT-enabled bridges seems like the ultimate solution to this attack, but the implications of such a change are unclear to me. Another change to mitigate this issue is changing the behavior of ports specified as 'auto' and then changing defaults and documentation to use auto by default. Currently specifying 'auto' in your torrc lets the OS decide the port; however, if tor were to generate a random port on first use that it continued to use across restarts it would it possible to use this for ORPorts and pluggable transports by default (as opposed to the current situation where for bridges you want ORPort auto but constant PT ports and a constant ORPort for relays which is confusing.) I've attached a patch to warn bridge operators running with ORPort set to 443 or 9001 as a stop-gap measure. - Vladislav [View Less]

8 12

stem on windows 7
by Tony Willingham 31 Dec '14

31 Dec '14

Any suggestions on how to deal with stem on Windows 7 getting stuck at: [notice] Bootstrapped 45%: Asking for relay descriptors. Occasionally it will make it to: [notice] Bootstrapped 50%: Asking for relay descriptors. If I run Vidalia in client mode only, it works fine. I see in the documentation it says: The timeout argument does not work on Windows, and relies on the global state of the signal module. I have no idea what the "global state of the signal module" means. Python 2.7 Thanks Tony

3 3

Torsocks compile errors
by grarpamp 30 Dec '14

30 Dec '14

On gcc 4.2.1 freebsd 8 (thus not really expecting a fix)... commit ab81544478eb9a0db821fd33684cc2f6aac88c7c syscall.c:213: warning: implicit declaration of function 'handle_mmap' syscall.c:283: warning: cast from pointer to integer of different size ../../src/lib/.libs/libtorsocks.so: undefined reference to `handle_mmap' *** Error code 1

1 0

Hidden service policies
by Mike Hearn 30 Dec '14

30 Dec '14

Hello, As we know, hidden services can be useful for all kinds of legitimate things (Pond's usage is particularly interesting), however they do also sometimes get used by botnets and other problematic things. Tor provides exit policies to let exit relay operators restrict traffic they consider to be unwanted or abusive. In this way a kind of international group consensus emerges about what is and is not acceptable usage of Tor. For instance, SMTP out is widely restricted. Has there been any … [View More]

6 11

ScrambleSuit's replay protection incomplete
by Philipp Winter 28 Dec '14

28 Dec '14

In short: The implementation of ScrambleSuit's replay protection is incomplete which means that an active adversary can circumvent it. All the credit for this discovery goes to Lasse Øverlier. ScrambleSuit uses Uniform Diffie-Hellman as one of its authentication mechanisms. To defend against replay attacks, a sever caches the HMAC of a client's authentication message. The attack works as follows. In the first step, an active adversary (e.g., a censor trying to detect ScrambleSuit) observes … [View More]

1 0

Damian's Status Report - December 2014
by Damian Johnson 27 Dec '14

27 Dec '14

Hi all! Tis that time of year coal appears in all my sox so guess it's time for a status report. This month I set arm aside to polish improvements that accumulated in the Stem 1.3 release... https://blog.torproject.org/blog/stem-release-13 There were a lot of small tweaks, but the highlights for this month were... -------------------------------------------------------------------------------- Hidden Service Tutorial --------------------------------------------------------------------------… [View More]

1 0

Drop or merge the projects wiki?
by Damian Johnson 24 Dec '14

24 Dec '14

Hi all. Quick question, any objections to us dropping the projects wiki? https://trac.torproject.org/projects/tor/wiki/org/projects It's years out of date and redundant with the volunteer page, which I continue to update on occasion... https://www.torproject.org/getinvolved/volunteer.html.en#Projects I'm asking here in case there's any strong objections, or folks want us to keep something from it. Cheers! -Damian

3 5

Stem Release 1.3
by Damian Johnson 22 Dec '14

22 Dec '14

Greetings wonderful people of the world! After months down in the engine room I'm delighted to announce the 1.3.0 release of Stem. For those who aren't familiar with it, Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to arm and Vidalia. https://stem.torproject.org/ So what's new in this release? ------------------------------------------------------------------------------ Better Hidden … [View More]

1 0

Thinking of raising bandwidth stats interval from 15 minutes to 4 hours
by Nick Mathewson 22 Dec '14

22 Dec '14

See https://trac.torproject.org/projects/tor/ticket/13988 . Karsten suggests that I should announce this on tor-dev before merging/deploying it, and he's probably right. Will this break anything you know about? -- Nick

2 1

Tor dev IRC meetings for the rest of this month
by Nick Mathewson 22 Dec '14

22 Dec '14

Hi, all! The regular tor patch workshop will happen on schedule, at 1800 UTC on the #tor-dev IRC channel on Tuesday the 23nd and the Tuesday 29th. I'm also planning to do a Tor dev meeting at the regular time of 1330 UTC on Wednesday the 24th and Wednesday the 31st, though of course it's likely that some folks won't make it at one of those times. (I strongly encourage taking Christmas Eve or New Years eve off, if that's your kind of thing.) Best wishes & happy holidays, -- Nick

1 0