Integrate Cryptocat Browser Extension into Tor Browser

added component::applications/tor browser new-addon owner::tbb-team priority::medium reporter::kaepora resolution::wontfix severity::normal status::closed type::enhancement labels

Trac:
Username: kaepora
Component: TorBrowserButton to Tor bundles/installation
Owner: mikeperry to erinn

I'm curious to hear Mike's opinion here.

Trac:
Cc: N/A to strangecharm

I'd also like to know more about code and protocol review. WRT the protocol(s), there's some spec material on the website, and some in the source distribution, but none of it seems to provide enough detail to reimplement a compatible version of the protocol.

The cryptographic information appears to do cryptography in javascript; that can get pretty scary. Quality-of-implementation appears less than what we'd accept for new cryptography in Tor proper: for example, the Curve25519 implementation here does nothing to avoid timing attacks.

(The above is not to say that no version of anything called cryptocat should ever IMO go in TBB, but rather that I think there could be more work to do, perhaps.)

It appears that none of our primitives are even slightly constant time. But in response to this I must ask: How likely is it that timing attacks will be a danger in this context?

I am inclined to believe it to be unlikely: The ciphertext will be sent and received from different browser versions, run on different operating systems using different hardware. The risk of precisely consistent timing is extremely minimal. Furthermore, the nature of the software design makes it difficult for this sort of attack to be relevant. _Note: If I'm saying something wrong here, please correct me; I am not an expert on timing attacks! _

Per our discussion on IRC, I am going to work up some more documentation regarding our protocol and software design, but I am just wondering whether timing attacks are worth being a blocking issue here at all. What are your thoughts?

Trac:
Username: kaepora

I also think that timing attack vulnerabilities maybe something very difficult to exploit, or in a specific context not exploitable.

So, given that javascrypt crypto primitives may have has such a behaviour, i am wondering how we can workaround that possible behaviour within the crypto protocol.

What if we try to mitigate further exploitability of possibly present timing related vulnerability by introducing a "time padding".

The adversary can only look "at the network", so the adversary would not be able to "sense" for possible timing squeeze on crypto, if all packets sent are scheduled to be sent at a specific time interval.

Let's say that "each packets sent during the key negotiation/handshake" will be sent "rounded to the next 1 second, at the end of the next one second.

That way the attackers should not be able to correlate anything related to timing, because on possibly timing sensitive cryptographic operation, we applied a "time pad".

What do you think?

-naif

p.s. Along with CryptoCat, to make it available with TBB via TorHS, let's consider also the "Comfort loader" to increase usability https://trac.torproject.org/projects/tor/ticket/7046

Replying to kaepora:

It appears that none of our primitives are even slightly constant time. But in response to this I must ask: How likely is it that timing attacks will be a danger in this context?

Like I explained last night, I think this might be motivated reasoning.

If you had a high-quality side-channel-free implementation of your various crypto primitives, you wouldn't be making this argument. You'd just be saying "We have a high-quality implementation of our primitives; we don't need to worry about it!" I think that if you knew how to get a high-quality side-channel-free implementation of your various crypto operations, you would just switch to it, right?

I am inclined to believe it to be unlikely: The ciphertext will be sent and received from different browser versions, run on different operating systems using different hardware. The risk of precisely consistent timing is extremely minimal. Furthermore, the nature of the software design makes it difficult for this sort of attack to be relevant. _Note: If I'm saying something wrong here, please correct me; I am not an expert on timing attacks! _

This is what absolutely everybody says, before they get hit with timing side-channels.

I can't analyze your protocol, because I don't know what the protocol is, because of the holes in the documentation. But if there is any case where one computer does something in response to another computer doing something -- for example, a handshake getting answered with a handshake -- then you need to be concerned about this. Even if one browser is not vulnerable, another might be. Even if all the desktop browsers you test aren't vulnerable, you would need to analyze low-resource situations, like smartphones and whatnot. Even if you try to exploit and you can't, that wouldn't prove that no exploit is possible.

So: Please care!

Per our discussion on IRC, I am going to work up some more documentation regarding our protocol and software design, but I am just wondering whether timing attacks are worth being a blocking issue here at all. What are your thoughts?

I agree with nickm and think non-constant time issues are concerning. Generally timing is considered "hard to exploit" but realistically, very few people that think it hard are actually doing the attacks.

