- tor-dev - lists.torproject.org

Version bump of obfsproxy to 0.2.8 in TB breaks FTE
by Kevin P Dyer 28 Apr '14

28 Apr '14

Hi Mike, It looks like [1] broke FTE [2]. Can you hold off on pushing any releases public, until we resolve #11629? George - Can we revert obfsproxy back to 0.2.4, to give me time to sort this out? -Kevin [1] https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/ce30cd… [2] https://trac.torproject.org/projects/tor/ticket/11629

2 2

GetTor Meeting (April 29)
by Sukhbir Singh 28 Apr '14

28 Apr '14

Hi, We will be having our first meeting on revamping GetTor in #tor-dev tomorrow from 20:00 - 20:45 UTC. Israel Leiva is the GSoC student who will be working on improving GetTor over the summer so we are looking for suggestions from the community on how we can improve the bundle distribution. (Sorry for the short notice and duration but everyone's schedule seems to be busy!) -- Sukhbir

1 1

GSoC: Pluggable Transports Combiner
by quinn jarrell 26 Apr '14

26 Apr '14

Hi everyone, My name is Quinn Jarrell and I'm a student University of Illinois at Urbana Champaign. I'm excited to join GSoC and I'll be working on building a pluggable transporter this summer for Google summer of code. The pluggable transports combiner will allow transports to be chained together to form more varieties of transports and make them harder to detect and block. You can read more about it here: [0]. My mentors are Infinity0 and dcf. My IRC name RushingWookie, and you'll often see me lurking in #tor-dev. I'm excited to work for Tor this summer and I can't wait to get started. Quinn Jarrell [0] https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Combi…

2 1

Please help testing a new Onionoo version that uses Gson to format documents
by Karsten Loesing 26 Apr '14

26 Apr '14

