- tor-dev - lists.torproject.org

test
by enfn 26 Oct '13

26 Oct '13

Test

1 0

Browser extension identification/fingerprinting mitigation?
by Griffin Boyce 26 Oct '13

26 Oct '13

Hi all, I'm looking at possibly replacing the images used by Cupcake with inline SVG XML, to reduce the possibility of fingerprinting/identifying Cupcake users who use Chrome [1]. One of the more talked-about methods of identifying a user's browser extensions is to look for images used by the extension (in Chrome at least), so this seems to make some amount of sense. [2] Does anyone have any thoughts on this? ~Griffin [1] https://chrome.google.com/webstore/detail/cupcake/dajjbehmbnbppjkcnpdkaniap… [2] http://blog.kotowicz.net/2012/02/intro-to-chrome-addons-hacking.html -- "Cypherpunks write code not flame wars." --Jurre van Bergen #Foucault / PGP: 0xAE792C97 / OTR: saint(a)jabber.ccc.de My posts are my own, not my employer's.

1 0

Re: [tor-dev] Incorporating your torsearch changes into Onionoo
by Kostas Jakeliunas 25 Oct '13

25 Oct '13

On Fri, Oct 11, 2013 at 12:00 PM, Karsten Loesing <karsten(a)torproject.org>wrote: > Hi Kostas, > > should we move this thread to tor-dev@? > Hi Karsten! sure. >From our earlier conversation about your GSoC project: > > In particular, we should discuss how to integrate your project into > > Onionoo. I could imagine that we: > > > > - create a database on the Onionoo machine; > > - run your database importer cronjob right after the current Onionoo > > cronjob; > > - make your code produce statuses documents and store them on disk, > > similar to details/weights/bandwidth documents; > > - let the ResourceServlet use your database to return the > > fingerprints to return documents for; and > > - extend the ResourceServlet to support the new statuses documents. > > > > Maybe I'm overlooking something and you have a better plan? In any > > case, we should take the path that implies writing as little code as > > possible to integrate your code in Onionoo. > > Let me know what you think! > Sounds good. Responding to particular points: > - create a database on the Onionoo machine; > - run your database importer cronjob right after the current Onionoo > cronjob; These should be no problem and make perfect sense. It's always best to use raw SQL table creation routines to make sure the database looks exactly like the one on the dev machine I guess (cf. using SQLAlchemy abstractions to do that (I did that before)). Current SQL script to do that is at [1]. I'll look over it. For example, I'd (still) like to generate some plots showing the chances of two fingerprints having the same substring (this is for the intermediate fingerprint table.) (One axis would be substring length, another would be the possibility in (portions of) %.) As of now, we still use substr(fingerprint, 0, 12), and it is reflected in the schema. Overall though, no particular snags here. > - make your code produce statuses documents and store them on disk, > similar to details/weights/bandwidth documents; Right, so if we are planning to support all V3 network statuses for all fingerprints, how are we to store all the status documents? The idea is to preprocess and serve static JSON documents, correct (as in the current Onionoo)? (cf. the idea of simply caching documents: if we serve a particular status document, it gets cached, and depending on the query parameters (date range restriction, e.g.) it may be set not to expire at all.) Or should we try and actually store all the statuses (the condensed status document version [2], of course)? > - let the ResourceServlet use your database to return the > fingerprints to return documents for; and > - extend the ResourceServlet to support the new statuses documents. Sounds good. I assume you are very busy with other things as well, so ideally maybe you had in mind that I could try and do the Java part? :) Though, since you are much more familiar with (your own) code, you could probably do it faster than me. Not sure. Any particular technical issues/nuances here (re: ResourceServlet)? cheerio Kostas. [1]: https://github.com/wfn/torsearch/blob/master/db/db_create.sql [2]: https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md#network-st… (e.g. http://ts.mkj.lt:5555/statuses?lookup=9695DFC35FFEB861329B9F1AB04C46397020C… )

2 2

Guard-security projects extracted from Roger's blog post
by George Kadianakis 25 Oct '13

25 Oct '13

Hey Nick, I made a pad with some of the tasks that Roger mentioned in his recent blog post [0]. The pad can be found here: https://pad.riseup.net/p/BQl2W58RLurU_guard It's probably not an exhaustive list and needs more work. Unfortunately I won't have time to work on it during the weekend so I'll post it here in case you find it useful. Cheers! [0]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa…

1 0

Re: [tor-dev] [tor-assistants] Finding a maintainer for Weather
by Damian Johnson 23 Oct '13

23 Oct '13

For those on tor-dev@, this is a thread where Karsten and I have been talking about the future of Tor Weather. Present thoughts are to do one of the following... a. Attempt to tap the community to find a maintainer (the service has been unmaintained for years). b. Hire a developer from odesk to address its present issues. Karsten and I aren't especially thrilled about this idea since it would mean continuing to have an unmaintained service linger on. c. Replace the functionality Weather provides with something else (that's most of what our recent discussion has been about). d. Simply deprecate and later shut down the service. >>> 3. We redesign Weather based on stem. >> >> As mentioned earlier this is already done to the extent that a patch >> exists. Weather's use of TorCtl was pretty simple so it was easy to >> map to stem, making some general improvements to the codebase in the >> process. If we opt for any plan involving the continuation of Weather >> than I'd like to see us do this since it's both easy, and will let >> Weather move off a deprecated dependency. We can then shift the >> service to Onionoo or rewrite it afterwards. > > There's a patch for this? Sounds like a new Weather maintainer should > apply this patch as their first action. (However, I'm not sure if we > should apply it without having a maintainer, because if it breaks, who's > going to pick up the pieces? Unless you'd want to do that?) Yup, a patch but untested (I didn't invest time into starting up a new Weather instance). So we definitely do need a maintainer before applying it. >>> 5. (Even smarter ideas go here) >> >> What about my earlier suggestion? I'd like to replace weather with a >> new torrc parameter, say... >> >> SendNotifications me(a)some_address.com >> >> ... which is then included in the extrainfo descriptors. DocTor (or a >> new Weather if we really don't want to merge services) could then send >> notifications when a relay that previously set this goes down, or has >> reached a point of deserving a t-shirt. The only trouble with this is >> that it would expose real addresses in descriptor data (and hence, >> possibly spam). >> >> Maybe there's something smart we can do to overcome this issue? >> Providing relay operators with a method for including real contact >> information would be helpful (as mentioned with the upgrade scenario >> earlier in the thread). > > But we already have ContactInfo lines. What's the difference between > the two? I'd find this rather confusing as a relay operator. Differences are... * This option would be an opt-in for receiving notifications about their relay. * It resides in extrainfo descriptors rather than server descriptors (not sure if that'll lessen spam, but ContactInfo's definitely in the wrong spot). * We've already trained users to throw garbage information into the ContactInfo. Since SendNotifications would be for automated systems like DocTor we could clearly state that it requires un-munged addresses, lest it doesn't work (and hence is pointless to set). This said, without a solution to the spam issue I don't think this is a good idea. I'm hoping others on this list will have some ideas around this since a solution for the spam problem is the only thing standing in our way for having a good replacement for Weather. > Also, I dislike the fact that we're adding a config option to tor that > is mostly used by the Weather service. What if we want to discontinue > the Weather service? The config option will be around for another two > years after that, but it won't do anything, which will make people think > the tor program is broken. Actually, DocTor rather than Weather - I want to shut Weather down. In theory this is a more general field for 'hey, automated services may send me notices regarding my relay', maybe also with 'here's tags for the notices I want'. Anyway, food for thought - an opt-in flag and email address is really most of what Weather provides us. > Also also, should this discussion happen on tor-dev@? :) Perfectly fine with me - added. Cheers! -Damian

3 4

Attentive Otter: Usability issues with existing OTR clients
by Derek Moss 23 Oct '13

23 Oct '13

>As you point out, you get a "Unverified/Verified" when using OTR. Verifying >fingerprints of anonymous chat is practically impossible -- every side >channel I can think of (telephone, meeting in person, email - ha) either >leaks the act of contacting, isn't practical or convenient, or requires >some kind of Internet reputation. I'd bet that most OTR users don't verify >fingerprints. >TOFU is a must, along with a dialogue that explains in simple terms what is >going on, with a way to dismiss the dialogue (e.g. by correctly answering a >security question). >Perhaps replacing "Unverified" with "In use for: x days" ? Changing fingerprints seems like a big problem, because it's reasonable for users to verify them when they first add a user to their contacts (via phone or whatever) but they're not going to keep doing that if the contact keeps changing their fingerprint and will probably just click OK when warned that the fingerprint has changed. I have no idea if this exposes a risk from a MITM attack or some other compromise but it would seem like it might. Certainly it should be easy to bring up a contact's fingerprint for verifying, by right-clicking on their name for example and not buried away somewhere in the preferences. > > We should have per-message icons for > > both sent and received messages that indicate encryption status for that > > message in the chat scrollback window. >If the Attentive Otter client is going to be "Force OTR", then you'd >only need a special flag for "received insecurely" (much as pidgin-otr >has). With Jitsi, I think it's not clear enough whether chats are secured or not and there seems to be some bugs that cause it send unsecured messages despite the "Force OTR" setting. I've had problems with it sending unencrypted messages when starting a conversation from one end but not in the reverse direction. Obviously this needs to be prevented and I like the idea of just not sending any text until a secure connection has been established. For Attentive Otter, hopefully the "Force OTR" can be made rock-solid and so it should only need to indicate unsecured incoming message (or maybe even block those but perhaps there's not much benefit from doing so). >Is "skull and crossbones" an easily understandable icon for "message >received insecurely"? It would certainly need a tooltip hint, or >something like that. I think a padlock icon is much more understandable for most users. > > 7. Logging should be off by default when OTR is on. >Agree (as with pidgin-otr 4.x). >> I guess people like logging for some reason, and I'll admit that pidgins >>"History" mode really enables asynchronous chat. Rather than require you >> *turn off* OTR to get this feature, an alternative would be to require a >> passphrase and automatically expunge encrypted logs after a configurable >> period of time. And, unlike other clients, perhaps telling the conversation >> counterparty that logging is enabled (e.g. the opposite of gchat "OTR" >> notifications ) at the start of the session would provide informed consent. >Unfortunately, such counterparty notifications cannot be relied on, as >you could have hacked your client. On the issue of logging, I'd suggest it would be best to have no logging features at all. That way, they can't be enabled accidentally or deliberately and other than the other user running a hacked version (either on purpose or unknown to them) both users can have more confidence that their chat isn't being logged. Of course, this won't prevent the other user cutting and pasting the conversation to manually log it but that comes down to trusting them, whereas logging features can cause a security breach without either party intending to do so. This was a big issue for a number of users on the Jitsi mailing list and we were rather disappointed that the devs seemed more focused on the convenience some users get from being able to refer back to old conversations than the security from not having conversations logged. Although the devs didn't really accept that logging could be a security problem and felt that Jitsi's purpose was to secure chats in transit and nothing else. If you must have logging, at least encrypt the logs so that they're not sitting around in plaintext for anyone to grab. Despite the issues I've mentioned with Jitsi, I wonder if it might not be an alternative starting point to InstantBird? I see that it's been decided you don't want to use Pidgin/libpurple but wonder if other alternatives, like Jitsi which I understand is free to be forked, have been considered, where much of the required OTR work might already have been done?

1 0

Re: [tor-dev] First draft of Requirements and Software Design for a Better Tor Performance Measurement Tool
by Karsten Loesing 23 Oct '13

23 Oct '13

[Adding tor-dev@ back to the Cc.] On 10/8/13 7:25 PM, Robert Annessi wrote: > On Friday 06 September 2013 15:58:53 Karsten Loesing wrote: >> I just finished a first draft of a tech report sketching out the >> requirements and a software design for a new Torperf implementation. > >> Feedback in the form of patches to the LaTeX sources is most preferred, >> though email replies are of course fine, too. > > I would add a "Circuit build success/failure rate" to the tests. Recent events > (botnet) clearly showed that such data is needed but missing. Absolutely. The plan is to log stream and circuit information on the tor processes used by Torperf. See section 2.2.1 "Results format" for details: """ Results may include data which appear not immediately relevant to measuring Tor performance, but which may be useful for related purposes. For example, Torperf should include data about circuit failures in its results, even though these circuits may not have been used in actual requests.% \footnote{\url{https://trac.torproject.org/projects/tor/ticket/8662}} """ Also see the appendix that specifies data formats for stream and circuit information. If you have suggestions for making this clearer, can you send me a patch to the LaTeX sources? https://gitweb.torproject.org/user/karsten/tech-reports.git/blob/refs/heads… All the best, Karsten

1 0

Torperf implementation considerations (was: Torperf)
by Kevin Butler 23 Oct '13

23 Oct '13

[cc tor-dev] On 16 September 2013 09:47, Karsten Loesing <karsten(a)torproject.org> wrote: > Hmm, I don't think the HTTP client/server part is the right interface to > write another client and server and call it Torperf compatible. The > Torperf data API would be a better interface for that: people could > write their own experiments and provide data that is Torperf compatible, > or they could use the data that Torperf provides and analyze or > visualize it in a better way. But writing only half of an experiment, > client or server, wouldn't be of much use. > > I thought bit more about this and I don't fully agree (but you've nailed it that the data is the core api). I've come to the conclusion that I think it makes sense for TorPerf to do much of the heavy lifting and the core server aspects, but I think the experiments should be decoupled in such a way as to allow for flexible client implementations. Below are a bunch of semi related musings on how to get to this: Of course as many experiments will just be doing simple http requests, the experiments will really just be wrapper scripts around a bundled default client implementation which would be similar to the one in your perfd branch. Specifically, to aid in this, I'd propose something like the folder structure below: https://etherpad.mozilla.org/iqrgueVFd6 [Why a set of directories? There's not a solid reason other than it forces unique names and gives good opportunity to isolate experiment specific data. If an experiment has no specific data files it should be alright to just have the config file instead of a directory. A directory structure also mimics the idea of a restful web service as mentioned in the pdf, i.e. the user could easily know to go to http:/.../results/myexperiment/ to see results filtered for that single experiment. Either way, it's a minor detail, I just feel it's easier for a user.] A good use of the specific experiment data could be for static files, where anything in an experiments '/public' folder would be served by the webserver while that experiment is running. If wanting to ensure nothing gets proxy cached, the experiment could be responsible for generating random data files for each run. (This is a clear separation of server vs experiment implementation concern.) Another idea could be custom experiment views(js probably) that would transform the experiment results when viewed on the web dashboard. The experiments should not be responsible for determining details such as socks port or control port, the TorPerf service should deal with load balancing a bunch of tor instances on different ports and just tell an experiment 'Do your stuff using this sock port, this public ip:port, etc...' via environment variables. (The config could ask that certain aspects of the torrc file are setup specifically but managing ports and stuff is just asking for user error unless there's some experiment that requires it.) The config should minimally have an execution rate and a command. The command could be to just execute the bundled TorPerf client implementation with boring parameters e.g. just fetch facebook.com and record the normal timings that the default implementation tracks. A more interesting config's command could be the alexa_top_100 where it's just a basic script/makefile that fetches a new alexa list if the one in the local folder is older than X days and then for each site in the list it runs the TorPerf client instance. The TorPerf service instance should be able to run experiments by just executing the commands and recording whatever is written to stdout and stderr. After the command exits, if it's non zero then the stderr output is treated as error messages while if it's zero then it's treated as info messages. The stdout data should be treated as TorPerf results and it's an error if it's not well formed. If it's not well formed it should be captured in the results file for debug purposes. An example of informational output might be that the alexa_top_100 experiment updated it's list before this result set. [On the web interface it should be clear which results sets contained errors or information] Once the experiment finishes, the service should postprocess the results from the experiment and replace any fingerprinted entries (This needs to be well defined) with the server side timing information for that specific fingerprint. Then the server should store the results file in a timestamped file (timestamped probably by experiment start time) and update it's database(if there is one). The experiments should be able to specify their required tor version in their config, but it should accept placeholder values such as the default 'latest', 'latest-stable' or even 'latest(3)' which would run the experiment for all 3 of the latest tor versions. I think the ability to check the performance of the same experiment over multiple Tor versions could be interesting, especially to determine if any one build has caused anomalies in performance. I would expect very few experiments to run across multiple versions though. Additionally, something that could be neat, but it's not clearly in the requirements, should TorPerf be responsible for notifying the user when there are new clients available to run as latest? Would it be useful to be able to specify that some experiments should be run on 'master' or a gitref and that it would be pulled between runs? That's probably not practical. Apologies for the length and lack of order! Kevin

4 11

Help wanted: write user manuals on digital signatures and open proxies
by Runa A. Sandvik 22 Oct '13

22 Oct '13

