- tor-dev - lists.torproject.org

Re: [tor-dev] [linux-elitists] Browser fingerprinting
by Eugen Leitl 14 Oct '13

14 Oct '13

----- Forwarded message from katana <katana(a)riseup.net> ----- Date: Mon, 14 Oct 2013 09:27:41 +0200 From: katana <katana(a)riseup.net> To: cypherpunks(a)cpunks.org Subject: Re: [linux-elitists] Browser fingerprinting Message-ID: <525B9CED.20907(a)riseup.net> User-Agent: Thunderbird Hi, > Check out firegloves. It's outdated, and I'd love to see it getting > some love, but it's a great POC for anti-fingerprinting in Firefox. In <http://www.cosic.esat.kuleuven.be/publications/article-2334.pdf> about their FPDetective Framework <http://homes.esat.kuleuven.be/~gacar/fpdetective/>, the authors wrote about Firegloves: "Additionally, Firegloves limits the number of fonts that a single browser tab can load and reports false dimension values for the offsetWidth and offsetHeight properties of HTML elements to evade JavaScript-based font detection. We evaluated the effectiveness of Firegloves’ as a countermeasure to fingerprinting, and discovered several shortcomings. For instance, instead of relying on offsetWidth and offsetHeight values, we could easily use the width and the height of the rectangle object returned by getBoundingClientRect method, which returns the text’s dimensions, even more precisely than the original methods. This enabled us to detect the same list of fonts as we would without the Firegloves extension installed. Surprisingly, our probe for fonts was not limited by the claimed cap on the number of fonts per tab. This might be due to a bug, or to changes in the Firefox extension system that have been introduced after FireGloves, which is not currently being maintained, was first developed. Although Firegloves spoofs the browser’s user-agent and platform to pretend to be a Mozilla Firefox version 6 running on a Windows operating system, the navigator.oscpu is left unmodified, revealing the true platform. Moreover, Firegloves did not remove any of the new methods intro- duced in later versions of Mozilla Firefox and available in the navigator object, such as navigator.mozCameras and navigator.doNotTrack." I add: OK, the naviagtor.oscpu issue can be fixed easily, but the timezone feature doesnt't work too with enabled JavaScript. --- Katana ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

Attention Otters
by Arlo Breault 14 Oct '13

14 Oct '13

Not sure the following is entirely clear or complete, but I tried to capture the concerns from the meeting and the ensuing discussion. Hope it helps. Arlo Attentive Otter Plan ==================== Goal ---- Add instant-messaging to the Tor browser bundle in order to provide a secure communication tool which supports the free flow of information online. Overview -------- Instantbird [1] is a cross-platform IM client based on Mozilla's XULRunner. The following presents the necessary steps to turn Instantbird into the future Tor Messenger. A Way Forward ------------- 1. Remove libpurple dependence This is a trivial amount of work and changes to the build to support it would be accepted upstream. They are already considering moving libpurple, and the added protocols it supports, to an add-on for reasons of licensing/code quality. JS implementations of the following protocols exist: XMPP, Google Talk, Facebook, IRC, Twitter, with Yahoo landing soon and AIM/ICQ started but further away. 2. OTR support Instantbird currently lacks support for OTR. Two pieces are needed here: a suitable OTR implementation, and an interface between the client and that library (essentially, the role that pidgin-otr plays). To get started, for the OTR library, a js-ctypes wrapper of libotr should be used in conjunction with the message observer API. Code [2] from a few years ago towards this end has been written but probably needs to be dusted off and extended. An effort is underway at Mozilla to implement OTR in JS using NSS, which could be dropped in as a replacement. A patch has been submitted [3] but it looks far from complete, so I wouldn't expect it anytime soon. When asked, they said it won't be ready for *a while*. Should the NSS implementation fail to materialize entirely, they would still be willing to take the ctypes wrapper and libotr, as it doesn't present any licensing issues. In his analysis, Mike suggested converting the ctypes wrapper to an XPCOM wrapper but it's unclear why that's preferable. The front-end side seems like a larger undertaking. This involves not only the interaction with the message observer API but handling the quirks in the various protocols (think /me in IRC), authentication including SMP, and importing and storing long-term keys. Sukhe estimated at least a month of development time and expressed an interest in being the one to undertake it. On the bright side, the Instantbird team seems eager for OTR support and this work will most likely be upstreamed. 3. Disable logging An add-on may be required to ensure certain desirable configurations, like logging disable by default. A difference in goals between UX for the average user and the TIMBB user may force us to maintain these changes. 4. Tor controller Tor Launcher will be used as the controller. Sukhe has already reported having this working. Using only JS protocol implementations means all traffic goes through nsIChannels, making proxy support fairly easy to verify. For DNS, network.proxy.socks_remote_dns should be set. DNS SRV should not be an issue seeing as how it isn't supported by Mozilla [4]. Should test for other UDP traffic leaks. 5. Messaging window Jail it to type=content. Preferably everything is displayed in plaintext, with HTML disabled or at least sanitized with an XSS filter [5]. Disable JS and other features. Make use of all the preferences from TorBirdy. 6. Installer and updates Leverage the work that's already being done on Mozilla's updater for the TBB. 7. Deterministic builds Deterministic builds for the TBB was a major undertaking. I can't imagine this case being any different, less the experience and groundwork already laid. 8. Sandboxing Come up with a practical, cross-platform way to sandbox the application. I don't have an answer here. Maybe you do. 9. Audit - Instantbird's render attack surface (content window, XSS filter, etc.) - Crypto in NSS and how JS uses it - Interface between the UI and OTR - Proxy by-pass - And more ... 10. Translations Instantbird is available in 14 languages, including French and Spanish. However, none are RTL and we want to support Arabic and Farsi. Messaging should already work for RTL languagues though, they've fixed a few bugs to ensure it, and reflecting the UI is reported to not be a ton of work. They are definitely willing to accept patches here. 11. Other considerations - Disable Instantbird's built-in auto-updater and crash reporter - For sure OTR on by default, but maybe disallow any non-OTR comm. entirely - CA verification: TOFU mode? Pin popular domains? - Disable older TLS/SSL suites - Consider the interaction between all three Tor bundles (FF, TB, IM). Tor Launcher could attempt to authenticate and read settings from an already running control port. - Choose a different default profile folder (to avoid picking up plugins and other unsafe settings) References ---------- [1] http://instantbird.com/ [2] https://gitorious.org/fireotr/fireotr [3] https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c20 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=14328 [5] https://mxr.mozilla.org/comm-beta/source/chat/modules/imContentSink.jsm

1 0

Chutney
by Charlie Belmer 11 Oct '13

11 Oct '13

Hey everyone, I am running some Chutney tests, and I want to go deeper than just running the bootstrap script and watching logs. Does anyone have advice on how to get the most out of Chutney? Thanks! Charlie

