-----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 [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