Hi everyone, [I'm blind-copying everyone who I know has been working on an Onionoo client in the past. If you received two copies of this email, or if you received this email even though you're not subscribed to tor-dev@, and you don't want to be informed of updates related to Onionoo, please let me know.] Please help testing the Onionoo version running here: http://54.81.197.70:8080/onionoo/ This version uses Google's Gson library to format JSON documents, rather than concatenating strings that happen to represent JSON documents (#11577). While this change doesn't sound very difficult, it required quite a few code changes. This is good, because the new code is much cleaner. I'm just not certain whether I broke things. Please try to point your Onionoo client to the new Onionoo version and see if something breaks. Please also try edge cases and give this Onionoo instance a hard time. Just note that this version only contains a few days of data. Things to try out in particular: - Responses contain less whitespace than before. Please make sure that your client handles the more compact responses correctly. - UTF-8 characters in details documents should still be in escaped form, e.g., \u00F2 for the ò in Filastò in the contact field. Other fields that might contain UTF-8 characters are city_name, as_name, etc. - The fields parameter for details documents required some hacking, so I might have broken it. I'm planning to deploy the new version on yatei in 5--7 days from now. If you find a bug, please either comment on #11577 or open a new ticket, whatever seems more appropriate. Thanks for your help! All the best, Karsten

2 2

How to run a headless second Firefox instance?
by David Fifield 25 Apr '14

25 Apr '14

We talked a while ago about using a browser extension to make HTTPS requests on behalf of a pluggable transport, so that the TLS doesn't stand out as unusual (#11183). I have that working pretty well and you can try it out. Using these bundles, you can run the meek pluggable transport and the TLS layer looks just like Firefox, because it is Firefox. https://trac.torproject.org/projects/tor/ticket/11183#comment:16 https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-5/ How it works: tor starts a wrapper program called meek-client-torbrowser, which starts a second copy of firefox using a separate profile.meek-http-helper. The second profile has some different prefs (https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/blob/861e270c…) and it runs the HTTP helper extension. The extension prevents a second browser window from opening. Once the second firefox starts up, meek-client-torbrowser runs meek-client and sets it up to communicate using the browser helper. What I need some advice on: In order to prevent a browser window from opening in the second instance of firefox, the helper extension opens a modal dialog and never returns. If the dialog is ever closed, the whole browser is shut down. It looks like this (https://gitweb.torproject.org/pluggable-transports/meek.git/blob/d2de8adc06…) try { // Block forever. var prompts = Components.classes["@mozilla.org/embedcomp/prompt-service;1"] .getService(Components.interfaces.nsIPromptService); prompts.confirm(null, "Query", "Get down, get funky?"); } finally { var app = Components.classes["@mozilla.org/toolkit/app-startup;1"] .getService(Components.interfaces.nsIAppStartup); app.quit(app.eForceQuit); } It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog? David Fifield

5 7

Tor Browser Weekly IRC meetings moved to 15:00 UTC Fridays
by Mike Perry 25 Apr '14

25 Apr '14

Due to the EU "Summer Time" changes generating new conflicts for a few people, the Tor Browser team's weekly IRC meeting will now be on Fridays at 15:00 UTC in #tor-dev on irc.oftc.net, starting this Friday, April 25th. For details on our meeting format, see the original post: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

3 2

txtorcon v0.9.2
by meejah 24 Apr '14

24 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce that txtorcon v0.9.2 is now available. This release adds a few minor bug-fixes and a few API enhancements. Full details: * add on_disconnect callback for TorControlProtocol (no more monkey-patching Protocol API) * add age() method to Circuit * add time_created property to Circuit * don't incorrectly listen for NEWDESC events in TorState * add .flags dict to track flags in Circuit, Stream * build_circuit() can now take hex IDs (as well as Router instances) * add unique_name property to Router (returns the hex id, unless Named then return name) * add location property to Router * TorState.close_circuit now takes either a Circuit ID or Circuit instance * TorState.close_stream now takes either a Stream ID or Stream instance * support both GeoIP API versions * more test-coverage * small patch from enriquefynn improving tor binary locating * strip OK lines in TorControlProtocol (https://github.com/meejah/txtorcon/issues/8) * use TERM not KILL when Tor launch times out (https://github.com/meejah/txtorcon/pull/68>) from hellais * Unit-test coverage now at 98% sha256 sums for the distribution files: 93e934f83e3fc6fcf40e76f7c9c28459af04205fb912d384aaacb7ac5269bb8f dist/txtorcon-0.9.2-py2-none-any.whl fe90743cdc453002ad046aa6556b611b4e85b813ff92865769d3d27712c2ca47 dist/txtorcon-0.9.2.tar.gz There are also signatures on github and txtorcon.readthedocs.org You may download from github or the hidden service: https://github.com/meejah/txtorcon/releases/tag/v0.9.2 https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2-… https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2-… https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2.… https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2.… http://timaq4ygg2iegci7.onion/txtorcon-0.9.2.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.9.2.tar.gz.asc Source code: https://github.com/meejah/txtorcon/archive/v0.9.2.tar.gz Thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTWVf5AAoJEMJgKAMSgGmn07kIAKSwjBck76dyN1lWJj0fRl/f BevLpnp+rb+ge5hBAeKfsVTYciDBZeSo8/fE44wTNh5Qj9HEhFopVC4WF61rIFU+ 4IkpnFvfmVEd8Iu1vqQ/hFmP1jrvT8T+nTbaTGkcoCSPI+GyXkbxLqcl0Fncq51M M0OIRphyWA7EK3YoZ2Q1BOEIwsN0pwERYUhU0CGS45L7OZmyw86RXTMBZpBnNXrD 5VjQdpx8fvrV2iCRXi/k/e2Jy/xqs8o0I2+o9M6WrBiGCs5S9YbjsAKzRb7dsaBZ RlRAdKUjyzkquPl4K8E5ocDToB1hIGvqCSp7s11a5rq5T/jUiDMYrjkxIXH1Yg4= =W7+f -----END PGP SIGNATURE-----

1 0

Pluggable transports meeting tomorrow (Time changed!) (16:00 UTC Friday 24th of April 2014)
by George Kadianakis 24 Apr '14

24 Apr '14

Hello friends, just wanted to remind you that the regular biewekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in OFTC. Please note that we *changed* the time from 17:00 to 16:00 UTC. Thanks!

1 0

Q&A for meek pluggable transport tomorrow, 25 April, 18:30 UTC, #tor-dev
by David Fifield 24 Apr '14

24 Apr '14

Tomorrow, April 25, at 18:30 UTC / 11:30 PDT, in #tor-dev IRC, there will be a question-and-answer session on the meek pluggable transport. It will last about 45 minutes. Developers will be present to answer your questions. Background information: https://trac.torproject.org/projects/tor/wiki/doc/meek https://lists.torproject.org/pipermail/tor-dev/2014-April/006718.html https://lists.torproject.org/pipermail/tor-dev/2014-April/006719.html How to get on #tor-dev IRC: https://www.torproject.org/about/contact#irc David Fifield

1 0

Re: [tor-dev] [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
by anonym 23 Apr '14

23 Apr '14

21/04/14 12:27, Nusenu wrote: > Hi, > > the code to blacklist heartbleed affected tor directory authority keys > has been merged about a week ago [1]. > > Do you have an ETA on when you are going to release it (tor and TBB > packages)? As the release manager for the Tails 1.0 release I'm also interested in an ETA for this. Ideally the Tails image intended for the 1.0 release will be built on 2014-04-27 (so this is when we'll truly freeze the version of Tor), and released two days later. We Tails developers would find it sad if its core piece of software becomes out-dated immediately or even just shortly after that. Nick (or any one else in the loop), do you have any idea of timings for the next stable Tor release? Cheers!

2 3

GSoC : Rewrite Tor Weather
by Sreenatha Bhatlapenumarthi 23 Apr '14

23 Apr '14

Hi all, My name is Sreenatha(lucyd on OFTC). I am currently a final year undergraduate student at IIITH, majoring in computer science. I'll be rewriting weather this summer as a part of GSoC 2014. My mentors are meejah and karsten. In a nutshell, the weather rewrite project mostly involves two tasks, shifting the data backend to onionoo and closing the weather-specific tickets that are causing an issue at the moment. Besides these, there is also a plan to make use of a postgres database to store weather's subscription data. After this is accomplished, I'll document and test the new weather to make sure it's clean. Further details of my project proposal can be found at [1]. I'm very excited about working with Tor on this project and am happy to receive any sort of feedback and suggestions. Cheers, Sreenatha [1] - https://sites.google.com/site/sreenathadev/gsoc-2014-weather-rewrite

3 2

GSoC: BridgeDB Twitter Distributor
by Kostas Jakeliunas 22 Apr '14

22 Apr '14

Hi all, I'm excited to be able to spend another summer-of-code together with Tor (how impudent!) :) My name is Kostas (wfn on OFTC), primary mentor is isis and secondary mentor is sysrqb. I'll be working on writing a new BridgeDB Distributor[1]. I've set my primary task to designing and implementing a Twitter-distributor-bot (see proposal[2]): a Twitter bot answers personal (direct) messages, does rate control if needed, and gives bridge lines to users. There should be enough time to at least start on another distributor (right now I'm thinking about an XMPP-based one, as the federated-network-nature allows for some neat censorship circumvention approaches.) But there's also value in implementing a generic/core distributor that could give bridges to third-party distribution systems over a (say) RESTful API. Will see how things go, but core task for now is a twitter-based distributor. For further ideas, discussion, etc., see a separate tor-dev@ thread: https://lists.torproject.org/pipermail/tor-dev/2014-April/006742.html Ideas are very much welcome indeed! [1]: https://www.torproject.org/getinvolved/volunteer.html.en#newBridgedbDistrib… [2]: http://kostas.mkj.lt/gsoc2014/gsoc2014.html -- Kostas. 0x0e5dce45 @ pgp.mit.edu

1 0

GSoC: Orbot and Orfox
by Amogh Pradeep 22 Apr '14

22 Apr '14

Hey everyone, I'm Amogh Pradeep, a student at International Institute of Information Technology, I have been accepted as a GSoC student this year and I am going to work on the android app for tor, Orbot as well as a new browser implementation called Orfox. Orfox is a new idea, the aim is to implement a complete browser based on GeckoView which has been built by Mozilla. This would hopefully replace the current Orweb browser as the default browser that works with Orbot. For more details on my project, and the proposal itself, you can find it at [0]. I'm online on OFTC and freenode under the nick amoghbl1, feel free to contact me anytime. Best, Amogh Pradeep, Developer, Student.

1 0

New BridgeDB Distributor (was: Re: New BridgeDB Distributor (Twitter/SocialDistributor intersections, etc.))
by Kostas Jakeliunas 22 Apr '14

22 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 With isis' and sysrqb's permission, moving the new BridgeDB Distributor (and maybe general bridgedb distributor architecture discussion) thread onto tor-dev@. On 04/15/2014 10:30 PM, Kostas Jakeliunas wrote: > On 03/29/2014 10:08 AM, Matthew Finkel wrote: >> (I look the liberty of making this readable again :)) >> >> On Fri, Mar 28, 2014 at 08:00:17PM +0200, Kostas Jakeliunas >> wrote: >>> isis wrote: >>>> Kostas Jakeliunas transcribed 7.9K bytes: >>>>> Hey isis, >>>>> >>>>> wfn here. [...] >>>>> >>>> >>>> Hi! >>>> >> >> Howdy! >> >> I'm super excited to hear you're interested in working on this! >> [...] >>>>> [...] a couple of questions (more like inconcrete musings) >>>>> [...]: >>>>> >>>>> Would you personally think that incorporating "some" ideas >>>>> from #7520[1] ("Design and implement a social distributor >>>>> for BridgeDB") would be within the scope of a ~three+ month >>>>> project? The way I see it, if a twitter (or, say, xmpp+otr >>>>> as mentioned by you/others on IRC) distributor were to be >>>>> planned, it would either need to >>>>> >>>>> - incorporate some form of churn rate control / Sybil >>>>> attack prevention, via e.g. recaptcha (I see that twitter >>>>> direct (=personal) messages can include images; they'll >>>>> probably be served by one of twitter media CDNs (would need >>>>> to look things up), but it's probably safe to assume that >>>>> as long as twitter itself is not blocked, those CDNs won't >>>>> be, either); >>>> >>>> Yes, this stuff is already built, and wouldn't be too hard >>>> to incorporate. However, as I'm sure you already understand, >>>> there is no Proof of Work system which actually works for >>>> users while keeping adversaries out. >>> >>> For sure, we always have to keep this in mind. Hopefully >>> there's a compromise that kinda-works, and eventually, given >>> some more metrics/diagnostic info intersected with OONI >>> hopefully being able to say which bridges don't work from which >>> countries, it'll be possible to actually carry out tests in a >>> kind-of-scientific/not-blind-guessing way.. >>> >> >> At this point I just assume our adversary will always have more >> resources than us no matter which mechanism we use. More people, >> more compute power/time, more money. At this point I think we >> only have two things that they don't. We have more bridges and >> more love for people. Leveraging this is...not easy, however. :( >> POW is useful in some cases, for example, to prevent an asshole >> from crawling bridgedb so that they can add all bridges to a >> blacklist. When dealing with state-level adversaries I agree with >> isis that they're of little use. >> > > Agree. > >>>>> >>>>> - or take an idea from the social distributor in #7520, >>>>> namely/probably, implement some form of token system. >>>>> >>>> >>>> This is not very doable in 6 weeks. It also, sadly, requires >>>> the DB backend work (which I'll be doing over the next three >>>> months, but might take more time). >>> >>> Aha, understood, yes. So basically, ideally I'd write code that >>> could *later on* be easily extendable in relevant ways. But no >>> tokens for now. >>> >> >> Ideally this sounds like a good idea, however I'm not sure we (or >> at least I) have a good handle on what bridgedb will look like in >> 6-12 months. It's undergoing a lot of change right now. Don't >> interpret this as saying this is a bad idea because the more >> abstract and extensible you make this distributor the more useful >> it will be. I'm just a little worried about writing something for >> the future. Perhaps there's a good way to design and plan for >> this, though. >> > > Yeah, understood. As I understand it, isis is changing some things > in bridgedb (bridgedb.Distributor, etc) right now / these days. > > For now, the idea is to have a thing that works that is more or > less completely decoupled from the bridgedb codebase. If we do this > right, it will hopefully be relatively easy to then integrate it in > a way that will make sense at that point in time (e.g. as part of > bridgedb.Distributor, *or* as a client to a core RESTful > distributor/api/service that gives bridges to other 'third-party' > distributors (see below.)) > >>>>> It might be possible to have some simplistic token system >>>>> with pre-chosen seed nodes, etc. Of course, security and >>>>> privacy implications ahoy - first and foremost, this would >>>>> result in more than zero places/people knowing t he entire >>>>> social graph, unless your and other people's ideas (the >>>>> whole Pandora box of; I should attempt an honest read of >>>>> rBridge, et al.; have only skimmed as of now) re: oblivious >>>>> transfer, etc. were incorporated. Here it becomes quite >>>>> difficult to define short-ish term deliverables of course. >>>>> I know that you did quite a lot of research on the >>>>> private/secure social distributor idea. >>>> >>>> Really, you don't want to get into this stuff. Or do, but >>>> don't do it for GSoC. I've spent the past year painfully >>>> writing proofs to correct the erro rs in that paper, and >>>> discovered some major problems for anonymity in old >>>> "tried-and-true" cryptographic primitives in the process. >>>> >>>> This is a HUGE project. >>> >>> Sounds insanely intense, in both a good and a bad way! It's >>> definitely interesting, but this is a whole other level for >>> sure. Ok. (Btw, interesting re: proofs for crypto/whatever >>> concepts. Intense stuff.) >>> >> >> rBridge is definitely a large project. This is not to say your >> help would not be appreciated [...] so I'm sure you can help, >> however this is much larger than GSoC. >> > > For sure, OK! (and yes, it sounds like an interesting avenue / way > of getting into zero knowledge madness etc etc. Will see how it > goes..) > >>>>> But I wonder if it wouldn't make sense to attempt a >>>>> simplistic token system, as well as (possibly) some >>>>> hopefully-not-too-evil incarnation of recaptcha, to >>>>> >>>>> - have a system that would actually do its job; - have a >>>>> system that would be easily extendible into cryptomadness >>>>> later on / when the time comes; - have a framework for more >>>>> complex social distributors later on. The latter is maybe >>>>> because only doing a naive twitter distributor (via PMs) >>>>> project is not enough, in the sense of gsoc scope (or I'd >>>>> like to attempt something a bit more ambitious anyway. But >>>>> here of course dragon territory starts, with many slippery >>>>> slopes.) This would hopefully be very useful f or later >>>>> work, with hopefully quite a bit of code reuse being >>>>> possible (vs. twitter distributor that would use your >>>>> twisted stuff + additional code which would likely not be >>>>> beneficial for other distributors/projects.) >>>>> Architecturally, this token-based distributor would be a >>>>> generic/parent class, with the particular twitter >>>>> distributor inheriting from it. Hopefully this would all >>>>> result in some clean, reusable code. >>>>> >>>>> Ideally, the token-distributor would work in a (generic) >>>>> way that could be used in IRC, etc etc. I think a >>>>> simplistic version of it would still prove useful (assuming >>>>> we'd actually be OK with taking the responsibility of >>>>> maintaining and knowing the social graph, and so on.) This >>>>> would be very nice indeed. >>>> >>>> I know that you want this, and I know that you want it for >>>> good reasons. Bu t I refuse to have access to something which >>>> might potentially get me shot in s ome countries. >>> >>> Yeah, I see the problem here. Ok. >>> >> >> +1 >> [...] > > Sorry for the kinda-delayed reply! > >>> >>> Cool. >>> >>> So right now I'm thinking just doing a simplistic >>> twitter-direct-message-based bot. I do believe some churn >>> control / semi-working-PoW thing is needed. Reusing (large) >>> parts of bridgedb's recaptcha makes sense to me. >>> >> >> I don't think this is a crazy idea. > > I wrote a simplistic twitter bot that pretends to give bridges to > people who ask: > > https://github.com/wfn/twidibot > > (tweepy (a python module) is used to interact with the twitter > API. Twitter has two main APIs: 'streaming' and the 'RESTful' API. > The streaming API just gives you event data about things that > you're interested in (so e.g. 'someone started following me', > 'someone sent me a message.') The restful twitter api is for > actually doing things (like sending messages) and getting event > info on a per-query basis (we don't need the latter.)) > > As of now, the bot is running under this account: > > https://twitter.com/wfntestacct > > Try following it; it should send you a direct message, to which you > can reply with e.g. > > "get bridges" or "get me some bridges nao!" or "get obfs3 > scramblesuit fte bridges" > > The bridge data returned is of course beyond-bogus (code is really > just a placeholder), but what is I think good is that I wrote the > thing in a way that can be easily extended - the > bridge-getting-process is abstracted away. > > The main bot stuff is at > https://github.com/wfn/twidibot/blob/master/twidibot/twitter_bot.py > > The stub 'bridge-getter' is at > https://github.com/wfn/twidibot/blob/master/twidibot/bridge_getter.py > > (take a look at the comments at the top maybe[3]) > > Basically I wanted to see if there'd be problems with the twitter > api, and so on. I should try to somehow benchmark the thing, to see > if anything breaks (on e.g. twitter's end[4]) when there are many > requests, etc. (the code itself is kind-of-not-ready for that, but > it should be easy to fix this up; but I'm also worried about > twitter limits and that sort of thing - stuff that in the end may > be hard to control on our end; hence the PoC, etc.) > > I also wanted to have some skeleton code that will support future > abstraction/extension (i.e. hopefully it's not an ugly script.) > [3]: the comments (pretty much all there is there) make it sound as if going the way they say we should go is the right way. The comments should probably be interpreted as a flaky proposal/ideas at best! [4]: By "problems on twitter's end" I of course meant twitter possibly rate-limiting the bot, or even blacklisting it somehow due to high direct message load (maybe lots of direct messages => anomalous behaviour, but then again, probably not.) > > >> It also seems like we're combining the email and http distributor >> with this, not that it is bad. > > ..so the whole plan in terms of bridgedb abstraction / > bridge-getting-mechanism abstraction is not clear, I suppose. > > Here's what asn wrote on that google melange project page[2] (as a > comment to the proposal): > > asn April 4, 2014, 11:09 p.m.: >> Don't mind me too much, but it would be great if we could have a >> simple RESTful HTTPS distributor for BridgeDB, before writing >> exotic distributors like Twitter. Such a distributor would expose >> a simple REST API that clients (like tor-launcher etc.) could use >> to fetch CAPTCHAs/bridges. >> >> A RESTful distributor seems easier and it would also give us a >> fair idea of the different methods that a BridgeDB distributor >> needs to implement. It would serve as a basic distributor that >> can be used as a skeleton to build more complicated ones. >> >> just 2 cents > > I then spoke with him briefly on irc. Basically, I'm up for writing > a RESTful bridge api/distributor, too (or focusing on it instead); > but maybe it makes sense to continue with the twitter bot (and have > the bridge-getting-mechanism be abstract enough to be completely > turned over / extended / changed easily, etc.), and to continue > thinking about the RESTful bridge api. Focusing on a twitter bot > for now will probably lead to clearer deliverables and results. But > we can develop things while thinking about related things in > parallel. > > I'm sure isis has some ideas here, too (e.g. how feasible it is to > implement a restful bridge distributor soon.) But I agree that it > would be nice to have a core distributor that could be used by > tor-launcher, and by other distributors (e.g. this twitter bot, as > well as future distributors.) > >> I do wonder if there is a better rate-limiting mechanism than a >> captcha that we can use. I suspect there is something, but it >> won't be much better, in reality. But, also, I wonder if we want >> to use a POW at all. Maybe only rate-limit a handle by time >> period, similar to how we handle emails? I don't know what is >> best. I think this can be decided in the coming months, though. >> > > Yeah, for now I'll probably flesh out a > rate-limiting-by-time-period thingie - simplistic, but this is OK. > There are some nuances, e.g. this would require the twitter bot to > remember every use who was given bridges, at least for a short > while; even if this would not be persisted / would only be in > memory, it's a delicate thing I suppose, security and privacy wise. > etc. > > But yeah, I'm not sure if a captcha PoW scheme is the way to go, > either. We can continue thinking about it, and meanwhile have > something simplistic. > >>> Or would any of you prefer a different kind of distributor? IRC >>> was mentioned (churn control more difficult), as well as >>> XMPP+OTR (the latter would be more difficult to do for sure, >>> lots of things to integrate.) Whatsapp, too. Twitter, of >>> course, sounds the most easy/easily-deliverable. I can try to >>> come up with future goals/tasks would it turn out to be too >>> easy (ha! i'm sure i'm bound to stumble into unforeseen >>> problems..) >>> >> >> I think you should have enough time to complete the twitter >> distibutor and, at least, start working on another one. Twitter >> seems like a good place to start. Some people would like an >> XMPP+OTR distibutor, but that will be a large and time consuming >> project. Maybe a chat protocol that is popular in AsiaPAC is a >> good second choice. >> > > Yeah! Sounds good. Federated-chat-systems (like XMPP)-based > distributor would sure be nice. WhatsApp distributor would surely > be very useful, and would be pretty hard to censor, if only in the > legal-repercussion-sense (lots of collateral damage so to speak.) > Let's think about this. > >>> Basically, if there are other ideas afloat around bridgedb that >>> are doable / can be incorporated into this, let me know (maybe >>> you've been wishing to do something not too difficult but >>> simply do not have time?) >>> >> >> There are a few outstanding tickets that we really should >> fix/implement/do, so maybe look through them and see if any seem >> interesting to you? >> >>> As far as the twitter bot idea is concerned, it's pretty much >>> straightforward, I guess. I can't think of a proper way to >>> subdivide the twitter distributor into further hashrings; i.e. >>> there'd probably need to be one single hashring for twitter, >>> and that's it. Of course the twitter-handlespace is larger >>> than, say, IPv4-space. I assume this is not a problem in and of >>> itself (there's a hashring for IPv6 (though not yet quite >>> functional), as I understand, etc.) But maybe there are some >>> nasty nuances to be found. >>> >> >> We could split the hashring into n partitions and then choose a >> partition based on some property of the handle. I don't know if >> there is an advantage to this, though. Probably not considering >> it would be trivial and cheap to create a new handle that is >> mapped to another partition. Let us know if you think of >> something :) >> > > Haven't yet. :) for now, I think having a normal hashring, and > having a mechanism of giving only very few bridges (that remain the > same, unless new brides inserted in the neighbourhood) makes > sense. > >>>>> Will do some thinking, finally have time now. >>>>> >>>>> [1]: https://trac.torproject.org/projects/tor/ticket/7520 >>>>> >>>>> -- >>>>> >>>>> Kostas / wfn >>>>> >>>>> 0x0e5dce45 @ pgp.mit.edu >>>> >>>> -- =E2=99=A5=E2=92=B6 isis agora lovecruft >> >> As an aside, I'm not usually not this synical. It was a long day >> at work and it made me grumpy. But in any case, I'm really happy >> you decided to look at making one of these! >> >> All the best, Matt >> > > Good stuff. :) (fwiw, nothing of this sounded cynical, at all. > Though everything depends on definitions, ha! > https://en.wikipedia.org/wiki/Cynicism_(philosophy) ) > > [2]: > http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/… > > The TL;DR would be * working on a twitter-bridgedb-bot, PoC is at https://github.com/wfn/twidibot/ * feel free to try and break https://twitter.com/wfntestacct (flood it with messages! follow, un-follow, re-follow, try to crash it if you'd like!) * just found out attaching images to direct messages over API directly is not possible: https://dev.twitter.com/discussions/24116 (whoops! And no updates to API doc elsewhere); still possible to link to images, etc. But kind of sad nevertheless. * will implement a generic rate control mechanism. Will either use requests-per-time-period (this would require the distributor to remember some state about users for a while, which is a somewhat delicate thing), (and/)or text-based challenge-response (which can later on be replaced by something more sophisticated.) * as of now, planning not to stop with a twitter distributor. Would sure be nice to also have an XMPP-based one, too. * RESTful BridgeDB Distributor / bridge API discussion is welcome. Did I miss something, or garble things up? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTVncOAAoJEMCyQlAOXc5FnZwP/2YGPQnd9sXyET+O8sSbEMvA g+6heUOsDK6k5tEEn7g700c2KVEaVREXLOlP68d27h/A0eM7b4nGjSJIhk1pcOIn 30DgaePIkaCPng5k5By1Z4ao79MwF7lEq/OHvN8+3W+Oje3HJzwogJOoYW7tH5Yi 6eqPPrOxNXcJ5zsRbUlzzl0uVFbuPf2JdioIkj3X5coOc6m0h6gKSrsNAV3Nvd6R oFTT7IvDxu8EMm8j+a07JSyZ/VePyKBfW0XMOfi/delU1wk691xd4OHOCua6Q8pQ /otiUXEsMnSMSBmTjc97s6H2S4hvwnET/1eu9zPY0R2PzaK5MBOeKezGOLCGxA3l 2wWWADp5xc3Y0CfT8bjpUhzdCYR1UADUhC7vuCzdL7F81RBksL1Zl/ZtxnCYjSIQ lQXe0x1Xid2rbsgIfaW7oWhcx0muxUbiQI+rLhMFcSRii9XD5YPzhfAg+ATmEn4+ BnVHFGJUeguY8T0OAy3bab/ASTUaN42AXceX7bs2OBOHqeNeGxP/PCjqfnMO4jj2 N5nJheAXpNyPXLUMoX1Vmwz+eQyfxelLZ1BdRwerGPp5zgCMWUT5YvGG/2Yl9WbR WEXIlDQb3PFJesIBCkqOMRs9IZwsCe07onEX8yspPE+RFFUOcsZIjKo3sL6WbP61 6w1qyJh0wWScZoE7NDxY =Tepi -----END PGP SIGNATURE-----

1 0

GSoC: A Framework for Website Fingerprinting Countermeasures
by Marc Juarez 22 Apr '14

22 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, My name is Marc Juarez and I'm a PhD student at KU Leuven [0]. I'm going to work in the GSoC project "A Framework for Website Fingerprinting Countermeasures" [1] that will be mentored by Mike Perry and Yawning Angel. I'm very excited about this project because my research now is on website fingerprinting topics. The main goal of the project is to implement the building blocks for a future padding based website fingerprinting countermeasure [2,3] as a pluggable transport. These days I'll be familiarizing with obfsproxy and twisted and getting things ready to start coding on May 19th. I will try to keep everybody updated and I'm looking forward to any advice and comments. If anybody needs to contact me, this is my main email and my oftc username is mjuarez. Best, - -- marc [0] http://homes.esat.kuleuven.be/~mjuarezm [1] http://homes.esat.kuleuven.be/~mjuarezm/GSoC14Proposal.pdf [2] https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-at… [3] https://trac.torproject.org/projects/tor/ticket/7028 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTVj4UAAoJEGfJ5xfgazlxNC0H/2mBLaaqoxk3oAPcFBqagJDN 2gWU0VA0o3XXzVxAvuB5ikEimNKmCGVimMGhC71shZe3Ot26AzJtD3dqFSNGtucB 5lzZR/tcsHjp2TDChePnQH/iDHNMY+VrdakkM/gjWorqjQHutrqGW+1crhkwscCO nJEcA4kinrQQc4mN/xTNHva6HDFx99e9Qs6N6sbumsdlNO3cew7Ly0NhTs7Jn4Jm U1/JlmnCfNyIArd65Ywcaqsb7ZMnKcu00DT34/1uNYqAbxEP+MQ3yH2IJjDHVgM3 7L1wTCM0OjsWVmVu5boQqsTeneRh0LzfdtBKdmQQJqfsPOgcOjskyALHwcjXt5s= =v9eI -----END PGP SIGNATURE-----