2 1

Pluggable transport biweekly meeting - Friday Oct 11
by vmonmoonshine＠gmail.com 11 Oct '13

11 Oct '13

Just a gentle reminder that the PT meeting is today in few hours: Friday - Oct 11 at CEST: 18:00 BST (Summer GMT): 17:00 UTC: 16:00 EST: 12:00 MNT: 10:00 PST: 9:00 @ #tor-dev on irc.oftc.net asn is going to moderate the session. (I have a very slow connection but I'll try to join) See you all there, Vmon

1 0

[Otter/Boisterous] WebChat report
by Colin C. 11 Oct '13

11 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The Boisterous Otter project requires us to offer assistance to users through instant messaging. Current plan: use an XMPP server allowing anonymous connections from a web interface on one side, and have the support team use an authorized account for each language. The full report is viewable on the wiki at https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous…. (Thanks to Lunar & Erinn for assisting with this) - -- - -Phoul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSV320AAoJEJ01Zvx7KO7YOgwQALmsJsnyVRUQ07CiqmxI+zle dNsROZvnNvhfPyza5McBjxckXQ5fD5tgCL5TMxzkBD3ICFQgZWByrX/bMN2ZFfx0 nh12TCs64TvMFAXnTVKRopBYfkas/uSs3PhM4vnPULJ+mDbFoMNKXkJP42s7jkGK D3q2+2k/yR9mu9IVLI9agKppR/L1Yq/lPzt9DFo0YZyIrI0nNrn9hFMCGQKuCl0u S40DWXXtUXn1a0qg4mFKGurrVua7ZvMeLqmZExhLMY8AnFBP40ELP0mmM0KkQg1F kW0ijmybEMcPwKsWltTNzwHj8pg7dLjD19/ZrVMjIhjinap0XDqcyjqJD3T1J4KE ti0+wZ7wXRfjJs6eA0otfu6xfF5JGYvOd9KniN567aPxjCVb2s1Gm60zA1PGQwAe npT3WTm4z02SHThEeS4NPJi1Vvt0WLGlHo6v5p0Fr+/g1dYqEmTK+6+kAHk+e2CS OXSvJ16rj7kncLMf9SImvbk0+nojC9qT/jgJQm4IBgxzSq+TVNwn463JpCdpCI6m wfqxAAqy3V+ZjG+KxZTrxRST/s5rdhKi+iiZUzgqx0SC/hEqWEoId+2q3DPyb69h exBV0eUE0XsHKi12qySOef7BfQXO2q15cdUcu+9VzqULcwP+xKd5NziVDMWd95fj skzK8xFSm4Epdpp65VWI =CISa -----END PGP SIGNATURE-----

1 0

[Otter/Cute] What's Cute in APAF
by Michele Orrù 10 Oct '13

10 Oct '13

Dear Team, For completeness' sake I am attaching to this email the report I wrote last week in order to summarize what the project APAF is about, and what there is in common between it and the Otter/Cute proposal. Eventually, feel free to add it to the trac page. After reading ["Cute" design and challenges], though, I think the report lacks an exhaustive description of APAF's threat model. In APAF's documentation, the only document vaguely resembling a threat model is embarassingly poor in terms of content[0]. If still possible, I would like to remedy writing a more detailed one during this week-end, maybe really pentesting the application with your help this time. Does this sound visible to you? ["Cute" design and challenges] <https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter…> [0] <http://apaf.readthedocs.org/en/latest/threat_model.html> -- mi.

2 1

Otter-related outreach, training & documentation meeting is at 1530h Pacific on Tuesday 2013-10-15
by Tom Lowenthal 10 Oct '13

10 Oct '13

It'll be in #tor-dev. If you want to be in the `to` field for future emails, announcements, and so on (rather than just reading them on `tor-dev` or `tor-assistants`), you should add your name, IRC nick, and email to the [Buoyant wiki page](https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Buoy…. -Tom On 8 October 2013 16:20, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > People of Earth, heed my call! > > Based on feedback that Boisterous Otters has too much to do, and on > the fact that current Boisterous meetings are using their full time on > only half the topics, we're splitting Boisterous into two components. > > The first component is going to stick with the name Boisterous, and > deals with the first two activities: the helpdesk, and l10n. If you're > already working on these things, nothing is changing for you, and you > may be able to stop reading this right here. > > The second component is picking up the name **Buoyant**, and will deal > with the remaining activities: > * written materials on general communications security > * short videos multi-language training videos > * outreach to Iranians and the Iranian diaspora > * social-media, radio, and television outreach. > * training, and train-the-trainer work > > If that sounds like your cup of tea, kettle of fish, or flagon of ale, > then you should come help us get started by filling in this [Doodle][] > **by Wednesday afternoon** so that I can plan a meeting at the end of > this week or the beginning of next. Please fill out the Doodle if > you're definitely coming, and plan to be part of the core effort. If > you just want to show up to spectate or lend a hand, there's no RSVP > needed. > > I plan to look at the Doodle around 1700-1900h Pacific tomorrow, and > I'll use whatever it says then to try and pick the best time. I'll > send the time out to tor-dev, bcc-ing everyone who's expressed an > interest or answered the poll. That's 24 hours to give me your > availability, but only about 16 hours between when I send out the time > and the first possible meeting slot, so check your mail tomorrow > evening Pacific. > > If you have any specific suggestions about venue, format, or other > running *of the meeting*, and you plan to be there, please reply > publicly or privately before I send out the scheduling meeting. If you > have specific plans about how to git'er done, you can either email me, > or bcc me on a tor-dev-bound email with an appropriately-ottery > subject line. Do note, however, that other folks may not be able to > read your suggestions if you send them less than 12 hours before the > meeting. I'll try to read them anyway, but that's only out of the > kindness of my heart. > > Questions on a postcard please, > -Tom > > [Doodle]: http://doodle.com/pm5cfunbcwuyrwh6

1 0

Pushed HS proposals on git
by George Kadianakis 10 Oct '13

10 Oct '13

Hey Nick, I pushed the recent HS proposals to my torspec git repo. You can find them on branch 'hs_experimentation' at https://git.torproject.org/user/asn/torspec.git . My next step would be to write the anti-enumeration crypto part of xxx-hs-id-keys-and-onion-leaking.txt (as I started doing with c8b7e40). Feel free to work on them. Maybe send me an IRC message before you start touching them so that we don't do change the same areas of the spec.

1 0

[ACTION REQUESTED] Cute Otters hidden services publishing meeting request &c. [due Friday Morning]
by Tom Lowenthal 09 Oct '13

09 Oct '13