Hi everyone, I am currently working on a rewrite of the short user manual [1] (relevant tickets are: #5571, #5811, #8003, #8779). The next version of the manual will (hopefully) be easier to read and translate, and it will also contain an updated list of frequently asked questions. I hope to have a version out for review next week. The old version of the manual contains pieces about verifying digital signatures and using open proxies. A number of people have suggested that we either move these pieces into an advanced section of the manual, or that we take them out completely. I intend to take these pieces out completely and suggest that we write separate manuals for them. The new manuals should be easy to read and translate, small enough to send via email, and be in a format which does not get blocked by most email providers (e.g. xhtml). If you would like to help with these two manuals, please take a look at Trac tickets #9883 and #9884. [1]: https://www.torproject.org/dist/manual/short-user-manual_en.xhtml Thanks, -- Runa A. Sandvik

2 2

[Otter/Buoyant] Tor documentation list
by Colin C. 21 Oct '13

21 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 At the last Buoyant Otter meeting, it was determined that we required a list of the documentation that we currently provide. Runa and I have put together a list, and it is now available on the wiki[1]. If anyone notices something missing, please feel free to edit the wiki. [1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous… - -- - -Phoul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSZZuQAAoJEJ01Zvx7KO7YTy8QAJTfQnUVqSkqWxh40jmh9I3I qgdx8x8tqugS0kLOD3tDRTU6YvyHjdDYpbcKw87AAVh4cT8vhy0pzEmq2WpTSebA Z19eyytf511TsPC/Ke/yL7Ub0Xqs66j+niIcmcFY3cZIykcpH1lLa5OQ3BR51FYn yo5fznbra9fwv9/TbE4r2sZdBu8dH2Vs9pJtzmsMcgZcPVbZlUTE102qRh31Fsib pU9fepc6SaKQOCDXkFbaIoydVqlr8sovlfmUNqZ3qiups2KBxJHrYGZBLGqkVqAi 12ux8C6WTpuCRIlMbcAyjJjuSiEesQDS7dekXsc35YC5Q8TPWFTXuDDY4XIsZ5wR LGWOgNENl//DOb1KR6S7EX9YI/WcqG9o/mgKKuDapNIQZesP9rfGudZsl8IdhZer QRO7GtfwMqRJEflhm5W3BMVZbQStIbpSyzmbBK+kou6b968oi9xDhGD5yT1Co07W HwV2lwTdGhDCBgY3peymBKul8v4yCKex4IP1tgF//dZrD6CsahtMreyzq8G5Syf3 S4ojrv5AXXqR6X1F8qRYCPkHgAYeKPQ8RZx+ynb+T8P65bZ7yUz51s4pO4Vvhh7H FjdgJk4esBg+BBic8ju3ATfPizaaaf1xHeCdts/qLdYjCNeEamQ6CYPnbw+Onqcs lg3qrQ/S2M88Ba0jr5PO =CfQj -----END PGP SIGNATURE-----

1 0

Sponsor F: update; next meeting [in *two weeks*]
by Tom Lowenthal 21 Oct '13

21 Oct '13

Today, at 1100 Pacific, we spent more than 90 minutes discussing [Sponsor F][]. Here's the summary. **READ THIS**: The next Sponsor F meeting will be held in a mere two weeks on **2013-10-14, at 1100h Pacific in #tor-dev**. This is a schedule change: from now on, the meetings will be every two weeks. It's possible that we may have to increase this to every week, depending on how fast we work, and how long meetings are taking. If you should be at these meetings but cannot make Mondays at 1100h Pacific, please contact me, and I'll start the process of finding a better time or times. If you are individually in the `cc` field of this message, it's because I think that there's something which I think you need to do for Sponsor F before Halloween. You should also come to the next Sponsor F meeting. If you can't make the meeting, or don't think this work applies to you, you should get back to me ASAP so we can fix it. Is something else missing, wrong, or messed up? I'd like to know. [Sponsor F]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year3 * * * * * Core Phase 2 Deliverables ========================= UDP Transport [#10] ------------- **[On Track: Minimal]** Karsten will work with Rob to complete the Shadow simulation of this work, then write up a full report on this, probably with Stephen's help. We expect both tasks to be complete by Halloween. This likely represents a minimal outcome for this deliverable. Combine obfuscation (obfsproxy) with address-diversity (flashproxy) [#11] ------------------------------------------------------------------- **[On Track: Minimal]** The work of integrating obfsproxy with flashproxy is done. George will include this in the next released version of the pluggable transports browser bundle. George will also write a report on this work. Ximin and David will help. By Halloween, the report will be complete and the bundles will either be released or well on their way through testing. This likely represents some combination of minimal or intended outcomes for this deliverable. Bridge Metrics [#12] -------------- **[Done: Intended]** Our reporting code has been merged into master. It will ride the trains or flow downstream or whatever your favorite code development cycle imagery is, and show up in future releases. As it goes through alpha, beta, and release, gets picked up and adopted by more operators, we'll get more comprehensive sample coverage, and better data. This likely represents an ideal outcome for this deliverable. N23 Performance Work [#13] -------------------- **[On Track: Alternate]** Roger doesn't think that N23 is as good as we thought it was, so he's going to write a report on the various performance improvements we've implemented lately; the performance work which we though about, but decided not to implement, and why; and a wishlist of future performance work and research. He'll have this done by Halloween. This likely represents an alternate outcome for this deliverable. Improved Scheduling [#14] ------------------- **[On Track: Intended]** Nick will work with Roger and Andrea to implement an improved scheduler (possibly based on picking randomly, weighted by bandwidth), and -- if possible -- also to refactor `cmux`. If time permits, Nick will also attempt to simulate this using Shadow , probably with Karsten's help. Finally, Nick will produce a full report before Halloween. This likely represents an intended outcome for this deliverable. Alternate `Fast` Flag Allocation [#15] -------------------------------- **[At Risk]** The person who we initially expected to do this work does not seem to be available to do it. We need to find an alternate plan to execute this deliverable. If you think you can do it, please read [ticket #1854][#1854] and get in touch. [#1854]: https://trac.torproject.org/projects/tor/ticket/1854 VoIP Support [#16] ------------ **[On Track: alternate]** Our implementation strategy for this was high-latency send-an-mp3-over-XMPP using Gibberbot/Chatsecure, or a similar system. The internal milestone was to have a release candidate available today. Sadly, Nathan (who is on point for this) wasn't on the call. Fortunately, Nathan [blogged][guardian-1] about Chatsecure's `12.4.0-beta4` ten days ago, and a tantalizingly-named [`ChatSecure-v12.4.2-release.apk`][chatsecure-release] ([sig][chatsecure-release-sig]) is available in the Guardian Project [release directory][guardian-releases]. The outlook seems good, but Tom will follow up with Nathan as soon as possible to verify these outrageous claims. Nathan, if you're reading this, could you get in touch (email, IRC, XMPP, whatever). Thanks! [guardian-1]: https://guardianproject.info/2013/09/20/gibberbots-chatsecure-makeover-almo… [chatsecure-release]: https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk [chatsecure-release-sig]: https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk.… [guardian-releases]: https://guardianproject.info/releases/ Extended Phase 2 Deliverables ============================= VoIP Support [#17] ------------ **[Limbo: Intended]** Here we're talking about getting a general VoIP client (Mumble) to work over Tor. This discussed in [ticket #5699][#5699], and [instructions][torify-mumble] for using Mumble over Tor are on the wiki. We didn't get an update during the meeting, so if you're working on this, get in touch, eh? [#5699]: https://trac.torproject.org/projects/tor/ticket/5699 [torify-mumble]: https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble Simulating Tor [#18] -------------- **[On Track: Intended]** Linus will finish Shadow improvements as needed, and write a full report on his Shadow work. That'll all be done by Halloween. This probably represents the intended outcome of this deliverable. Relays as Bridges [#19] ----------------- **[Done: Minimal]** Using a public relay as a bridge works. Defiance [#20, #21] -------- **[At Risk]** We cannot work on these without open Defiance code. Throttling Classifiers [#22] ---------------------- **[On Track]** Adaptive throttling seems to come with unpleasant anonymity tradeoffs, so we're not doing that right now. It looks like static throttling will work really quite well, without these tradeoffs. Torbrowser Optimistic Data [#23] -------------------------- **[Done: Ideal]** It's in your TBB *right now*. FAQ === **Q**: Why do you keep talking about Halloween? **A**: We're currently in Phase Two of Year 3 of the Sponsor F project. That phase ends on October 31st 2013, so we should try to finish everything as best we can before then. Also: if we don't finish, at midnight (local time) each person who has an outstanding deliverable will be besieged by a seemingly-endless horde of zombies. Others may be besieged too: the zombie report is hazy.

4 6

Re: [tor-dev] Sponsor F: update; next meeting [in *two weeks*]
by matt＠pagan.io 21 Oct '13

21 Oct '13

I wanted to give another update as to the status of patching Mumble to support native Tor proxification. Mumble uses its own connection protocol to make external connections, a protocol which is defined in a 30-page pdf file which comprises most of Mumble's documentation (the comments in the code are quite sparse). Most of the methods laid out in mumble-protocol.pdf are defined in the file mumble.pro (or mumble.proto in the github version). I suspect the method named 'connect' of being a culprit in the DNS leaks. Unfortunately 'connect' is not defined in mumble.pro like the rest of the connection protocol. Right now I am searching for where this method is defined. I have visited #mumble on freenode, but no one there was able to offer any insight. I even wrote a simple tool to help me search for this method, but 'connect' is used in over 30 of mumble's *.cpp files (and none of the *.h files).

1 0

I2P's Syndie (wrt HS publishing)
by George Kadianakis 21 Oct '13

21 Oct '13

Hey people, there seems to be some movement on improving HS publishing (making it easier and more user friendly) lately. I just wanted to point you to a project by I2P called Syndie which looks relevant to your interests: http://syndie.i2p2.de/ (FWIW, I haven't checked its code or its architecture yet.)

2 1

Attentive Otter: Usability issues with existing OTR clients
by Mike Perry 18 Oct '13

18 Oct '13

Here's the major usability pain points I've run in to with various OTR clients over the years. Feel free to chime in with any additional issues you've noticed. 1. The multiple client problem: If you have two devices online simultaneously under the same account, they will fight and endlessly renegotiate. This issue may be specific to OTRv2 only. Arlo pointed out that this change in OTRv3 may solve a lot of these problems: "Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions." -- https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html We should be sure we use these features properly, and make sure the js-ctypes wrappers are updated to support the new libotr v3 APIs with these instance tags. The current js-ctypes wrapper may still be v2 only. If for some reason these tags in v3 can only be used if both parties support v3, perhaps we can add some additional code to track OTR state using XMPP resource/device info and tell the OTR lib underneath that different XMPP resources are actually different users, so that at least XMPP accounts won't have this problem. 2. Better TOFU support: We should track only one OTR key for a given XMPP resource/device ID. Some people I communicate with are constantly rotating OTR keys for security and other reasons. However, this doesn't help me any: I have accumulated about 50 keys of unknown age and usage pattern in my OTR fingerprint list for them, and I have no idea which ones have been changed due to compromise, device loss, or simply due to reinstall. Worse, I have no idea which keys should correspond to which XMPP resources/devices. If a user changes the key for a given XMPP resource ID, we should expire the previous key and loudly alert the user of the fact that the resource's key has changed, and ask them if they want to replace the old key with the new key. We should not simply accumulate more keys by default, especially for the same XMPP resource/device, and especially not for unverified keys. At the same time, we should allow a different OTR key for each unique XMPP resource ID, and perhaps allow non-XMPP keys to accumulate at user option. 3. "Unreadable encrypted message" errors should be visible only to advanced users/in the error console, and the client should transparently renegotiate and resend. It looks like OTR has an ERROR_START_AKE flag for this, but for some reason, some states of OTR in Pidgin still cause me to get and send these errors and miss messages though, usually if one client has crashed or restarted without properly ending the conversation. We should try extra hard to force key re-negotiation in these cases. We probably also want an auto-responder after the renegotiation that informs the other party that N messages were missed (for clients that don't support OTR's built-in notifications). 4. OTR shouldn't get stuck in the "Finished" state when you end a conversation. I've noticed in the past that OTR seemed to refuse to automatically negotiate/re-negotiate if it is still "Finished" regardless of your "Require/Force OTR" setting. This is just bad, and often causes plaintext to leak. 5. It should be impossible for our client to send a message in plaintext by default, and the client should discourage counterparties from sending more than one plaintext message. Perhaps related to issue 3, I've not had very good results with the "Require OTR"/"Force OTR" options on many clients. It also seems like many people's clients will still send the first message unencrypted (to get the handshake hint), and on all clients OTR doesn't seem to try very hard to negotiate if an unencrypted message is received. On our side, we should hold those messages and send only the handshake initiation (ie our default OTR mode should be REQUIRE_ENCRYPTION). We may also want to consider a plaintext auto-reply for when we receive unencrypted messages. Something like "Please install and enable OTR before sending further messages" as a separate message in *addition* to attempting an OTR handshake. 6. The UI should have per-message encryption indicators (send and receive) For many clients, the UI is not clear which messages were sent encrypted, especially if the OTR state has changed due to autonegotiation or "Finishing". We should have per-message icons for both sent and received messages that indicate encryption status for that message in the chat scrollback window. 7. Logging should be off by default when OTR is on. -- Mike Perry

3 2

REMINDER: Attentive Otter IM meeting in 1h [1430 Pacific]
by Tom Lowenthal 18 Oct '13

18 Oct '13

Today at **1430h Pacific** (an hour from now), we'll be in #tor-dev talking about how to turn Instantbird into TorMessenger, or MessengeTor, or OnionTalk, or something. Some of you noticed my cunning test of putting different times in the subject and the body. The body was right, it's 1430 Pacific! See y'all soon! -Tom On 15 October 2013 21:57, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Sorry about this late notice too. I thought I'd sent these times out > already, but apparently I was rather mistaken. > > We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to > talk about the Tor IM project. We may take up to 90 minutes, and plan > to meet again next week, probably at the same time unless there are > conflicts. > > Arlo came up with [a cunning plan][1] m'lord. You should totes read it > and come tomorrow with questions and suggestions about how best to > implement Instantbird as the Tor IM app. > > See y'all tomorrow. Play nice, now. > -Tom > > [1]: https://gist.github.com/arlolra/6969273

2 1

REMINDER: 1 hour until Cute Otter hidden services & publishing
by Tom Lowenthal 16 Oct '13

16 Oct '13

Just under an hour until 1130 Pacific on Wednesday 2013-10-16. We'll be in #tor-dev, talking hidden services and publishing. -Tom On 15 October 2013 21:40, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Sorry about the late notice, folks. I thought I'd sent these times out > already, but apparently I was rather mistaken. > > We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to > talk about hidden services, scaling thereof, and safe publishing > therewith. We may take up to 90 minutes, and plan to meet again next > week, probably at the same time unless there are conflicts. > > It'd be super neat if you could familiarize yourself with [Sina's > proposal][1] before the meeting. Come with constructive comments and > suggestions. > > See y'all tomorrow. > -Tom > > > [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

Attentive Otter IM: tomorrow Wednesday 2013-10-16 at 1400h Pacific
by Tom Lowenthal 16 Oct '13

16 Oct '13

Sorry about this late notice too. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to talk about the Tor IM project. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. Arlo came up with [a cunning plan][1] m'lord. You should totes read it and come tomorrow with questions and suggestions about how best to implement Instantbird as the Tor IM app. See y'all tomorrow. Play nice, now. -Tom [1]: https://gist.github.com/arlolra/6969273

1 0

Cute Otter hidden services & publishing: tomorrow Wednesday 2013-10-16 at 1130 Pacific
by Tom Lowenthal 16 Oct '13

16 Oct '13

Sorry about the late notice, folks. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to talk about hidden services, scaling thereof, and safe publishing therewith. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. It'd be super neat if you could familiarize yourself with [Sina's proposal][1] before the meeting. Come with constructive comments and suggestions. See y'all tomorrow. -Tom [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

Comments Requested: General anonymity with Tor video
by Sherief Alaa 15 Oct '13

15 Oct '13

Hello Everyone, I am working on a general anonymity with Tor video [0] and a script [1] for it. This video will be translated to all of the help desk languages. Basically, the video will some slides playing while I talk/explain them, both the video script and the slides can be found on trac [0][1] I would appreciate your comments/suggestions before I start recording the video. (Deadline 18-Oct-2013.) If you find any mistakes, please let me know here or on trac [0][1] Thanks! [0] https://trac.torproject.org/projects/tor/ticket/5991 [1] https://trac.torproject.org/projects/tor/ticket/6922 -- Sherief Alaa pgp 0x8623B882

2 1

REMINDER: Boisterous Otters helpdesk meeting in 1h
by Tom Lowenthal 15 Oct '13

15 Oct '13

Today at 1100h Pacific (an hour from now), we'll be in #tor-dev to discuss how we're going to start offering webchat support, in line with the [draft][1] produced by Colin (Phoul), with help from Lunar and Erinn (Helix). See y'all soon! -Tom [1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous…

1 0

OnionMail 0.1.1 Beta is Out
by Liste 15 Oct '13

15 Oct '13

Next week we will translate the web site. http://onionmail.info/

1 0

ACTION REQUESTED: Help me plan deliverables for Sponsor F, Year 4 [due Friday, discussion Monday]
by Tom Lowenthal 14 Oct '13

14 Oct '13

<https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4> Sponsor F year 3 ends at the end of this month. Fear not though, for year 4 starts right after that! We need to get to work planing the things that we'll do during year 4, so that we can tell Sponsor F what they are and all that good stuff. For your convenience, I have prepared a [RiseUp pad][1] where we can put all our ideas (no I don't have an [AllOurIdeas][2] instance). For convenience and expediency, I would very much like it if you could get your ideas into this pad before **Friday 2013-10-18**. Then folks can look at them over the weekend, and we can talk about it next **Monday 2013-10-21, from 1100-1230h Pacific**. If you are in the `to` field, that's because I have some particular reason to believe that you are likely to be involved in year 4 (probably because you were in year 3). You should totes make sure you get your plan into the pad. To get started, you should head over to the [pad][1] and add your thoughts. Any questions? -Tom [1]: https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4 [2]: http://www.allourideas.org/