1 0

Tor Cloud - Issues/Maintainer/Next Steps
by Sina Rabbani 21 Apr '14

21 Apr '14

Dear Team, I have created a ticket for Tor Cloud, I think I need access to the following assets: Tor's Amazon EC2 account login, or API access Access to update cloud.torproject.org and git.torproject.org/tor-cloud.git Access to update blog.torproject.org with latest Updated in regards to Tor Cloud Please let me know how to move this ticket forward. All the best, SiNA -- "be the change we wish to see in the world." Gandhi

2 2

Python Only Tor Client?
by Fabio Pietrosanti (naif) 21 Apr '14

21 Apr '14

Hi all, does anyone know of any work to make a Python Only Tor Client, that just enable to expose a Tor Hidden Service? It would be very cool if it would be possible to avoid "Tor binary" as a dependency for Globaleaks, making it pure Python application code. The questions are: - Are there projects that foresee to do something like that? - From a Tor Project perspective, does it make sense? - From a Security perspective, are there strong security implications in doing so? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org

4 3

Re: [tor-dev] Python Only Tor Client?
by Jacob Garber 21 Apr '14

21 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/14, Fabio Pietrosanti (naif) <lists(a)infosecurity.ch> wrote: > Hi all, > > does anyone know of any work to make a Python Only Tor Client, that just > enable to expose a Tor Hidden Service? > > It would be very cool if it would be possible to avoid "Tor binary" as a > dependency for Globaleaks, making it pure Python application code. > > The questions are: > > - Are there projects that foresee to do something like that? > > - From a Tor Project perspective, does it make sense? > > - From a Security perspective, are there strong security implications in > doing so? > I have been considering such a project, though my purpose for pursuing it would be to both learn Python and to come to a better understanding of the internals of Tor. Perhaps not the best circumstances for a solid implementation... For the time being my implementation is just going to be an experiment with trying to speak the Tor protocol, but assuming that I can get some of the basic building-blocks working I'll be pursuing a Tor rewrite in my spare time (I'm currently a student, and as such still sorting out my schedule). I'll probably be in and out of IRC and these mailing lists asking questions every now and again (and trying not to ask stupid ones). - - ajtgarber (0xEFDA75F9) A190 2527 2D58 6A2B 8108 CB66 D57A A16A EFDA 75F9 -----BEGIN PGP SIGNATURE----- Version: n/a iQIcBAEBAgAGBQJTVV/4AAoJEEyLqVBnwH7XGu0P/3e0ZI+y067si2PItq4xWsaq +NLIzEymUjoSEM8iaYkZVumcOofY+yD1vCEGIvUroCvymC0YWFH+FYw5jkiffjRX 6wmc/d25ARtT/wVP59Nrmi+P9ZpD1fMaNaQ68eS3rnIPbZHc/ONsemXnW3g/m49Q zPViKtXNu3/1pmix33yS2SSU8uJIPd9j7NWDV3lxZ9fOlFfv0TocgJgvYdx0gVJC QGXiK6dprGgXhEy4+pzxDroUbKynh0pwd6N5ZiwlCbhcSAeIps87zGPldnasb8cA ZHEcyG8Gvlsoat/kQAVI7EwLYS3HCXiqKnhmoB1hXllDG6pJpYK1FufwGYyvlUZM ds1s0OQymmuftgEFcAbuInBlbqKihwllspMGdoz6SjBj50+iYqG3K/XP5yhyiZBx fk6X4LhAPh+GCClSRPn7ZV6oPDqrc/T3yodcUfGoKAlZiFQkCkX/DZUITr59Sb1g Hy7CKBIUdrzvK0B4XLf9gdVpf/pZCy0CTUikZbnke2ctyEseKkQbiZGLYIC5+ueT VJTGYtlFxZtblz3dh+lfwEI5HAPQRaa/cR6yRJd4yxvIOGlFNNAyn4E4HXuI4K+L VoWaDoFQQButYMlx8LiYt228HGVQkfxPpwX5OWH8u2BJpRYqKblGWpGu2bvkgiyw ZpsBF6B/8v+FTLN0fMk6 =s4ji -----END PGP SIGNATURE-----

