Tor Instant Messaging Bundle
trac.torproject.org
trac.torproject.org
It makes little sense to me to pick up and move to another platform and product because it's written in JavaScript. The remaining bullet points in this wiki page appear to be fixable with a lot less directed effort than adopting and drastically changing an unpopular application.
[1] https://blog.wasilczyk.pl/en/2013/google-donates-pidgin-to-i... [2] http://pidgin.im/news/security/
i was assuming this would be some sort of xulrunner app(for some reason a non native chat client strikes me odd for some reason, but meh). it's actually an old seamonkey "fork" from what i gather, but i'm not sure if that's still the case.
can someone comment on why a browser is more desirable? i'm guessing it's, because of random bugs appearing where dns or other things may be leaked, and crossplatform support.[3]
i'm starting to think that the "right"(there i said it) way to deal with all this is if we follow with the portal approach[4](someone had a debian version, feel free to post the link). but instead of running portal on a seperate device it'll be a container in a container(or light vm). that way the outer container(vm) is the sandbox(portal), then you can run whatever app you want. and yes, i really what i propose is a major pain in the ass to setup, and won't work in windows that well, but meh i don't see why we couldn't make it easier. the main issue in my opinion would really be the privileges it might need.
[1]: https://wiki.instantbird.org/Instantbird:related_links#Thing...
[2]: https://hg.instantbird.org/
The setup that you describe is actually implemented in Whonix [3], and personally I don't like it that much. I don't believe that VMs are very secure. I prefer the TAILS [4] system for a hardened Linux as a baseline, but it doesn't even use a VM to segregate the Tor daemon from the main OS. A superior hardened system (from a security POV) is Liberte Linux [5], however development is stalled and it is more complex to setup and use than TAILS. (Worth noting that TAILS is sponsored and has development resources, everything else is just a side project for various people).
If you want to setup a PORTAL that runs in a vm, it is really simple to do. QEMU will run the OpenWRT based PORTAL image, although someone would have to figure out how to configure the network settings appropriately. You'll probably want to use a VM for the "workstation" environment, as well as a VM for the Tor daemon. This will give you maximum control over the networking (this is what Whonix does).
At any rate, I suspect that JITSI is a better client than pidgin, but it gets no love (and unfortunately, it is Java). pidgin is basically technical debt which can never be repaid. Parsing network protocols in ad hoc parsers written in C is just not rational in this day and age. A client should use a managed language to minimise memory corruption bugs. I don't think using xulrunner is a good idea either, given how terrible Firefox is at security.
Ideally, there would be work put into making Pond [6] a viable instant message application.
I'd also be happy if the OTR spec was updated to bring it inline with the new TextSecure v2 protocol.
[1]: http://grugq.github.io/blog/2013/10/05/thru-a-portal-darkly/
[2]: http://learn.adafruit.com/onion-pi/overview
A minimum Debian is grml [1], 150-350MB, which Whonix uses as a base.
But by the time we're done adding packages and KDE, it's not minimal anymore. We use a popular GNU/Linux distro (instead of, say, hardened gentoo) because 1) Lots of eyes on a bigger project is more secure than few eyes on a smaller project, and 2) Bad or missing usability/UX hurts security: these systems are used by journalists and dissidents, not the Unix and computer security trained. The trick is making a system that moderately educated users can get work done on, without letting them shoot themselves in the foot.
VMs have their problems, but VirtualBox inside an average Windows install is harder to exploit than an average Windows install alone. Whonix can also run on dedicated hardware or inside a dedicated/minimal/portable host OS. Running inside QubesOS, the Xen-based (everything is isolated) security focused desktop OS, is a mid-term goal.
Additionally, as resources (that is, volunteers) grow, builds of Whonix based on other distros/desktops/hardware will appear. To see you post on our forum [2] or github issues [3], lending your experience with PORTAL, would be a dream! Let's talk stream isolation. Or just voice your concerns and we'll try to defend our choices.
---
Ditto on Pond, which is weird since Appelbaum is behind it, but apparently they don't want to start from scratch (Pond was just a README last time I checked).
I have big hopes for TIMB, BitMessage, and the new (crossplatform) TextSecure. Hopefully redphone will receive the same treatment as TextSecure. Me and the lead Whonix developer tried to set up a crossplatform secure voice chat over Jitsi... an hour later we gave up.
Icebird + TorBirdy is just barely becoming a reality. A GPG capable email client that doesn't give away your time zone is big news in this world. Don't get me started on losing all your bookmarks when you update the tor browser bundle! We got a long way to go.
[1]: https://grml.org/ [2]: https://www.whonix.org/forum/index.php?board=5.0 [3]: https://github.com/Whonix/Whonix/issues
A hardened Gentoo is a more solid platform because of the reliability of GRsec + PaX for exploit mitigation. Unfortunately, configuring GRsec to work generically for a large number of usecases would be time consuming. I would still like to see it though.
There is an option on how to do it properly, but so far I don't believe that anyone is working on making it available publicly. I know it has been done in private at least twice but neither implementation is likely to become public. I would very much like it to be public. :(
If you are interested, it is a viable business, but I personally don't have the time to put into it.
I really don't like VirtualBox. I think Xen, KVM, VMware are all superior options.
I have never been able to get Qubes to install on any of my computers. It just fails. I guess I have the wrong hardware. I think it is sort of the correct approach, but there is a much better way. Email me if you want to devote some time to "doing it right". Would be in line with Whonix/Qubes, but different. :)
I gave up on Jitsi fairly quickly(this from a person that wrote actually hacked together a proof of concept skypekit plugin for pidgin). It's slow, it randomly locks up for no apparent reason, and well as you said, it's java. So I went back to pidgin.
You're absolutely right about pidgin and it's technical debt though. The only way it can be repaid is by a complete rewrite. I'm still holding my breath for stable gui bindings, and a 1.0 rust release.
what you're saying about vm's and containers about security is true, yes. But it's not about security. It's about leaking information, and comfort. The tor browser bundle is all about comfort, and being "safe enough". If you're rooted it neither tor browser bundle, nor tor chat bundle will help you. The reason I brought this up is because i think in theory it should be possible to make a bundle that allows you to run desktop apps inside of that vm/container setup with a fully configured pf tables setup so that particular instances connection will fully go through the parents tor node
Pond looks interesting, but i'm still a little of split opinion whether things that later target end user desktop application should ultimately be written in go.
https://rednerd.com/2013/12/07/portal-for-debian/
As is mentioned above, I think the way to do this in a VM is to emulate OpenWRT in qemu.
There is an issue for the torrc that is open on github, but it hasn't been applied yet. You might want to test it and see if it works for you.
Pond is a sort of email replacement. I prefer it for security reasons. It protects against traffic analysis.
[0] https://github.com/agl/pond/commit/338395668fbb8a7819c0fccf5...
My main point, really, is that the content is not that relevant most of the time. It is far more interesting to see who is talking to whom, how frequently, and for how long. This sort of data provides rich information on the target network, both the edges and the nodes. This information can be used to analyze the network and to fit people back into the network if their identifying device/ID/etc is changed. You can still match the new activity against the old activity (particularly if the old activity has ceased) and get a match on who the "new" node actually is.
The metadata masking of Pond is what I like. It makes it a much more secure system than an XMPP based IM network. Even a private XMPP server is not secure against a global passive adversary. And thats basically the important thing for me. TextSecure is fine, but it leaks too much information for me to be completely comfortable using it. Pond addresses those issues (although, unfortunately, it fails on the usability front).
Thanks for the correction.
I have no actual knowledge of why Tor picked Instantbird over Pidgin; idle speculation says they're already stuck with Firefox anyway (TBB), so the additional risk from JavaScript-based instant messaging protocols isn't high. I do not believe Instantbird supports DNS SRV at all at this point, and it just uses the same infrastructure Mozilla uses for browsing to make connections, so presumably that's already safe.
(Bias warning: I hang out in Instantbird's IRC channel and have made a patch or two. I don't think any of the above would change otherwise, though.)
Tor provides Anonimity first. Security is a by-product.
Apparently the decision was made at a meeting last month[1], but I can't find much discussion on it, even on the mailing lists.
[1]: https://trac.torproject.org/projects/tor/wiki/org/meetings/2...
I would say, yes it is more secure.
As for OpenSSL, better ask advice to Apple developers. They know all about how C helps security experts keep their jobs.
This means that a lot more eyeball-power went into inspecting those for security issues than into inspecting a messenger - simple reason: a bug in V8/xMonkey would fetch far, far bigger reps and money than finding a bug in Pidgin.
Always remember: given enough eyeballs all bugs are shallow.
Though it doesn't fit the specification of the linked project as it uses its own custom protocol based around Tor hidden services, rather than implementing XMPP, Twitter, Facebook messenger, etc. This may be more secure as it is keeping everything within Tor rather than using exit nodes, but perhaps less usable if everyone else you know is using more popular IM software.
> Audit the Pidgin chat client, fixing security bugs
And
> we don't want to use Pidgin/libpurple
> It also includes outreach, especially towards Iranians.
[1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/O...
[2]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/O...
Originally sponsored by the U.S. Naval Research Laboratory,[11] which had been instrumental in the early development of onion routing under the aegis of DARPA, Tor was financially supported by the Electronic Frontier Foundation from 2004 to 2005.[13] Tor software is now developed by the Tor Project, which has been a 501(c)(3) research-education nonprofit organization [14] based in the United States of America [1] since December 2006. It has a diverse base of financial support;[13] the U.S. State Department, the Broadcasting Board of Governors, and the National Science Foundation are major contributors.[15] As of 2012, 80% of the Tor Project's $2M annual budget comes from the United States government, with the Swedish government and other organizations providing the rest,[16] including NGOs and thousands of individual sponsors.[17] One of the founders of the project, Roger Dingledine, stated that the DoD funds are less similar to being a procurement contract and are more simiar to a research grant. Andrew Lewman, the executive director of the Tor project, stated that even though it accepts funds from the U.S. federal government, the Tor service did not necessarily collaborate with the NSA to reveal identities of users.[18]