Hello cute pals. We didn't have a meeting today due to scheduling. If you think you want to work on making point-click-publish hidden services a reality, and hidden services better in general, then this is what you should do: 1. [Note down when you're free next week.][1] 2. Add your name, IRC nick and email to the [Cute wiki page][2]. 3. Read [Sina's proposal][3]. I'm planning to read [this Doodle][1] and send out updates on Friday morning (Pacific). If you haven't filled it out by then, I won't be able to account for your preferences. Please fill out the doodle only if you think that I need to consider your availability before scheduling the meeting. If you just want to spectate, no RSVP is needed, you can just lurk in #tor-dev. Please make sure that you only fill out times that you can actually make it. Future emails about Cute Otters will be sent `to` the email addresses listed on the [Cute wiki page][2], `cc`'ing `tor-dev` and `tor-assistants`. If you want to get messages "to" you, you should add yourself to the team listing on the [Cute wiki page][2]. Sina has produced an [outline of the publishing system][3] we're planning to build. You should read it, help him improve it, and come to the meeting next week prepared. That's all for now, -Tom [1]: http://doodle.com/wqr9phdck23mac7u [2]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute [3]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

[30-minute reminder] Cute Otters hidden services and publishing meeting at 1500h Pacific in #tor-dev
by Tom Lowenthal 09 Oct '13

09 Oct '13

See you soon.

1 0

[ACTION REQUESTED] Attentive Otter IM bundle: meeting scheduling; team signup [due Friday]
by Tom Lowenthal 09 Oct '13

09 Oct '13

Please read your other mail or the [wiki][2] for a status update. In addition, I would like you to do the following two things: 1. [Tell me about your availability][1] to meet next week. 2. Add your name, preferred email, and IRC nick to the appropriate section of the [Attentive Otter wiki page][2]. For maximum effectiveness, you should before about 1530h Friday, since that's when I'll send out the meeting invite. If you haven't filled the Doodle out, I won't account for your availability. If you haven't added your details, you'll need to read `tor-dev` or `tor-assistants` to find out when the meeting is. [1]: http://doodle.com/g7xq4e2x8pgf7vda [2]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Attentive

1 0

Attentive Otter: Analysis of Instantbird/Thunderbird
by Mike Perry 09 Oct '13

09 Oct '13

This outline was a collaborative effort between me and Sukhbir Singh. Code and package URLs: Packages: http://instantbird.com/download-all.html Nightlies: http://nightly.instantbird.im/ Instantbird Code: http://hg.instantbird.org Thunderbird Code: https://github.com/mozilla/releases-comm-central FAQ: http://instantbird.com/faq.html Instantbird Overview: + Cross-platform (Windows, OS X, Linux). + Based on XUL+XPCOM (specifically Thunderbird). + Many existing Thunderbird addons should be easy to port. + Periodically syncs its codebase with Thunderbird: - https://bugzilla.mozilla.org/show_bug.cgi?id=920801 + Thunderbird can be used as combined secure Chat+Email communications software. + One piece of software for all secure communications is a usability win + Leveraging the work done on TorBirdy, we can distribute Instantbird and Tor (and related components) in a single package, or as a combined addon. + Use Tor Launcher as the controller (sukhe recently added Thunderbird support) + Will allow seamless zero-configuration Tor usage for normal case, and will share Tor Browser's future Pluggable Transport support with no additional effort. + See the TorBirdy manual for more information: https://trac.torproject.org/projects/tor/wiki/torbirdy#TorBirdywithTorandTo… + Good protocol support: Currently Instantbird supports by default: AIM, Bonjour, Facebook Chat, Gadu-Gadu, Google Talk, Groupwise, ICQ, IRC, MSN, MySpaceIM, Netsoul, Odnoklassniki, QQ, Simple, Twitter, VKontakte, XMPP, Yahoo and Yahoo JAPAN. + Supports "portable version". + InstantBird is available in 14 languages; Thunderbird is available in ~65 + Clean and easy to use interface. + We are amassing a fair amount of in-house expertise with Mozilla/XPCOM, which we can use for code review, UI design, etc. + Can also leverage our existing relationship with Mozilla to share workload Security Properties: * Currently based on libpurple, but Mozilla is working to replace libpurple with pure JS implementations (due to both licensing and code quality/security issues with libpurple). Instantbird nightlies have this code but it must be enabled via about:config. Seems to work. + http://clokep.blogspot.com/2013/10/yahoo-protocol-google-summer-of-code.html + http://lxr.instantbird.org/instantbird/source/chat/protocols/ + http://lxr.instantbird.org/instantbird/source/chat/protocols/xmpp/ - No OTR support yet + OTR support tickets: https://bugzilla.instantbird.org/show_bug.cgi?id=877 https://bugzilla.mozilla.org/show_bug.cgi?id=779052 + For a stopgap/prototype: We can use the js-ctypes wrapper of libotr along with the message observer API + Example observer API use w/ rot13: http://hg.instantbird.org/addons/file/tip/rot13 + JS-Ctypes wrapper for native libotr: http://gitorious.org/fireotr/fireotr/blobs/master/chrome/content/otr_wrappe… + The ctypes wrapper can be converted to an XPCOM wrapper later. + According to sshagarwal #maildev on irc.mozilla.org, Mozilla is also working towards implementing all of the primitives needed for OTR (and OTR itself) in NSS. These are listed in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c17 + We could also rely on the ctypes wrapper until native support is available, and possibly skip an XPCOM libotr wrapper entirely. + Solid proxy support. JS XMPP implementation allows you to omit DNS SRV and since everything goes through nsIChannels, proxy support is easy to verify and audit. + Messaging window is jailed to type=content (unlike cryptocat) and is additionally XSS filtered immediately prior to display: https://mxr.mozilla.org/comm-beta/source/chat/modules/imContentSink.jsm Summary of Goals Met: Release a secure, portable chat program that sends all traffic over Tor: + Yes. Can be used with a wide variety of chat networks: + Yes, even without libpurple Uses off-the-record encryption of conversations by default: - Not yet, but support is coming, and it's not too hard to deploy a stopgap French, Spanish, and Arabic support: * Partly yes. Full support for French and Spanish, but Instandbird has no translations for Farsi or Arabic (however Thunderbird does support these locales and can also be used as a chat client). -- Mike Perry

3 2

Attentive Otter IM bundle update
by Tom Lowenthal 09 Oct '13

09 Oct '13

We had a meeting as scheduled at 1100h Pacific. We broadly agreed that: * we don't want to use Pidgin/libpurple * we have a mild preference for Instantbird. We have some open questions about Instantbird: 1. What sort of attack surface does Instantbird present, compared to -- say -- a browser. 2. What's the timeline for Instantbird implementing OTR, and how are they going about it. Our current plan is to go for a more thorough investigation of Instantbird, and work out what we'd need to do to take Instantbird and produce Tor Messenger, and what roadblocks stand in our way. We were unable to find a lead for this project during the meeting. Afterwards, Arlo volunteered to put together such a plan, and possibly even execute it. Arlo has committed to putting that plan together by the end of the weekend. If we allow Monday morning to read and digest Arlo's work, we should reconvene some time on Monday afternoon, Tuesday, or Wednesday next week. [Let me know when you're free.][1] I've decided to send out updates to both tor-dev and tor-assistants, as well as to the individual addresses of folks who are interested. I'm committed to using the string "Otter" and "Attentive" in the subject line. If you want to get those emails, please [edit the wiki page][2] to add that info. I've only put my info there for now, so please edit it if you want to get personal attention in future emails. What you should do now: 1. Please [tell me about your availability][1] to meet next week. 2. Please add your name, preferred email, and IRC nick to the appropriate section of the [Attentive Otter wiki page][2]. [1]: http://doodle.com/g7xq4e2x8pgf7vda [2]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Attentive On 9 October 2013 09:04, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Hello hello, > > This is your roughly 60-minute reminder that we'll be comparing > proposals for the IM browser bundle on #tor-dev in about an hour. For > your reference, and to brush up on the research that everyone > valiantly did, the analyses are: > > *[Purple](https://lists.torproject.org/pipermail/tor-dev/2013-October/005544.html) > *[xmpp-client](https://lists.torproject.org/pipermail/tor-dev/2013-October/005546.html) > *[Instantbird](https://lists.torproject.org/pipermail/tor-dev/2013-October/005555.html) > > That's all for now. > -Tom

1 0

Pluggable Transport TBB Build
by Kevin P Dyer 09 Oct '13

09 Oct '13

Hi David, Sorry I missed the most recent Pluggable Transport bi-weekly meeting. In regards to the PTTBB build, I plan to make progress towards a streamlined build process. Platforms I want to get the PTTBB build working on: 1) CentOS 5.9 (32-bit) 2) CentOS 5.9 (64-bit) 3) Windows 7 4) OSX 10.8 For each build platform I'm going to: 1) Create a VirtualBox image. 2) Construct a script that takes the latest TBB release and VirtualBox image as input, and outputs a PTTBB zip file. The output PTTBB zip file will include all of the "deployed" pluggable transports. The build process must be deterministic and reproducible. I was hoping to do this on Amazon Web Services, to avoid the licensing issues. However, AWS does not support OSX. By using VirtualBox, it reduces the problem to each developer acquiring their own VirtualBox image for each target platform. Not desirable, but I don't have a better solution. I anticipate this will be a non-trivial effort to get working correctly. So, it would be great if you could help me adjust my plan to minimize headache! Thanks! -Kevin