Is it a lot of trouble to make it constant time? It seems reasonable to try.

Replying to kaepora:

Cryptocat is a browser extension available for Firefox that provides an in-browser XMPP client capable of handling Off-the-Record encrypted conversations as well as multi-party encrypted conversations. Cryptocat is free software, implements open standards and is developed by the Cryptocat Project (https://project.crypto.cat). It has been rigorously tested for compatibility with the Tor Browser bundle under Windows, Linux and Mac.

What tests were done? What kind of stuff are you testing or trying to assert?

I believe Cryptocat should be integrated into the Tor Browser Bundle for the following reasons:

Cryptocat can offer integrated OTR encrypted messaging immediately to anyone who downloads the Tor Browser Bundle.

How does it work? Does it connect to crypto.cat? Or to another server? Or a list of servers?

Cryptocat is easy to use and is translated to more than 22 languages. It provides an accessible alternative that is likely to encourage Tor Browser Bundle users to avoid risking their anonymity, by using Cryptocat (OTR over Tor/HTTPS) instead of Facebook Chat or Google Talk (Plaintext over Tor/Uncertain HTTPS).

Both Facebook and Google Talk use HTTPS in the Tor Browser as we ship HTTPS-Everywhere.

Cryptocat's inclusion into the Tor Browser Bundle benefits Tor users and Tor developers by bundling a one-click access to private Instant Messaging. It is likely to shift Tor Browser Bundle users from using untrustworthy, commercial services to using a free software platform which has privacy as a priority and a history of responsible responsiveness to feedback.

But what service will they use now? Will this mean all TBB users will join chats on your server?

Replying to ioerror:

Replying to kaepora:

Cryptocat is a browser extension available for Firefox that provides an in-browser XMPP client capable of handling Off-the-Record encrypted conversations as well as multi-party encrypted conversations. Cryptocat is free software, implements open standards and is developed by the Cryptocat Project (https://project.crypto.cat). It has been rigorously tested for compatibility with the Tor Browser bundle under Windows, Linux and Mac.

What tests were done? What kind of stuff are you testing or trying to assert?

I simply got together with a friend and we had conversations on Cryptocat over TBB on Windows, Mac and Linux. We tried conversations with up to 5 participants, private messaging, and checked to see what happened if a TBB idled for about an hour. Performance was good on all accounts, if sometimes slow.

What I'm trying to assert is that Cryptocat seems to work reliably over the Tor network for the standard end-user.

I believe Cryptocat should be integrated into the Tor Browser Bundle for the following reasons:

Cryptocat can offer integrated OTR encrypted messaging immediately to anyone who downloads the Tor Browser Bundle.

How does it work? Does it connect to crypto.cat? Or to another server? Or a list of servers?

By default it connects to the XMPP-BOSH server at crypto.cat. However, Cryptocat supports custom servers (easily changeable in the client's login screen), and we even provide instructions on how to set up your own XMPP-BOSH server for Cryptocat at our wiki: https://github.com/kaepora/cryptocat/wiki/Server-Deployment-Instructions

Cryptocat is easy to use and is translated to more than 22 languages. It provides an accessible alternative that is likely to encourage Tor Browser Bundle users to avoid risking their anonymity, by using Cryptocat (OTR over Tor/HTTPS) instead of Facebook Chat or Google Talk (Plaintext over Tor/Uncertain HTTPS).

Both Facebook and Google Talk use HTTPS in the Tor Browser as we ship HTTPS-Everywhere.

I guess that is true.

Cryptocat's inclusion into the Tor Browser Bundle benefits Tor users and Tor developers by bundling a one-click access to private Instant Messaging. It is likely to shift Tor Browser Bundle users from using untrustworthy, commercial services to using a free software platform which has privacy as a priority and a history of responsible responsiveness to feedback.

But what service will they use now? Will this mean all TBB users will join chats on your server?

That's a bit hyperbolic - TBB users will be given the option to use Cryptocat to either use Cryptocat's default server or specify any custom server they wish. They are also still capable of using other services such as Google Talk.

Let's keep the conversation going - I am excited about satisfying your questions and making progress on this issue! :-)

Trac:
Username: kaepora

My initial thoughts here are:

This is a totally awesome idea. I think it becomes even more awesome if it either shipped with or contained an XMPP server that gets automatically configured as a hidden service (#6660 (closed)).
In fact, if we can easily do XMPP over fully P2P hidden services (where each user gets their own hidden service), the timing issues with OTR become secondary, as OTR would be largely redundant in that case.
We need to audit this for XUL XSS issues, especially since it is displaying remote-provided content (chat messages) in XUL windows. Has anyone done this audit yet? I assume the AMO reviewers have, but who knows how competent they are for this stuff. There are several people around the net that may be even more qualified reviewers than I am, in fact. There have been a few BlackHat/DEFCON/other presentations on this topic.
It seems to use jsctypes. Is this dependency strictly necessary, or can we do without it?
I'm pretty sure Pidgin is a security nightmare on Windows, and their devs seem to take a rather lax attitude to such problems. It likely has way worse vulnerabilities than timing attacks in the crypto... But CryptoCat could be worse in terms of exploit, because XUL XSS exploits are way easier to use (and cross-platform!) if they exist...

Ugh. The everybody-gets-an-XMPP-server ticket is #6600 (closed), not #6660 (closed). The main thing that buys us is not revealing your social network to a centralized XMPP server (this reduces the risk of targeted attacks, DoS attacks, and deanonymization through social network analysis).

Oh, also, I think this extension is something that might make more sense in Thunderbird. It's great that it could exist in the browser, but secure instant messaging is more like something you'd expect from a mail client than a web browser.

Replying to mikeperry:

Oh, also, I think this extension is something that might make more sense in Thunderbird. It's great that it could exist in the browser, but secure instant messaging is more like something you'd expect from a mail client than a web browser.

Really? Everybody does their gtalk messaging with a browser these days, don't they? A mail client has nothing to do with interactive messaging in my world.

Hey guys,

We recently received the results of our first full audit (completed by Mario Heindrich's team) and we've been busy fixing the bugs he's discovered. We've fixed around a dozen bugs (including a couple of critical ones!) so that was a really great audit and Cryptocat is in a much better situation right now.

I'm really glad to see that you guys think it's a good idea to try out Cryptocat integration. Our code certainly needs every bit of auditing it can get; we're still beta software and if you want to audit it some more before including it in something like Tor then by all means please do so.

Overall, and once Cryptocat is verified to your satisfaction, I believe it would be a good alternative to web-based chat services such as Facebook Chat - however, we need to be clear on it not being a replacement to PGP and the like.

I also wonder if Cryptocat would be bundled with TAILS.

mikeperry: Yes, jsctypes is necessary so we can access nsslib for secure random number generation in Firefox. Chrome and Safari support window.crypto.getRandomValues() so we don't need to do that there, but it's been a total nightmare to get that implemented in Firefox and we'll need to use jsctypes until it does get implemented.

We're also working on Thunderbird integration anyway: !https://github.com/cryptocat/cryptocat/issues/144

Trac:
Username: kaepora

Personally, I would still say "wait".

The bugs that the audit found are not the kind of thing that makes me go "ah, well, I suppose that everything is okay now that those are found and fixed." They're the kind that make me think that there are probably more issues we didn't spot; we should let cryptocat become more mature before we think of endorsing it.

Replying to nickm:

Personally, I would still say "wait".

The bugs that the audit found are not the kind of thing that makes me go "ah, well, I suppose that everything is okay now that those are found and fixed." They're the kind that make me think that there are probably more issues we didn't spot; we should let cryptocat become more mature before we think of endorsing it.

I agree with you completely. It would help if you could come up with a laundry list of what we need to focus on. Otherwise, I still believe you are right. I am also for the opinion of waiting for Cryptocat to mature before including it in the TBB, but I am also looking for advice on how to mature and also a criteria of what the Tor Project would consider a "mature" Cryptocat.

Trac:
Username: kaepora

kaepora: Is there a tag in your bugtracker so we can look over the bugs found as a result of the audit?

Also, if NSS is only used as a source of random bytes, you should consider using https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIRandomGenerator. It uses NSS's PRNG underneath. The reason to avoid jsctypes is because it increases the vulnerability surface for sandboxed TBBs. We're pondering removing it if we ever get a working sandbox (see #6152 (moved)).

Integrate Cryptocat Browser Extension into Tor Browser

Child items ...

Activity