[liberationtech] An interesting anonymous chat project: Invisible.im

[carlo von lynX]

On Thu, Jul 10, 2014 at 04:24:38PM +0200, Piotr Chmielnicki wrote:
> On 07/10/2014 04:06 PM, hellekin wrote:
> > On 07/10/2014 10:38 AM, Keira Cran wrote:
> >> Invisible.im (http://invisible.im) is a really interesting project
> >> leveraging Tor to provide anonymous chat. It takes a fascinating
> >> approach using Tor hidden services, but is yet to be released to the
> >> public.

Fascinating. TorChat has been doing that, too.

The fact that it tries to establish Tor circuits to every other
participant doesn't make it terrifically scalable. "Federation"
over XMPP doesn't change much of anything about that. I started
putting Tor federation into psyced a year ago, thinking that it
would be better than nothing.. but for some detail it didn't work
and I really should focus on secushare as the long term solution
anyway. PSYC would be more appropriate as a wire protocol than
XMPP for reasons as simple as binary file transfers being possible
to reasons as complex as...

    "For some inexplicable reason the first few messages in a chat session just disappear into the ether."

XEP-0190 also shows that XMPP doesn't have a terrific track
record for secure delivery. The XEP has been deprecated, yet
several server implementations still close sockets the wrong
way. There is a XEP that puts acknowledgments on top of XMPP,
but you have to make sure your code actually uses that in
order to not lose messages.

    "It's entirely possible and very easy to spoof a hidden service address when launching an out-bound connection from a locally-hosted XMPP service. The XMPP service accepting the inbound connection will do nothing to verify the source of that connection, thus spoofing is a real risk. This is why we'll be forcing OTR for all chat sessions."

That sounds like *totally* a problem with XMPP or some wrong
use of it. PSYC over Tor federates with no dependency on OTR
whatsoever. Tor hidden services are self-authenticating and
forward secret. The choice of encryption strength is sufficient
for mass communications I believe - if not, I would rather
upgrade Tor. Thus, chatting is as simple as using any IRC
client and all the auth you need is to get the onion address
right. OTR usability inferno is entirely optional.

    "It must also be noted that the presence of identifying OTR key material on the source's system may be a liability. [..] This is why we generate one-time, ephemeral OTR keys in anonymous mode."

I must have misunderstood, but it doesn't make sense to me that
some bug in XMPP authentication is circumvented by OTR, yet the
OTR is not used for authentication. And even without identifying
OTR key material there is still identifying onion address material
on each computer - so that is a threat that can't really be solved 
this way. Pond goes as far as one can get, methinks, concerning this.
The social graph has to be somewhere, after all... Pond encrypts the
address book and does some mumbo jumbo with TPM. I personally think
all computers should use full disk encryption and that it is
pointless to invest energy in keeping some data encrypted if the
entire OS is still easily accessible and can thus break your trust
the next time you decide to input some extra safe part's pass phrase.

> > *** It sounds like the approach taken by Ciboulette [0], to run local
> > hidden services and federate them.  Although I like the approach, I have
> > the intuition it's too much effort put on the user: while we're at the

Ah, using prosody. Means having lua on each participant's computer.

> > point of installing servers locally to mimic P2P services, why not focus
> > the effort on advancing GNUnet services directly?
> >
> > The obvious advantage of GNUnet is that it's not just for chat, but
> > provides a complete infrastructure ranging from an alternate to DNS, to
> > HTTP transport, etc. [1]

Yes, but there's more to it:

    "Initial conversations with people who know a lot more about Tor than us suggest that hidden services don't really scale that well."

GNUnet would not make circuits to each and every other participant
but rather create mesh nets. secushare puts multicast trees on top
of that for large size channels, so there is a realistic/scientific
perspective of obtaining a system that is both anonymizing and
scalable.

As a side effect you also get file exchange, a telephony prototype
and a few other nifty things... and you get rid of legacy code
dependencies such as X.509 and DNS.

> XMPP over hidden services could be a good compromise between
> anonymity/security and usability. A non-tech user could just use a
> server he trusts. Organizations could provide trusted servers for
> internal or public use.

That is not the scenario that invisible.im suggests, as I understood -
also because in that case you *do* need OTR for end-to-end auth and
because doing "regular" federation will always lead to very popular
servers which then turn into honeypots for attack.

So I say, no, that wouldn't be such a huge progress from the current
situation. I think that's also what invisible.im criticizes in the
answer to "Aren't tools like this already being developed?"

> If a server is compromised, risks can be limited if users have good
> OPSEC habits (different coverts identities and so on ...) and use
> end-to-and encryption.

Hardly anyone has good OPSEC habits, like having multiple identities
spread over several servers, making group chats even more complicated,
and corelating all the accounts by your coming-online-all-at-once
habits anyway... and ultimately putting stress on the Tor network in
a slightly different fashion...

> Running a .onion on a machine that is not running all the time (like a
> laptop) like with Torchat or Cables could be risky because of the uptime
> monitoring of the hidden service.

Could make sense to decouple the hidden service DHT operations from the
boot and shutdown procedures of the Tor node as such, in order to reduce
the chances of correlation. But maybe this is already being done - didn't
look into the details of hidden service implementation.


-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet