- tor-dev - lists.torproject.org

Fwd: Games Without Frontiers: Investigating Video Games as a Covert Channel
by Rishab Nithyanand 19 Apr '15

19 Apr '15

Hey all, I just thought I'd share and get feedback about some recent work from our team at Stony Brook University. I posted this to the tor-talk list earlier and it was suggested to x-post here, too. Title: Games Without Frontiers: Investigating Video Games as a Covert Channel [ http://arxiv.org/pdf/1503.05904v1.pdf ] Abstract: The Internet has become a critical communication infrastructure for citizens to organize protests and express dissatisfaction with their governments. This fact has not gone unnoticed, with governments clamping down on this medium via censorship, and circumvention researchers working tirelessly to stay one step ahead. In this paper, we explore a promising new avenue for covert channels: using video games as a cover protocol. The popularity of platforms like Steam have given rise to a rich population of video games for use as cover. The common properties of games in the same genre simplify the process of adapting channels to evade detection. We demonstrate the feasibility of this approach using two real time strategy games (including a popular closed-source game). We show how common properties of these games can be used to design a coding scheme to translate data into game commands in a way that is general across games and requires little per-game customizations. We evaluate the security of Castle by quantifying its resilience to a censor-adversary, its similarity to real game traffic, and its ability to avoid common pitfalls in covert channel design. We use our prototype to demonstrate that Castle can provide throughput which is amenable to transfer of textual data (\eg e-mail, short articles, etc.). I thought this was a cool idea, and had a lot of fun exploring it. One of the key changes that Castle brings to the PT landscape is easy extensibility and large space diversity -- i.e., it takes very little skill and developer time to port Castle to any of 100's of existing (and perennially releasing) RTS games, in the event that it is detected and blocked for one game. Please check out the paper and feel free to post questions here, or email them to me. Rishab

3 2

Re: [tor-dev] shipping with fallbackdir sources
by teor 18 Apr '15

18 Apr '15

> Date: Sat, 18 Apr 2015 08:51:35 +0200 > From: Peter Palfrader <weasel(a)torproject.org> > >>> On Fri, 17 Apr 2015, Jacob Appelbaum wrote: >>> >>> On 4/17/15, Ian Goldberg <iang(a)cs.uwaterloo.ca> wrote: >>> Remember that the purpose is to help first-time clients, who have never >>> used the Tor network before, fetch their very first consensus. To do >>> that, they'll need addresses to contact bundled into the binary and/or >>> distro without being able to look at a consensus first. Disabling fallback directories in custom Tor networks (Trac #15642) tor currently doesn't disable the list of fallback directories when the DirAuthorities or Alternate{Bridge,Dir}Authorities options are set. This means that any fallback directories will still be used in test, private and custom Tor networks. This could mix descriptors from the public network in with private Tor network in certain circumstances (at the very least, when the private authorities are unreachable). I suspect this is an undiscovered bug in the fallback directories feature. It hasn't really been an issue until now, as the list of fallback directories has been blank. I am also concerned that this general area of the code lacks unit tests, which it might be wise to include before we effectively activate it for the first time. I've created a git branch with a fix in the trac issue #15642 [0]. I've also included unit tests for the function I've modified as a commit in that branch. But there's currently no coverage for the function that adds fallback directories. (In fact, I mock it in my unit tests, because I need it to do *something* so I know if it has been called or not.) Loading from an Authority-Signed file of Fallback Directories The function which loads fallback directories currently loads from a string array inside the function, so it would need to be modified to load from a signed file. I support the security benefits of signed fallback directories enough to write client code and unit tests for it, but I'm not sure how the code for the authorities would work - is the proposal to sign a section of the consensus, and output it as a separate file? If so, we would either need to backport, and/or wait until a majority of the authorities update to tor versions with the feature. And perhaps a majority of clients as well, controlled by a consensus parameter? (Otherwise, using any entry in the file itself would allow clients to effectively be partitioned from the rest of the network by their behaviour.) While I'm making a list, do we need to modify the existing proposal which describes fallback directories? Is this change proposed for 0.2.7? Or all currently supported releases? 0: https://trac.torproject.org/projects/tor/ticket/15642#comment:8 teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

1 0

shipping with fallbackdir sources
by Peter Palfrader 18 Apr '15

18 Apr '15

Hi, so, Tor has included a feature to fetch the initial consensus from nodes other than the authorities for a while now. We just haven't shipped a list of alternate locations for clients to go to yet. Reasons why we might want to ship tor with a list of additional places where clients can find the consensus is that it makes authority reachability and BW less important. At the last Tor dev meeting we came up with a list of arbitrary requirements that nodes should meet to be included in this list. We want them to have been around and using their current key, address, and port for a while now (120 days), and have been running, a guard, and a v2 directory mirror for most of that time. I have written a script to come up with a list of notes that match our criteria. It's currently at https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates It currently produces https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list Discuss :) -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/

3 7

Release: obfs4proxy-0.0.5
by Yawning Angel 17 Apr '15

17 Apr '15

Hello all, I just tagged obfs4proxy-0.0.5, this time with improvements for both clients and servers. All users are recommended to upgrade. Special thanks to mvdan for various code cleanups. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5… Changes in version 0.0.5 - 2015-04-15: - Go vet/fmt fixes, and misc. code cleanups. Patches by mvdan. - Changed the go.net import path to the new location (golang.org/x/net) - Added limited support for detecting if the parent process crashes. - Support for tor feature #15335 (stdin based termination notification). - Moved the leveled logging wrappers into common/log so they are usable in transport implementations. - Added a DEBUG log level. - Use a bundled SOCKS 5 server instead of goptlib's SocksListener. The big features are: - obfs4proxy now tries really hard to detect if the parent process has crashed, using various system specific hacks (and the new and improved tor assisted mechanism in #15335). This should reduce defunct obfs4proxy processes when tor happens to crash without tearing down the obfs4proxy instance. - Instead of using goptlib's SOCKS4a server, obfs4proxy now includes a SOCKS5 implementation, bringing IPv6 support to clients. Note that running IPv6 bridges has always worked (though dual stack configs are currently somewhat broken due to a tor PT configuration protocol limitation). Notes for packagers: - Like in obfs4proxy-0.0.5, one of the upstream dependency locations has changed. (code.google.com/p/go.net -> golang.org/x/net) As far as I am aware, migrating to the new package immediately is not required though, should be done sooner rather than later due to the impending deprecation of code.google.com. To temporarily continue to build against the old go.net dependency, please revert: aed4b723891db1be34eb866a03c62806b58ac148 - It is *strongly* recommended that packages be built against goptlib-0.4 or newer to work around tor bug #15240. Without this workaround, certain bridges will fail to operate correctly when the ExtORPort is enabled (the Tor side fix is in tor-0.2.6.5-rc and newer). Questions, comments, feedback appreciated, -- Yawning Angel

3 3

Summer of Privacy application, Censorship Analyzer
by Miquel Llobet 17 Apr '15

17 Apr '15

Hey tor-dev, I'm a third year Computer Science student interested in doing the Censorship Analyzer project this summer. I just found out about the Summer of Privacy program so I'll do my best to be on time. I find the project very exciting as it can potentially help the TorProject and its users in a big way, specially if we can receive feedback from the tests. I've done a first read of the Censorship Analyzer paper and I'm currently working on the proposal, I expect to submit by tomorrow. As far as coding goes, I played a bit with OONI (did a scan, turns out I'm clean :-) ). and built it from source. What bugs to you recommend to work on as a start? Ideally I can write a patch before the submission is due to attest my skills. Let me know if you have any suggestion or advice on pursuing this project. Best, Miquel

3 3

Should popularity-hiding be a security property of hidden services?
by George Kadianakis 16 Apr '15

16 Apr '15

Hello, Tor hidden services are meant to primarily provide server anonymity but they also provide various other properties. For example, their addresses are self-authenticated and their connections punch NAT. This post is about another property, which is that Tor does not reveal the popularity of a hidden service by default. That is, you can't easily get the user count of a specific hidden service. This is not that surprising to hidden service operators, since that's also how the normal Internet works. In the normal Internet, someone cannot learn the user count of an IP or website, except if they are the operator or they control DNS or the site publishes analytics. Over the past years, people have suggested various features that would provide us with interesting information and optimizations but would have the side effect of revealing the user count of hidden services (or only of popular hidden services) to the public. Some examples of such popularity-leaking features: - Hidden Services dynamically set their number of Introduction Points depending on their popularity. Basically, they self evaluate their popularity, and use a formula to decide the number of Introduction Points between 3 and 10. For a while, we thought that this formula does not work properly (#4862, #8950), but we recently discovered that it seems to be working in some manner. While an interesting and useful feature on its own, it has the side effect that it leaks how popular your hidden service is. Since a hidden service publishes a descriptor every hour, you can monitor hourly usage patterns of hidden services. Of course, you can't get the exact user count, but you might be able to get rough approximate numbers (we still haven't analyzed the formula enough to know *exactly* how much). - During our recent work on hidden service statistics [0] people have suggested to gather statistics that would get us closer to learn the number of hidden service users [1]. The suggested way to do so is to have HSDirs or introduction points count the total number of introductions or descriptor fetches and publish that number in their extra-info descriptor. Since given a hidden service address you can easily learn its HSDirs or IPs, it should be possible to map those statistics to specific hidden services, which would leak their popularity (more on this later). There might be more examples that I'm missing, but this should be enough to demonstrate the leaks. For the rest of this post, I will be presenting various arguments for and against leaking popularity. Disclaimer: I still am not 100% decided here, but I lean heavily towards the "popularity is private information and we should not reveal it if we can help it" camp, or maybe in the "there needs to be very concrete positive outcomes before even considering leaking popularity". Hence, my arguments will be obviously biased towards the negatives of leaking popularity. I invite someone from the opposite camp to articulate better arguments for why popularity-hiding is something worth sacrificing. == Arguments for leaking popularity and reaping its benefits == Here are a few arguments that people use to shrug off popularity-hiding. I can relate to some of them, but I find the reasoning of some others funny or even dangerous. - "If we don't care about leaking popularity we can get useful statistics" Indeed, we've dismissed various statistics that we could collect because we were afraid that they would leak the popularity of hidden services. If we didn't have this fear, we would have a better idea on how much usage hidden services see, or whether people are conducting DoS attacks on hidden services. - "If we don't care about leaking popularity we can get nice optimizations" As an example, the dynamic IP calculation is one of those optimizations. I'm not aware of other optimizations, but I bet that we can think of a few more if we completely remove popularity-hiding from our threat model. Also, people have claimed that more statistics would reveal more optimizations that we could do. - "Popularity-hiding is just a side-effect of the Tor protocol, and not a stated security goal" People have claimed that popularity-hiding is not a stated security goal of hidden services, or that the name "hidden services" does not imply popularity-hiding in any way. - "There are no realistic attacks that could happen from leaking popularity" People have claimed that popularity is just a curiosity, and nothing bad can come from leaking it. They say that protecting popularity does not offer security against realistic or dangerous attacks. Other people claim that popularity-revealing attack vectors are too noisy and contain too much random data, hence it's hard to get targetted popularity values out of them. They say that it might only be possible for very popular hidden services, or for unlikely edge cases. - "There are probably other ways to reveal popularity. You can't fix them all" That's actually a big fear of mine. That we are nitpicking about 2-3 popularity revealing vectors, while there are hundreds more currently open. See #8742 for example, but I bet there are more vectors that we need to think about. == Arguments for protecting popularity == And here are arguments that make me believe that popularity is something that should be protected. - Popularity attracts attention Anonymity likes uniformity, but popularity attracts attention. There are literally infinite possible use cases where a hidden service wants to be public and still not attract attention. However, since the above argument has not been particularly successful and only attack demonstrations will persuade a true skeptic's mind, here is an attack scenario: Try hard to imagine a dystopian future where authorities are tracking down and hacking activist websites. They just received a big list of hidden services, the result of a messy interrogation, but they are all locked. Their hackers can hack some of them but not all. Not much time before revolution, end of dystopian future and happiness for all humanity. The dictator needs to decide which hidden services to hack to stop the revolution. Which?? With popularity being public , they can get the popularity of the biggest ones and target those first. - Popularity can be used to find patterns in group movements now and in the past. Even though you can't track specific users using popularity, you can still track group of users. Also, these statistics are forever: even if you didn't care about a group of users in the past, but you start caring about them now, you can still look back and see their development over time. Here is an attack scenario: Imagine a community that practices very dangerous urban climbing [2]. Imagine thousands of friends climbing away in happiness from all over the world, Imagine now that this community splinters in other smaller communities, if you monitor their popularity, it will be possible for you to observe the movement of that subculture. As a further point, imagine now that dystopian future comes and very dangerous urban climbing gets outlawed. The police catches an urban climber in New London and gets a list of hidden services from her. They can then check _historically_ how many users those hidden services had. They can basically notice all the trends of the urban climbing scene in the past years. Creepy, no? As you probably well know, anonymity is not a binary option. It's not like you are not either super anonymous, or not. It's more of a fuzzy variable that depends on many things. OPSEC is a big part of anonymity, and it seems to me that popularity has OPSEC consequences. - Statistics noise will get reduced. Attacks only get better. In the statistics we were talking about, each HSDir would reveal the number of descriptor fetches it received over the past day. We know that each HSDir serves about 150 hidden services, which means that the final value in the end will contain the popularity of 150 hidden services in one number. This is expected to be extremely noisy, and I think that's one of the main hopes of people who don't care about popularity hiding. That allows them to claim that popularity will only be leaked for very popular hidden services. While this indeed seems reasonable, my main intuition is that attacks can only get better. Here are some ways that noise can be reduced. I will focus on the HSDir case, but same arguments apply to other suggested statistics like number of introductions per IP. -- It's still early in the hidden services scene, so not many services get lots of traffic. I imagine that many of those 150 hidden services are going to be very inactive, and not provide much noise. -- Hidden services publish hidden service descriptors to 6 HSDirs. This means that every day you will learn 6 noisy values for your target hidden service, not just 1. It's easier to remove noise that way. -- Also, those 5 irrelevant hidden services that provide the noise will publish themselves to 6 HSDirs. Applying the same logic as above, you might be able to learn information about the noise, which makes it easier to remove. In a way, you can put all the statistics measurements in a big system of equations, and start solving it to reduce noise in the equation you are interested in. -- Think of crazy edge cases. Maybe an introduction point is very weak and unlikely to be picked and only got 10 HSes for a day. If one of them is the hidden service you are interested in, there is going to be much fewer noise than usual. -- There might be other techniques for reducing noise, by combining other statistics (like the number of hidden services per HSDir which is already a stat), or by influencing the statistics yourself (like Aaron's attack on the stats aggregation protocol [3]). What I'm trying to say here, is that if you thought that the urban climbing example was ridiculous because such a community cannot be big enough to be visible in noisy statistics, maybe by reducing noise you can actually make it distinguishable. - There are not that amazing benefits from ditching popularity-hiding. To be honest, I have not heard convincing enough arguments that would make me ditch popularity hiding. Some extra statistics or some small optimizations do not seem exciting enough to me. Please try harder. This could be a nice thread to demonstrate all the positive things that could happen if we ditch popularity-hiding. Also, there is a small difference here between the stats and the introduction point formula. The dynamic introduction point formula is something that we could disable by default, but also leave it as a configurable option for people who want to use it. That is, it will then be *the choice of the hidden service operator* whether he cares about popularity being hidden or not. With the statistics that have been proposed, you don't give any choice. You just do it for all hidden services forever. - Principle of least surprise Hidden service operators except that hidden services are at least as secure as the normal Internet plus more. On the normal Internet, popularity is private by default. Having this assumption violated on hidden services, might not be polite. - Popularity-hiding is crucial to maintain the deep sea security model of hidden services As I have mentioned in the past, some people think of the onion land as a very deep ocean. In some places of the ocean, you might be able to see some buoys (some more visible than others). To visit them, you need to wear your goggles and your snokrel, dive in and enter from underwater. This might not seem like a very concrete security model, but in any case popularity is not revealed at any point. The sea is opaque and you can't see the divers entering the hidden services. Anyway this post has grown to immense size, and I was really hoping it would be shorter. On a more practical note, over the next few weeks, we should decide what we want to do with the dynamic introduction point formula and whether we should keep it or not (#4862). My current intuition is that it should be disabled but also kept there as an option for people who want to enable it. In any case, I hope that this thread can stimulate discussion. Also, if you are a hidden service operator I'm curious to hear about whether you believe that popularity hiding is a security property that should be preserved if that's even possible. Cheers! [0]: https://blog.torproject.org/blog/some-statistics-about-onions [1]: https://lists.torproject.org/pipermail/tor-dev/2015-February/008247.html [2]: https://www.youtube.com/watch?v=kpS7vhvkIQM [3]: https://lists.torproject.org/pipermail/tor-dev/2015-March/008404.html

4 3

TOR SoP proposal: extending and improving TOR network anomaly detection
by Kibo Schaffer 16 Apr '15

16 Apr '15

Hi all, I'm applying for TOR Summer of Privacy. I'm curious if there are any developers here who are able and willing to become a mentor for this idea. I want to improve TOR's ability to detect anomalies such as sybil attacks, and make it easy to include other heuristics for other potential attacks. When a potential attack is detected, users and maintainers are notified (as necessary). There has been research and development with this field with TorDoctor, exitmap, and HoneyConnector. However, as far as I am aware, these projects could use some help being solidified and integrated into TOR. Please let me know what you think, if you want to suggest any improvements, and / or if you are a mentor interested in this idea. Cheers, Kibo [1] TorDoctor -- https://gitweb.torproject.org/doctor.git [2] exitmap / HoneyConnector -- http://www.cs.kau.se/philwint/spoiled_onions/

2 2

Tor Summer of Privacy deadline is soon!
by Damian Johnson 16 Apr '15

16 Apr '15

Hi all, just a quick friendly heads up that the deadline is coming up soon. If you've been thinking of making an application then now is the time! Application deadline for students is April 17th (end-of-day everywhere [1]). NO LATE APPLICATIONS WILL BE CONSIDERED. We're sorry about needing to be strict on this, but we have a really tight deadline for making selection decisions. Late applications make the process harder, so the only fair thing is to not allow any exceptions. Cheers! -Damian [1] https://en.wikipedia.org/wiki/Anywhere_on_Earth

1 0

Re: [tor-dev] TSOP proposal
by Alden Page 16 Apr '15

16 Apr '15

Hey Remi, It's great to see someone else interested in adversarial stylometry! I have been working on a project quite similar to your proposal since January as my undergraduate thesis. I am considering applying for TSoP in order to fund the continued development of the project, but I think the mentor issue is a strong indication that we should focus our efforts on something more related to Tor. Since I have made considerable progress implementing the tool you described, perhaps we should instead combine our efforts? Rachel Greenstadt, whose work I am sure you are familiar with, also expressed interest in collaboration when I announced this project in December. You will find that I have implemented many of your proposed features in my project on GitHub. Near-term work involves making the project easier to install and implementing Writeprint feature set extractors. If you manage to get it running (for now, you will have to install dependencies manually), I would love to hear some feedback from you! Until then, see my thesis. Contribute at: www.github.com/pagea/unstyle A preliminary version of my thesis can be found below. I will provide a more permanent URL on GitHub in the future. https://www.scribd.com/doc/261957061/Unstyle-A-Tool-for-Evading-Authorship-… Full disclosure: I am applying to TSoP this year, and I am still strongly considering proposing the continued development of Unstyle, in addition to a few other potential applications. Cheers, Alden Page

1 0

Summer of Privacy applicant, Multi-threading
by Kim Reece 15 Apr '15

15 Apr '15

Hello, I see several folks doing brief intros here so I'll do so as well. Most of my application is in already, just finishing up the patch. I'm a Mathematics undergrad, 3rd year come Fall. I've used multi-threading in coursework and in an internship I did at JPL/NASA. I want to expand the multi-threading in Tor this summer. For my patch I'm working on #3569 (Refactor socks parsing). It won't be a complete implementation of that bug this week, but I aim to complete the first part of it, ie. the refactoring internal to the function to expose the state model clearly in code structure. To that end I have one quick code style question: Is clarity preferred over the (very short) body of a conditional only occurring in one place? I'm encountering at least once instance where the choice is between repeating a (very short) code block, thereby introducing the potential that one section of it may in the future be edited without the other receiving the same edit (even though they're right next to each other), or retaining a gnarly conditional that took a truth table for me to be sure I had the right end of. If code occurring exactly once is a priority, the gnarliness can be repaired with an explanatory comment, but I'd like to know which is preferred. Thanks, -- Kim

1 0