TorChat is a security hazard (Answer)

[Bernd Kreuss <prof7bit@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I found this message from February in the archives and since the
original message ID is hidden I cannot write a follow up, so I start a
new thread to comment on the topic:

Original Message from Paul Campbell, Tue, 23 Feb 2010 19:38:50 -0800
> 
> Hello.
> 
> I'm in no way a security expert.  I never ran "TorChat" but I did read the 
> source code. Read on why I haven't run it.
> 
> "TorChat" is an inofficial chat client for the Tor network.  I like the idea 
> behind "TorChat": easy to use, usb-stick portable and runs on Windows 98.
> 
> These are the problems I see with "TorChat":
> 
> 1. No authentication.  There is no way you can know for sure that the person 
> you are chatting with is the person you chatted with yesterday.  Tor's hidden 
> services don't make any such guarantees about incoming connections. The clients 
> stay anonymous.
> 
> 2. To make things even worse, the only information needed to impersonate a 
> buddy is their .onion address.
> 
> 3. Buddies have control over your buddylist.  It is just a matter of 
> identifying as a buddy and telling the software to remove this said buddy.
> 
> I don't think these are the only problems, but the first one alone is enough to 
> conclude that "TorChat" cannot give adequate security.  It's too easy to 
> impersonate people.  "TorChat" lives off the name of the Tor Project, but 
> unfortunately doesn't deliver.
> 
> It is possible to run Off-the-Record Messaging over Tor.  Off-the-Record 
> Messaging has all kinds of features: encryption, perfect forward secrecy and 
> deniable authentication.  And it doesn't have the problems of "TorChat".
> 
> Best regards,
> Paul

I am the original developer of TorChat and I feel the need to comment
the above message. Point 1 is about the supposedly missing
authentication and points 2 and 3 are direct consequences of point 1.

I did not yet write any paper that explains the protocol in detail, it
is all "hidden" in the source and in the source code documentation of
the message classes. I will now try to explain how it works.

> 1. No authentication.

This is not true. There is authentication, the incoming connection must
prove that it is reachable under the .onion address it pretends to be by
correctly answering pings with random numbers that are sent to this
address. The connection procedure is as follows:

* client A will connect the hidden service of client B
* after successful TCP connection to B it will send its own hidden
service ID (its onion address) to client B along with a ping message
containing a random number.
* client B will now try to connect back to the (still untrusted) address
given to him in this (still anonymous) incoming connection.
* after successful TCP connection it will also send its own address to A
along with a ping message and also the pong to A's ping message.

* A will receive the pong on the incoming connection for the ping it has
sent over the outgoing connection and now knows that the incoming
connection undoubtedly belongs to the outgoing connection to B. It will
then also answer the ping from B

* B will receive the pong to the ping that it has sent and also know
that this incoming connection undoubtedly belongs to A

At this point each client has an outgoing connection that they opened
themselves (trusted by definition) and an incoming connection that has
been authenticated by the fact that a random number sent on the trusted
out connection has been correctly answered on the incoming connection.

Every incoming connection that cannot be called back at the address it
pretends to originate from and that will not reply with a pong to the
ping that is then sent on the corresponding outgoing connection will be
ignored and closed.

For the buddy icon to become green and any messaging, status- or command
messages to be allowed there *must* exist one outgoing and one incoming
connection for it and they must have fully completed at least one round
trip of ping (sent to the outgoing connection) and corresponding pong
(received from the incoming connection).

This system is of course only as secure as the private hidden-service
keys (and their onion addresses) are. Trying to impersonate a TorChat ID
is *equivalent* to trying to impersonate a hidden service. If you want
to pretend that you are abcdefghijklmnop.onion in TorChat you must also
prove that you are able to receive incoming connections for that address.

> 2. the only information needed to impersonate a buddy
> is their .onion address.

As explained above: If you simply connect a TorChat client and pretend
to be this faked address it will not trust you until you answer the ping
message and the ping message will be sent over the callback connection.
You need to be reachable for incoming connections under this address,
you need to impersonate the hidden-service itself.

> 3. Buddies have control over your buddylist.  It is just
> a matter of identifying as a buddy and telling the software
> to remove this said buddy.

Buddies only control their own entry in the list, they can only remove
themselves from the list and as explained above for any command message
to be accepted they must first be authenticated by proving that they
actually *run* the hidden-service with this name.

It might not be impossible to impersonate a hidden-service address (has
this been done already, are there estimates of the needed computing
power?), but it is certainly not as easy as it might sound from reading
your analysis.

Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNA8l6xT6R4jlFoh0RAlBQAKCSAX7wtO1R/46traYaH90yiryPVgCgooT9
pXU/RVXwTL287Akh3dkSrtc=
=fGpB
-----END PGP SIGNATURE-----
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/