2 4

Reminder: Attentive Otter IM Bundle Meeting in 1h
by Tom Lowenthal 09 Oct '13

09 Oct '13

Hello hello, This is your roughly 60-minute reminder that we'll be comparing proposals for the IM browser bundle on #tor-dev in about an hour. For your reference, and to brush up on the research that everyone valiantly did, the analyses are: *[Purple](https://lists.torproject.org/pipermail/tor-dev/2013-October/005544.html) *[xmpp-client](https://lists.torproject.org/pipermail/tor-dev/2013-October/005546.html) *[Instantbird](https://lists.torproject.org/pipermail/tor-dev/2013-October/005555.html) That's all for now. -Tom

4 3

Re: [tor-dev] [tor-commits] [tor/master] Clarify who learns about ContactInfo.
by Roger Dingledine 09 Oct '13

09 Oct '13

On Wed, Oct 09, 2013 at 01:45:26PM +0000, nickm(a)torproject.org wrote: > diff --git a/src/config/torrc.sample.in b/src/config/torrc.sample.in > index c667efc..78013c2 100644 > --- a/src/config/torrc.sample.in > +++ b/src/config/torrc.sample.in > @@ -120,9 +120,12 @@ > ## is per month) > #AccountingStart month 3 15:00 > > -## Contact info to be published in the directory, so we can contact you > -## if your relay is misconfigured or something else goes wrong. Google > -## indexes this, so spammers might also collect it. > +## Administrative contact information for this relay or bridge. This line > +## can be used to contact you if your relay or bridge is misconfigured or > +## something else goes wrong. Note that we archive and publish all > +## descriptors containing these lines and that Google indexes them, so > +## spammers might also collect them. You may want to obscure the fact that > +## it's an email address and/or generate a new address for this purpose. > #ContactInfo Random Person <nobody AT example dot com> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> Hi Nick, Karsten, You've just changed the torrc.sample.in file, which will cause everybody who uses the deb and upgrades from Tor 0.2.4.17-rc to have to manually evaluate/adjust/replace their /etc/tor/torrc file. Are you sure you want to do this? It's not the end of the world here since the torrc.sample was last updated for Tor 0.2.4.3-alpha, so people upgrading from 0.2.3.x debs will already be affected. But I wonder if it's really worth hassling every deb user who will be upgrading from 0.2.4.x? In any case we should update the ## Last updated 12 September 2012 for Tor 0.2.4.3-alpha. line at the top of the file, so we can accurately predict who will be affected by changes like this in the future. --Roger

3 3

Attentive Otter: Analysis of xmpp-client
by Jurre van Bergen 09 Oct '13