1 0

Stem Release 1.1
by Damian Johnson 14 Oct '13

14 Oct '13

Hi all. After seven months of work I'm pleased to announce Stem's 1.1.0 release! 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? ============================================================ * Remote Descriptor Fetching The stem.descriptor.remote module allows you download current Tor descriptor data from directory authorities and mirrors, much like Tor itself does. With this you can easily check the status of the network without piggybacking on a local instance of Tor (or even having it installed). https://stem.torproject.org/api/descriptor/remote.html For example... from stem.descriptor.remote import DescriptorDownloader downloader = DescriptorDownloader() try: for desc in downloader.get_consensus().run(): print "found relay %s (%s)" % (desc.nickname, desc.fingerprint) except Exception as exc: print "Unable to retrieve the consensus: %s" % exc ============================================================ * Connection Resolution One of arm's most popular features has been its ability to monitor Tor's connections, and stem can now do the same! Lookups are performed via seven *nix and FreeBSD resolvers, for more information and an example see... https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resol… ============================================================ * Numerous Features and Fixes For a rundown of other changes see... https://stem.torproject.org/change_log.html#version-1-1 Cheers! -Damian

1 0

Checking Tonga's consensus (was: Consensus issues)
by Karsten Loesing 14 Oct '13

14 Oct '13

On 10/14/13 6:45 AM, metrics wrote: > WARNING: The consensuses published by the following directory authorities are more than one hour old and therefore not fresh anymore: Tonga Hi Damian, why do you check Tonga's consensus? Tonga is not a v3 directory authority but just a directory mirror. All the best, Karsten

2 1

More Hidden Services help needed: Guard enumeration
by George Kadianakis 14 Oct '13

14 Oct '13

Greetings, another important Hidden Service issue, is the guard enumeration attack that was described by the "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" paper (in section VII) [0]. A trac ticket was created to fix this issue (#9001 [1]). The most popular solution so far seems to be the 'Virtual Circuit' concept. The idea here is that if you have already created a circuit to a Rendezvous Point, and then that circuit fails and you need to connect to a different RP, then maybe you could reuse the previous hops of the circuit and only change the last hop to the new RP. This is an interesting concept and useful in other occasions too. For example, if the network is flooded with CREATE cells (like during the recent botnet invasion) and relays reject them because of increased workload, then maybe clients shouldn't build entirely new circuits to send CREATE cells to different relays (because building new circuits increases the total load of the network even more). However, this concept must be designed carefully and in a security-conscious way. Reusing parts of old circuits to connect to new nodes might result in unexpected attacks. More solutions have been proposed in #9001, like "guard node layers", which need further investigations. If you think you can contribute to this topic, please write your ideas in this mailing list or in ticket #9001. Enjoy. [0]: www.ieee-security.org/TC/SP2013/papers/4977a080.pdf‎ [1]: https://trac.torproject.org/projects/tor/ticket/9001

1 0