2 1

Potentially n00b question about Tor Cloud & Heartbleed
by Peter B 21 Apr '14

21 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 hi all, As I understand, there are two steps to mitigating the Heartbled bug for Tor bridges: 1. Upgrade OpenSSL 2. rm -rf /var/lib/tor/keys/* and restart the tor procses While the bridges on Tor Cloud (and therefore Access' Global Proxy Cloud) are configured to automatically fetch updates, there is no way to complete step 2 with SSH access, correct? If so, is there any plan to deal with instances that were set up with the vulnerable version of OpenSSL, but whoever set up the instance has not or cannot regenerate the keys. - -- Peter Bourgelais Circumvention and Network Interference Technologist Access | accessnow.org | rightscon.org PGP ID: 0x1C16F6D8 Fingerprint: EC9B 18C2 EBF4 07E0 37C6 E306 6592 DE70 1C16 F6D8 Github: https://github.com/pbourgel -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTVUToAAoJEGWS3nAcFvbY15oP/31qpnsLAFZZiuvsQ19jwx6C 74drB1P8zdr8cpAvCVMpmEGRE1hDHTB4iyKQ4rttaAhJu5D5ukP+pGvL+bIL7bTC mzyww37gZE4Fh/ydyaUEQSPw6dBR0pMpKl61/DUKsvF2G/62gW8c5j/+ZXlvBYb8 5tX1ecfWF3LAuBDqrFK0EHtysZ8JfwjRz9aOBR/ZuGM9NKW2UN5iLljxsq7nKIIx YFDKEwPJKPV8t4AsaAxv1Z6ctFqAOSmFObj5Ku9Ifc8vgpSKx9yZpuAttpfaEwYT wf+PHvn1hZNzHb/UZ5ZaIBqP63w+xqTLUEmoDrO9qwSUsi2DhCPUCvKhQ7wzWsnZ 3U+GvmsV3c1JGHCroXii+B2hu04DI0fKxboyFdy+x19PvAMf4UAEIwAG+X0FO9dS pd1F8Zq5ohXItjdAm6ZxGtOL1Q9KHU29G9liYjj/N9NYq7iQLd59CNhoELHulYoO BYBUyTzVwASYIDPbcUZ63z23vCk+ymfX95JTj2J4LK0ZbmJWhe+23ZOIfXiF/v/t 5UBoSIPok336NmsNv7vGMV8O8PuqsEm6/Gv9CCETlUw+wzrSdlu3K0QhLjYagj0C Fl8uEiKzH1LzavdBsSMfDKCGQya4LbvWSnDM2DmHWra3hPG6xJMvnMPxCdqr73dv vGezCcQBb6limTdHW1xH =xqRh -----END PGP SIGNATURE-----

1 1

Starting Tor from Python using Ctypes improving Sandboxing?
by Fabio Pietrosanti (naif) 19 Apr '14

19 Apr '14

Hi, currently starting Tor from an python application using existing frameworks (such as txtorconn) provide limits related to the capabilities of sandboxing the application itself with AppArmor. If you want to start Tor from your own application, then you must enable such application to "execute" an external binary called /usr/bin/tor . I'm wondering if anyone ever tried to start Tor from a Python application using Ctypes, to start the Tor "main()", placing the Tor process into a dedicated Python's application Thread. That way it would be possible to sandbox the Python application using AppArmor without enabling any kind of execve() call. Does anyone ever tried this? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org

1 0

consensus-health.torproject.org
by Michael Wolf 19 Apr '14

19 Apr '14

I think I can make some improvements to the consensus-health page (mostly removing redundant formatting code in the HTML), but I can't seem to find the git repo for the project listed at https://gitweb.torproject.org/ Could someone point me in the right direction? I another pertinent question would be: is anyone using any scripts that scrape this page, which might be broken if things are changed? An example of a change could be: since the flags in the "Consensus" column seem to always be blue, remove all the <font color="blue"> tags, (and closing tags) in the consensus column, and replace them with one class per <td> in that column. I estimate that this change alone would save about 575KiB in the uncompressed HTML. That's about 10% of the document's uncompressed size, without even using any CSS3 trickery. -- Mike Wolf

2 1

Please try 3.5.4-meek-1 bundles (covert HTTPS pluggable transport)
by David Fifield 18 Apr '14

18 Apr '14

A while back I wrote about a pluggable transport called meek that routes your traffic through a third-party web service in a way that should be difficult to block. There are now experimental bundles featuring this transport, ready for somewhat wider testing. Please try: https://people.torproject.org/~dcf/pt-bundle/3.5.4-meek-1/ The files are signed with my key 0xC11F6276 from: https://www.torproject.org/docs/signing-keys https://www.bamsoftware.com/david/david.asc You don't have to do anything in the configuration. Just click "Connect". What you'll see, if you look at your network traffic, is a lot of HTTPS requests to www.google.com. (And no connections to any Tor bridge, nor anything speaking the Tor protocol.) Behind the scenes, Google is passing the requests on to our web app, which then forwards them to a Tor bridge. More on how the whole system works is at https://trac.torproject.org/projects/tor/wiki/doc/meek. Another thing to know is that starting the browser will run a second, headless instance of Firefox. The second browser is used as a tool for making HTTPS requests. It's the same Firefox binary used by Tor Browser (so it doesn't increase the size of the bundles), but it has a special configuration and an extension that allows it to access the network directly. When you're using meek, this browser extension is in fact the only thing that touches the network, but you never interact with it directly--it only takes orders from the client transport plugin. We do it this way so that the HTTPS requests look like they come from a browser, and are not fingerprintable as coming from some custom SSL program. The second browser should be completely invisible to you--except on OS X, where it creates a second dock icon (this is bug #11429). These bundles are experimental and you shouldn't use them to replace your main browser just yet. We're most interested in hearing about what didn't work for you or what was surprising. I'll write another post about code review and other things that need to happen before you'll see meek in a mainline bundle. David Fifield

1 1

[Flashproxy] Some sites filtering users?
by Griffin Boyce 18 Apr '14

18 Apr '14

Hey all, Got a report from a friend* who noticed that twitch.tv stops letting him watch broadcasts while flashproxy is in an active state. He uses Cupcake, which shows flashproxy's status in the icon bar, and he only has an issue when the cupcake icon has a mustache. Has anyone noticed similar behavior when using flashproxy? ~Griffin * who is a hacker

1 0

Combining obfsproxy+scramblesuit with OpenVPN
by irregulator＠riseup.net 17 Apr '14

17 Apr '14

Hello people, I'm investigating how may we combine the traffic obfuscation provided by obfsproxy+scramblesuit with OpenVPN instead of Tor. I completely understand how this combination does not provide anonymity, but nevertheless I think it will be of some use. In the recent past there have been some interest in this combination [1], [2], [3], mainly cause of VPN traffic blocking in various countries or networks. OpenVPN supports only Socks5 proxy but current obsfproxy's version doesn't have a Socks5 listener, see ticket #9221 [4]. Luckily yawning provided a patch some days ago [5], and I decided to test it. According to patch's comments, it implements a Socks5 proxy with authentication as in RFC 1928/RFC 1929. This authentication is gonna serve as a means to pass parameters to the pluggable transport, please correct me on this one. Firstly, does this patch and generally obfsproxy development takes in consideration other clients except for Tor, e.g. OpenVPN or OpenSSH ? I think it would be very nice to have a way to combine OpenVPN with Scramblesuit as stated in the latter's paper. But then I'll understand if that's not a priority for obfsproxy's developers. So, while testing OpenVPN with obfsproxy and the latest patch, the vpn client enters the authentication phase. Do the credentials depend on the pluggable transport in use by the obfsproxy? If so, what credentials should the vpn or the ssh socks client provide when talking with scramblesuit? Will vpn client have to provide the session ticket or other pre-shared secret through socks authentication? Thanks in advance for any answers. Alex [1] http://community.openvpn.net/openvpn/wiki/TrafficObfuscation [2] http://www.dlshad.net/?p=135 [3] https://www.void.gr/kargig/blog/2012/10/05/bypassing-censorship-devices-by-… [4] https://trac.torproject.org/projects/tor/ticket/9221 [5] https://trac.torproject.org/projects/tor/attachment/ticket/9221/0001-Use-SO…

7 12

Named pipes with tor
by carlo von lynX 17 Apr '14

17 Apr '14

Hiya. Been around the tor dev community a bit, but today is my first day on the legendary tor-dev mailing list. I am asking if it makes sense to apply a minor patch to Tor source, but first, the use case: tor is very adamant at scrubbing the addresses that are being connected to in the logs, but I have the opposite wish case were I would like to have a terminal show me the addresses my tor is connecting to in real-time. Could be that the "arm" app would be able to do that without taking up the screen space that vidalia takes, but for some irrelevant reasons I am not using that. What I do is "Log [app]debug file /dev/shm/tor-log.txt", then run "tail -f /dev/shm/tor-log.txt | grep asked" to extract the "Client asked for <hostname>:<port>" lines, so I even get to see DNS requests independently from actual virtual circuits. I also have "SafeLogging" set appropriately. Needless to say, the RAM disk fills up quickly, so the usefulness is limited. This is a case screaming for unix named pipes as follows: mkfifo /dev/tor-log grep asked /dev/tor-log But tor refuses to write to such a FIFO pipe because it can't seek to the end of it. Couldn't open file for 'Log /dev/tor-log': Illegal seek ./or/config.c calls ./common/log.c's add_file_log which calls ./common/compat.c's tor_fd_seekend to make sure the stuff is appended at the end of a log. In the case of a FIFO pipe this returns an ESPIPE code which currently makes tor throw up. In my understanding it should be safe to ignore it, instead. We should expect the user to know what she is doing if she puts a pipe where the log should be. Or am I missing something? There is also a similar case of calling tor_fd_seekend in ./common/util.c which suggests there may be other use cases of mkfifo which are currently impeded by this. So the question is, would it be okay to catch ESPIPE in all cases, thus having it ignored in tor_fd_seekend, or just catch it in add_file_log? Or is there a reason to impede the use of unix named pipes under all circumstances? Best sockets from Berlin, CvL. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet

3 5