09 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi, Below you can find the analysis of xmpp-client for the Attentive otter project, written by dgoulet, nickm, arlo, asn and myself. All the best, Jurre - -------- Intro xmpp-client is a simple XMPP client written in pure Go with OTRv2 support. It's a terminal program but doesn't have a GUI or a UI like GTK or ncurses. The software should be considered in an alpha state. *Is traffic send over Tor?* Yes, xmpp-client has support for sending all traffic over Tor, this includes connecting to onion's. When you connect to jabber.ccc.de or the riseup.net jabber service, you are automatically connected over Tor through their onion address (hidden service), if Tor is running. SRC lookups are not proxied. *Chat network(s) support* Only basic XMPP support, no extensions are implemented (XEP - http://xmpp.org/xmpp-protocols/xmpp-extensions/) *How trivial is extending XMPP-Client to different protocols?* This code base is only for XMPP and seems quite hardcoded for that. Section "Instant Messaging" - https://code.google.com/p/go-wiki/wiki/Projects#Networking * XMPP in Go - https://github.com/mattn/go-xmpp * IRC in Go - https://github.com/husio/go-irc * Various Go bindings - http://go-lang.cat-v.org/library-bindings *OTR* OTR support comes from the Go crypto package: https://code.google.com/p/go.crypto/ This library only has support for OTRv2 and not the latest OTRv3 specification. If we want to be resistant to several attacks[1] on the OTR protocol, we need to reimplement the OTR protocol and update it to the latest version or, we use Cgo, which binds into libotr. (Open questions: OTR by default?, ) [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.165.7945&rep=rep1&… *What languages are supported?* Currently, there is only support for English, extending the client with other languages is rather trivial like Farsi, French, Spanish and Arabic. *_Graphical interface_* A graphical interface needs to be implemented for the client. However, there is only a limited amount of graphical interfaces available, all are far from stable to use. The best bet for now is Go-GTKand extend it and let fixes go upstream. Another thing we could do is implement or extend an existing minimal implementation of a QT library. This means however, that we would need to maintain an extra "third party" UI library, which isn't Tor's core "business". * QT: https://github.com/visualfc/go-ui * GTK: http://mattn.github.io/go-gtk/ * Webkit: https://github.com/mattn/go-webkit *_Operating System Support_* *Windows* * MSI package support - http://golang.org/doc/install#windows *Mac OS X* * Package exists for Go - http://golang.org/doc/install#osx *Linux* Packaged in most distributions. *_Build & build automation_* *Cross-platform* Go compiles into a static binary. Next to that, Go has the possibility to build cross-platform binaries. *Deterministic builds* Some hacking needs to be involved and having a deterministic binary for Go might prove more difficult. I'm unsure whether this is going to be easily implemented (more research needed) *Browser extention* Of what I can understand with Xullauncher, we can start any type of applications shipped in the "TBB sandbox" in a specific path. With xmpp-client, it would require a Go version that is shipped with the TBB and every other library we use (i.e. crypto.otr). (Not 100% sure here...). A fat binary is an option here also (Go + otr + xmpp-client). *Control mechanism* A control mechanism needs to be implemented so xmpp-client can interact with Firefox in some way or the other. *_Hardening_* *Building with hardenend compiler flags* Hardening is possible by using gccgo, which is a frontend to the GCC gnu compiler. * http://golang.org/doc/install/gccgo *Sandboxing* * There is an existing AppArmor profile for xmpp-client for Ubuntu 11.04+ * There isn't a Seatbelt OSX sandbox profile. * There isn't a way to sandbox in windows. - -- Developer at https://www.useotrproject.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSUu2kAAoJELc5KWfqgB0CnNAH/2ZpvUgB/enkgMZ7tH4q1cj7 w0S9N5bRD21JSYHpd9ZhvMOIHUOVOm8fothUvB1HVFwLhTMqsnqB5vtOPe117WYX WDp9rwicKz110r1dyEDcDhkGnI0OKJ5trDDalmmFaeFaP7gTwedee8lNRBdV+bPs tEqSGIxtNbY7WUpDZvTUBxkqZjAgWsag4K+fcn3ZA0m1vUmyWpyV+xYXCvjJH6fo oDVirvXpQibQxZWSLnRceq7otNXI1TdZL60KiipPJNDyfi5g5d3pToo3CU61wJgF 0KtvtzYnG5l476aJhd1hCdfO7Ni3NoZ1dheqPsRGcmNp/kICqbRYnc9MDqiCpEM= =e6xQ -----END PGP SIGNATURE-----

9 10

RESPONSE REQUESTED: scheduling Otter-related outreach, training, documentation &c. kickoff [due wednesday]
by Tom Lowenthal 08 Oct '13

08 Oct '13

People of Earth, heed my call! Based on feedback that Boisterous Otters has too much to do, and on the fact that current Boisterous meetings are using their full time on only half the topics, we're splitting Boisterous into two components. The first component is going to stick with the name Boisterous, and deals with the first two activities: the helpdesk, and l10n. If you're already working on these things, nothing is changing for you, and you may be able to stop reading this right here. The second component is picking up the name **Buoyant**, and will deal with the remaining activities: * written materials on general communications security * short videos multi-language training videos * outreach to Iranians and the Iranian diaspora * social-media, radio, and television outreach. * training, and train-the-trainer work If that sounds like your cup of tea, kettle of fish, or flagon of ale, then you should come help us get started by filling in this [Doodle][] **by Wednesday afternoon** so that I can plan a meeting at the end of this week or the beginning of next. Please fill out the Doodle if you're definitely coming, and plan to be part of the core effort. If you just want to show up to spectate or lend a hand, there's no RSVP needed. I plan to look at the Doodle around 1700-1900h Pacific tomorrow, and I'll use whatever it says then to try and pick the best time. I'll send the time out to tor-dev, bcc-ing everyone who's expressed an interest or answered the poll. That's 24 hours to give me your availability, but only about 16 hours between when I send out the time and the first possible meeting slot, so check your mail tomorrow evening Pacific. If you have any specific suggestions about venue, format, or other running *of the meeting*, and you plan to be there, please reply publicly or privately before I send out the scheduling meeting. If you have specific plans about how to git'er done, you can either email me, or bcc me on a tor-dev-bound email with an appropriately-ottery subject line. Do note, however, that other folks may not be able to read your suggestions if you send them less than 12 hours before the meeting. I'll try to read them anyway, but that's only out of the kindness of my heart. Questions on a postcard please, -Tom [Doodle]: http://doodle.com/pm5cfunbcwuyrwh6

1 0

Status report - Stream-RTT
by ra 08 Oct '13

08 Oct '13

Hi all! During the last weeks I have been very busy working on my GSoC project which is about reducing the RTT of preemptively built circuits. There is now a single script called "rttprober"[0] that depends on a patched[1] Tor client running a certain configuration[2]. The goal is to measure RTTs of Tor circuits. It takes a few parameters as input: an authenticated Stem Tor controller for communication with the Tor client, the number of circuits to probe, the number of probes to be taken for each circuit and the number of circuits that should be probed concurrently. It outputs a tar file containing lzo-compressed serialized data with detailed node information, all circuit- and stream-events involved and the circuit build time for further analysis. Since the RTT-measurements are run in parallel with very short locks it is important not to overload Tor nodes. Therefore a single node is not probed more than once at a time. A first analysis of some measurements taken supports the original assumption that a Frechét distribution fits both the circuit build times[3] and round trip times[4]. I will continue gathering and analyzing measurement data and will hopefully be able to draw some conclusions from that. Best, Robert [0] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/rttprober.py?at=master [1] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/patches?at=master [2] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/torrc?at=master [3] http://postimg.org/image/je8k5yydt/ [4] http://postimg.org/image/ktk90vxm7/

3 9

Tor Beta area
by Phill Whiteside 08 Oct '13

08 Oct '13

Hi good people, I do run a relay [1], but with my work as Team Leader for lubuntu quality / testing [2] with our small, but dedicated, team I cannot allocate the time to install and test your RC. Instead, I put at your disposal a VM (kvm) with a dedicated ipV4 address running ubuntu server 12.04 LTS. This can be changed to what ever is best used for testing. I can take snapshots, so if you crash & burn it, it does not take too long to re-install. It also can pull full logs out out of a broken VM using guestfish[3] If this would be of use for you on alpha / beta testing relay software, please do get in touch. Regards, Phill. 1. https://metrics.torproject.org/relay-search.html?search=176.31.156.199 2. https://wiki.ubuntu.com/Lubuntu/Testing 3. http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html#t16:01 -- https://wiki.ubuntu.com/phillw

1 0

Fwd: [rt.torproject.org #14731] Off by one buffer overflow in tor stable
by Pedro Ribeiro 08 Oct '13

08 Oct '13

---------- Forwarded message ---------- From: Colin Childs via RT <help(a)rt.torproject.org> Date: 7 October 2013 14:25 Subject: [rt.torproject.org #14731] Off by one buffer overflow in tor stable To: pedrib(a)gmail.com On Mon Oct 07 12:13:21 2013, pedrib(a)gmail.com wrote: > Hi, > > I think there is a small buffer overflow (off by one) in the current stable > version of tor. > The function in question is format_helper_exit_status, which returns a > formatted hex string. It is in common/util.c, starting at line 3270. > The function has a comment header that explains how it works. It > specifically says it returns a string that is not null terminated, but > instead terminates with a newline. > > The code checks periodically throughout the function whether it has written > more bytes than it should. If it does, it errors out and writes a null > character in the current character positions. This by itself can lead to a > buffer overflow, but I believe the checks ensure that it almost never > writes over the buffer size - except in one case. > > After it has finished everything, it then checks again if there are more > than 0 bytes left in the buffer. If there are, it writes two characters - a > newline and a null terminator (lines 3342 to 3347). > > The problem here is if the buffer only has one byte left, an off by one > overflow occurs. These usually are very hard to exploit, but can be a > security issue nonetheless. > > However given that I am not familiar with the tor codebase I might be > wrong? I also did a quick security audit on the rest of the tor code and > couldn't find anything else. I was inspire because of the recent events... > > Regards > Pedro Hello, Please send a copy of this email to our tor-dev mailing list at https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev. Thank you! -- Colin C. ------------------------------------------- Hi, Please find above a bug report with possible security implications. I was a bit weary of sending to a public list at first, but I doubt the bug above is exploitable. Regards Pedro

2 2

REMINDER: Boisterous Otter helpdesk/l10n meeting in 2h, at 1200 Pacific
by Tom Lowenthal 08 Oct '13

08 Oct '13

Hello all, This is your irregularly-scheduled reminder that we will be discussing the Helpdesk and translation in just a smidge over two hours (that's 1200h pacific) in #tor-dev on irc.oftc.net. Highlights will include hearing from Sherief, Lunar, and Phoul about their research into ways to provide support chat accessible through our website. We'll also make a preliminary incursion into the topic of organizing shifts at predictable times. How very exciting! Other developments: I'm going to slice and dice Boisterous into two separate components which we'll run in parallel, otherwise these discussions and whatnot are going to run forever each. In this track, we'll continue with helpdesk and l10n. The other track will focus on outreach, training, videos, and documentation. If you're mainly in it for the helpdesk/l10n, you have nothing further to do: your meetings are just shorter. If you're interested in outreach, training, videos, and documentation, (and I already know that Kelley, Karen, Runa, and Sherief might be), then look for the meeting-scheduling message to go out to tor-dev, probably today. If you drop me a line, then I'll try to do something clever to make sure that the message hits your inbox too. That's all from this reminder. Any questions, folks? -Tom

1 0

CPAProxy - a thin Objective-C wrapper around Tor
by Claudiu-Vlad Ursache 08 Oct '13

08 Oct '13

Hi everyone, For those of you interested in making Tor available on iOS, I've recently released CPAProxy, a thin Objective-C wrapper around Tor ( https://github.com/ursachec/CPAProxy) The goal of the project is to release a free open-source browser on the AppStore that uses this wrapper and Tor to anonymize requests. It works by starting an instance of the Tor client in a background thread of an iOS app's main process. CPAProxy connects a socket to the client's control port, send an authenticate message and asks for the bootstrap progress until it reaches 100%. When the bootstrapping is done, the app is notified that Tor's SOCKS proxy is ready to be used. From that point on, networking requests can be sent over the proxy using Apple's iOS networking classes. The github repository contains two packet traces from a test app using CPAProxy of what traffic for an HTTP request looks like when it's sent over Tor and when in plain. The repo also contains build scripts that ease the compilation of openssl, libevent and Tor for iOS without changing anything in the "normal" build process except for removing _NSGetEnviron() and ptrace() calls in src/common/compat.c, since they're are not available on the iPhone. Each of the libraries are statically linked into the application binary. Before continuing with the endeavor of releasing a browser, it would help to know if there are people who think that it's not a totally bad idea to release software that uses Tor on a closed platform and to get some feedback on what security considerations are of high importance. Some open questions I'm still looking answers for: - What webkit features have to be disabled in order to keep anonymity intact while displaying web content? - Apple's networking classes provide ephemeral in-memory URL Sessions ( NSURLSessionConfiguration<https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/URLL…>). Can those be trusted or should equivalent classes be written from scratch? - CPAProxy sets up Tor's DataDir in a temporary directory of an app's sandbox where it's not accessible by other processes. Should that directory be protected in any other way? - What is a good way of analyzing packet captures from an app using CPAProxy and Tor to see if any information leaks? If there's anyone with opinions on the project, it would really help to hear them. On #tor-dev I'm ursachec. All best from Hamburg, Claudiu -- Claudiu-Vlad Ursache Homepage: cvursache.com Phone number: +49 152 554 08 409 Address: Lange Reihe 113, 20099 Hamburg

2 1

Re: [tor-dev] Project *Cute* - draft design and challenges
by SiNA Rabbani 08 Oct '13

08 Oct '13

Resending to tor-dev with correct email address. Sorry to those receiving 2 copies. On Oct 8, 2013 2:02 AM, "SiNA Rabbani" <sina(a)redteam.io> wrote: > Dear Team, > > I have started on a draft design document for Project cute. > Please let me have your kind comments and suggestions. > (https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute) > > All the best, > SiNA > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > "Cute" design and challenges - draft 0.1 > By: SiNA Rabbani - sina redteam io > > > *Overview* > > Project Cute is part of the Otter contract. This project is to provide > (in the parlance of our time) "point-click-publish" hidden services to > support > more effective documenting and analysis of information and evidence > documenting > of ongoing human rights violations and corresponding training and advocacy > Our > goal is to improve hidden services so that they're more awesome, and to > create > a packaged hidden-service blogging platform which is easy for users to run. > > *Objective* > > To make secure publishing available to activists who are not IT > professionals. > > *Activities* > > Tor offers Hidden Services, the ability to host web sites in the Tor > Network. > Deploying hidden services successfully requires the ability to configure a > server securely. Mistakes in setup can be used to unmask site admins and > the > location of the server. Automating this process will reduce user error. > We have to write "point-click-publish" plugins that work with existing > blogging > and micro-blogging software. > > *Expected results* > > The result will be a way to provide portals to submit text, pictures, and > video. > These sites will not have the ability to log information that can be used > to > track down citizen journalists or other users, and will be resistant to > distributed denial of service (DDoS) attacks. > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > *Introduction* > > This document describes the technical risks associated with running a > web-based > blog tool and exposing it over a hidden service (.onion address). Our goal > is to > create a packaged blogging platform that is easy to operate for the > non-technical user, while protecting the application from a set of known > attacks > that can reveal and compromise the network identity. > > Hidden-services make it possible for content providers and citizen > journalists to offer web-applications such as blogs and websites, hosted > completely behind a firewall (NAT Network) never revealing the public IP > of such > services. By design, Hidden Services are resilient to attacks such as > traffic > analysis and DDoS, therefore it becomes compelling for the adversary to > focus > on the application layer vulnerabilities. > > According to OWASP Top 10, Injection is the number one security risk for > web applications. "Injection flaws, such as SQL, OS, and LDAP injection > occur > when untrusted data is sent to an interpreter as part of a command or > query. > The attacker?s hostile data can trick the interpreter into executing > unintended commands or accessing data without proper authorization." [1] > > > Running a site such as WordPress involves a LAMP (Linux, Apache, Mysql, > PHP) > installation. This stack needs to be carefully configured and implemented > to > meet the desired privacy and security requirements. However, default > configuration files are not suitable for privacy and lead to the leakage of > identity. > > WordPress is the most popular blog platform on the Internet. We select > WordPress > due to it's popular and active core development. WordPress features a > plug-in > architecture and a template system, "Plugins can extend WordPress > to do almost anything you can imagine. In the directory you > can find, download, rate, and comment on all the best plugins the > WordPress community has to offer." http://wordpress.org/plugins/ > > Themes and plugins are mostly developed by programmers with little or no > security in mind. New code is easily added to the site without the need > for any > programming skills. This is recipe for disaster, a quick look at the > publicly > available plugin repository and security forums reveals many of the OWASP > top 10 > vulnerabilities such as XSS and injection vulnerabilities: > > http://packetstormsecurity.com/search/?q=wordpress > http://wordpress.org/plugins/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > *Adversary Model* > > We use the range of attacks available to the adversary adversary as the > base for > our Threat Model and proposed requirements. > > > *Adversary Goals* > > *Code Injection* > This is the most direct compromise that can take place; the > ability for > the adversary to execute code on the host machine is disastrous. > > *XSS the front-end, DoS the back-end* > The adversary can overwhelm the database backed or the web-server > of a > dynamically hosted application, denying access to the service. > > *Location/Identity information* > Applications that are not designed with privacy in mind tend to > reveal > information by default. For example, WordPress includes the name > of the > editor of a post inside the RSS feed: <dc:creator>John > Smith</dc:creator> > > *Adversary Capabilities - Positioning* > > The adversary can position themselves at a number of places to execute > their > attacks. > > *Local Network/ISP/Upstream Provider* > The attacker can hijack the DNS of the plugin repository or > perform a > man-in-the-middle attack and push malicious code into the blog. > > *Third party service providers* > It is common for a blog to email authentication information. > This information is at risk of social and legal attacks. > The repository of the blog's source code where themes and plugins > are > downloaded is a target for the adversary to insert malicious code. > > > *Adversary Capabilities - Attacks* > > The adversary can perform the following attacks in order to accomplish > varies > aspects of their goals. Most of these attacks are due to the dynamic and > Web 2.0 nature of blog platforms. > > *SQL Injection & XSS* > Dynamic sites take advantage of databases for content storage and > JavaSript for client-side presentation. Programming mistakes can > lead to > code injection on server or client side. > > *Inserting plugins or core updates* > Blog platforms have automatic update install features, WordPress > connects to a remote repositories to download updated code. > Adversary can perform a man-in-the-middle attack and insert > malicious > code. > > *Misbehaving plugins/features* > Some plugins depend on remote connections to provide a feature, > for e which can lead to leakage of identity. > > *Brute-force the admin password* > Weak passwords are vulnerable to brute-force attacks. > Blog engines do not provide protection against such attacks. > > *Remotely exploiting the LAMP stack* > A determined adversary has a very large attack surface to analyze > and discover 0-day vulnerabilities in Apache, PHP or Mysql > applications. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > *Proposed requirement* > > *Dynamic to Static* > A simple yet effective way to protect dynamic websites is to save > a 100% > static copy, hosted with a lightweight and well configured http > server. > We propose Nginx which is a free, open-source, high-performance > HTTP server. We have the option of extending existing WordPress > plugins > such as "Really-Static" (HTTP://wordpress.or/plugins/really-static/) to > generate 100% static files. > > *Disable Comments and New User signup (POST REQUESTS)* > The ability to receive and store comments involves actions and > configurations that expose the installation to DoS and other web > attacks. > We propose to completely disable reader's backed interactions, > specifically disabling New User Registration and Comment features. > > *SOCKS Proxy support for WordPress* > WordPress has the ability to proxy its outgoing connections, > however the > current implementation only supports HTTP proxy. We propose to > submit a > patch to WordPress core, enabling SOCKS Proxy support: > > http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php > > *Update safety* > Tor Project or a partner such as WordPress.org should maintain the > latest > copy of the WordPress source-code over a .onion address. This will > allow > for the Core application updates to take place without ever > leaving the > Tor network and we achieve end-to-end encryption without relying > on the > traditional SSL/CA model. > > *OnionPress plugin* > Instead of hard-coding our modifications to control WordPress' > functionalities, we propose to develop a custom plugin. > The plugin will provide a new menu in the Administrative panel of > the > site. Providing options to interact with Hidden Service features. > (Note that Administrative features are going to be restricted from > the public and only available to localhost) > > *User Authentication/Permission Levels* > > a) Blog Administrator > This person is hosting the blog on a local computer and > has physical > access to the installation. There is only 1 of such role. > This > login will be restricted to localhost only. > > b) Blog editors/contributors > These are the active content publishers. Each person has > the ability > to remotely connect, login and publish content. Editors do > not have > any administrative permissions such as adding or deleting > users. > Each editor is assigned a dedicated key and .onion > hostname using > the HidServAuth and HiddenServiceAuthorizeClient features > in > stealth mode. > > "HiddenServiceAuthorizeClient auth-type > client-name,client-name,… > If configured, the hidden service is accessible for > authorized > clients only. The auth-type can either be 'basic' for a > general-purpose authorization protocol or 'stealth' for a > less > scalable protocol that also hides service activity from > unauthorized clients. Only clients that are listed here are > authorized to access the hidden service. Valid client names > are 1 to 19 characters long and only use characters in > A-Za-z0-9+-_ (no spaces). If this option is set, the hidden > service is not accessible for clients without authorization > any more. Generated authorization data can be found in the > hostname file. Clients need to put this authorization data > in their configuration file using HidServAuth." > > c) Readers (the world) > These are the site visitors, they will be able to send GET > requests > to the .onion address and receive HTML and multimedia > content. > No login or comment posting permissions granted. > > *Packaged System* > > We propose to design and develop a Debian based Live OS that can > be started as a Virtual Machine or to boot a personal computer. > This OS > will include Tor, LAMP stack and a running copy of WordPress. > > The LAMP installation will be hardened and configured to meet our > security desires. We require a secondary USB disk for persistent > storage. > Desired outcome is a point-and-click and maybe portable solution > that > can be launched from inside of Windows, Linux or Mac OSX. > > VirtualBox is a second candidate to host the VM. > http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/ > > > *Edge Cache Nodes* > > In order to provide "blazing-fast" access to the published content > outside of the Tor network, we propose the deployment of caching > servers > operated by semi-trusted third party organizations or persons. > These are > similar to tor2web nodes:http://tor2web.or/ > > The content providers (bloggers) would select from a list of > available > edge servers and send a pgp signed zip file of the latest static > version > over Tor. Edge servers will reduce traffic from the Tor network, > also > provide a chance for content to reach the world in case of a DDoS > or > technical issues with the Tor network itself. > > Having cached copies available remotely make it possible for the > blogger > to get on-line, publish content and go back off-line, minimizing > the > amount of time and traffic spent on the Internet. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >

1 0

Attentive Otter: Analysis of libpurple
by Thijs Alkemade 07 Oct '13

07 Oct '13

Hello! Here is the analysis of libpurple/Pidgin as a candidate for the Attentive Otter project, written by DrWhax and me. Best regards, Thijs (xnyhps) ----- ## Intro Pidgin is an IM client written in C using a GTK+ UI. libpurple is the library used by Pidgin as an abstraction for the different network protocols Pidgin supports. libpurple comes with a number of plugins ("prpls") for the various chat networks it supports. Other UIs using libpurple include Adium (Cocoa), Finch (GNT) and Quail (Qt, in development). ## Release a secure, portable chat program ### Secure Number of security advisories published on https://pidgin.im/news/security/ since 2005-06-10: * libpurple: 6 * nss plugin: 1 * Pidgin: 3 * prpl-gg: 1 * prpl-irc: 2 * prpl-jabber: 7 * prpl-msn: 15 * prpl-mxit: 3 * prpl-oscar (AIM/ICQ): 6 * prpl-qq: (no longer supported) 1 * prpl-sametime: 1 * prpl-silc: 2 * prpl-yahoo: 3 My (xnyhps) personal experience is that the Pidgin developers take reported security issues very seriously and often come up with a fix quickly. However, it does sometimes take a while before they release and deploy that fix. I don't have enough experience with Pidgin (the GTK+ UI) to judge its code quality, but I think the quality of libpurple itself is decent. The quality of prpls varies a lot, generally the reverse-engineered protocols are in worse shape than those with open specifications. I think MSN is definitely the worst and auditing it would take more time than the servers will be online for (until March 2014). I think auditing jabber+irc should be doable and would be a good start: IRC is quite small (>5kloc), XMPP (28kloc) has clear specifications and by using UTF-8 and XML it removes a lot of possible buffer overflow and string manipulation vulnerabilities. DrWhax's personal experience is that Pidgin developers don't always take security issues seriously. In the summer of 2012 I spent a night digging with Jake into the source code and DLL's that they ship and we found out that in 2012, they were shipping vulnerable DLL's with the oldest exploit originating from 2006! It took quite some convincing that this is a serious matter and we had to convince(sigh) the Pidgin folks to update all the DLL's to the latest version. In February 2013, Pidgin finally released a security update which fixed 12 security bugs? I would say, if we would want to go forward with releasing a minimal Pidgin, we should only ship with IRC and XMPP support. ### Portable Pidgin provides official instructions on how to run Pidgin from an USB stick: https://developer.pidgin.im/wiki/Using%20Pidgin#RunningWindowsPidginFromaUS…. ## Sends all traffic over Tor libpurple has a proxy setting that will force all traffic to pass through Tor. This disables all SRV lookups, meaning many XMPP servers require manual configuration to work. UPnP (used for automatic port fowarding and external IP detection) can be disabled globally. ## Can be used with a wide variety of chat networks libpurple includes support for: * AIM * Bonjour * Gadu-Gadu * Google Talk * Groupwise * ICQ * IRC * MSN * MXit * MySpaceIM * SILC * SIMPLE * Sametime * XMPP * Yahoo! * Zephyr Though nearly everyone of these is a separate prpl, so would require its own auditing. ## Uses off-the-record encryption of conversations by default The Pidgin-OTR plugin can be configured to enable OTR by default. Including this plugin with Pidgin by default is underway. ## Has an easy-to-use graphical user interface localized into Farsi, French, Spanish, and Arabic. It has a graphical user interface which a large number of users might already be familiar with. From https://developer.pidgin.im/l10n/2.x.y/: * Farsi: 59.77% finished. * French: 98.95% finished. * Spanish: 99.31% finished. * Arabic: 78.02% finished. This breakdown includes all prpls, so might turn out differently when only including a subset of them. ## Cross-platform support Pidgin ships binaries for Windows and Linux. By packaging GTK+, it should be possible to package it to run on OSX too, though the UI would be quite confusing to many OSX users. Another option on OS X is Adium, though this increases the amount of code to be audited by a large factor. ## Integration with Tor libpurple supports plugins written in C, Tcl, Perl and C# (Mono). These can make changes to the preferences to automate configuring it for Tor. It is also possible to configure Pidgin using D-Bus, but for security reasons it is probably wiser to disable D-Bus support. So the options to control Tor are: * A C/Tcl/Perl/C# plugin that launches a Tor process and which sets up Pidgin's preferences accordingly. * Use Tor Launcher from the TBB to start both Tor and Pidgin. Configuring Pidgin could happen by: * Writing to the preference files before starting it. * Communicating the preference changes to a simple C/Tcl/Perl/C# plugin. * D-Bus. (Unlikely to work on Windows and difficult to secure) ## Pidgin 3.0 Pidgin 3.0.x will be released with OTR support by default, which is awesome, only one codebase has to be maintained in the various Linux distributions and Windows clients! Huzzay! Something i'm less happy with, is that the Pidgin developers started using Webkit for HTML rendering within the client. Webkit doesn't have a very good security history and opens up with another giant security hole. If we would want to release Pidgin inside of TIMBB, I would propose to work on Pidgin 3.0 and not the older 2.x releases.

1 0