Re: Re: TorChat is a security hazard (Answer)
2010/12/13 : > I have committed a patch that will explicitly check for your scenario > and immediately discard the wrong pong message. Wow! I see a lot of creative hacking currently going on on in my log file, somebody is really desperately trying to send all sorts of pings and pongs to me with forged addresses and cookies but it all results in either dropping the connection or simply ignoring it, no disruption of normal operation :-) Bernd *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Re: TorChat is a security hazard (Answer)
On Dec 12, 2010 7:20pm, Michael Blizek wrote: I meant that A will connect intentionally to B, eg A wants to talk to B. B can then send messages to C which seem to came from A. However, C will talk back directly to A and the manipulation will most likely be detected... I have committed a patch that will explicitly check for your scenario and immediately discard the wrong pong message. The result is that this type of attack now shouldn't have any effect on the proper operation of A and the connection between A and C anymore. I also fixed a possible attack regarding the sending of pong (or other) messages over the victim's outgoing connection. It will now only accept file* messages on the outgoing connection (files are always sent on the other conection to enable chatting during file transfer) and file transfer requires a fully completed handshake anyways. I don't have any windows build based on this yet, I'm still fighting with py2exe and the Python-2.7 SxS-msvcr90-dll-manifest-hell (dll-hell v2.0). Bernd
Re: Re: TorChat is a security hazard (Answer)
On Dec 12, 2010 7:20pm, Michael Blizek wrote: I meant that A will connect intentionally to B, eg A wants to talk to B. B can then send messages to C which seem to came from A. However, C will talk back directly to A and the manipulation will most likely be detected... Yes. The innocent client C will then start talking with A and send its own address. A will then directly connect back to C and complete the handshake with C. I'm not 100% sure without looking into the sourcecode now (2 years since i wrote it) what exactly will happen with the wrong pong message from C that should have come as the ping response from B. It should ignore it because pong sender does not match the initial ping recipient. But I'm 100% sure that it would *not* lead to a stable connection (status: online, nomal behavior) or even a completed handshake at all. It might be suitable for some kind of DOS attack against a connection between A and C. Bernd
Re: TorChat is a security hazard (Answer)
Hi! On 15:03 Sun 12 Dec , Bernd Kreuss wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > [sorry for eventual double post, gmail replied to the sender instead of > the list] > > On Dec 12, 2010 8:26am, Michael Blizek > wrote: > > > proof. Suppose you have 3 peers A, B and C. B wants to impersonate A: > > > A wants to establish a connection to B > > This is where your example fails. A *can* not accidentally try to > connect B instead of C. I meant that A will connect intentionally to B, e.g. A wants to talk to B. B can then send messages to C which seem to came from A. However, C will talk back directly to A and the manipulation will most likely be detected... -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TorChat is a security hazard (Answer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [sorry for eventual double post, gmail replied to the sender instead of the list] On Dec 12, 2010 8:26am, Michael Blizek wrote: > proof. Suppose you have 3 peers A, B and C. B wants to impersonate A: > A wants to establish a connection to B This is where your example fails. A *can* not accidentally try to connect B instead of C. The only way to make A connect B would be that B first connects A and at this point it would appear as a completely separate buddy with B's true address in A's list. If TorChat sends a message it will always use the outgoing connection. It would not send messages on incoming connections, this means all messages that are intended to go from A to C (including the authentication ping) will be sent directly to C. I don't see any possibility to make a loop over 3 clients as long as both victims are not patched somehow. The intention for this architecture was to keep it *simple*, to use only the mechanisms that Tor provides and to use them in the correct way and to their fullest potential. I didn't try to re-invent or add anything additionally on top of that, I used only simple obvious logic. I didn't want to make yet another complicated thing that cannot be used by ordinary end users because its proper usage would require a degree in math and computer science. I wanted to make a tool that configures itself automatically and just works out of the box. The cryptic 16 character addresses are already near the upper limit of the comprehension of the average computer user. Usability has to be the highest priority! TorChat is exactly as strong as Tor's built-in mechanisms are: * TorChat authentication/man-in-the-middle <-- Tor hidden_service can not (easily) be impersonated * TorChat end-2-end encryption <-- Tor hidden service end2end encryption * TorChat anonymity <-- Tor anonymity nothing more and nothing less. If I had written a similar thing for i2p or any other similar network I would have used only the mechanisms that would be available and built into this network too. Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNBNY0xT6R4jlFoh0RAo2LAKCcbFb4+3r28U/LIycQuACVqpD2DACdHYnG q2d519CuBCELokiCNsoNsa4= =dHQV -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TorChat is a security hazard (Answer)
Hi! On 19:57 Sat 11 Dec , Bernd Kreuss wrote: > -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: ... > 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 I have not participated in the previous discussion. This concept sounds like reinventing diffie-hellman to me - except it does not fully man in the middle proof. Suppose you have 3 peers A, B and C. B wants to impersonate A: A wants to establish a connection to B and sends B a cookie + A's .onion address. B does *not* connect back to A, but sends the cookie and A's .onion address on to C. Then C will connect back a A and send A its cookie. A sends the cookie to B and B sends it on to C. Now B can read and manipulate the messages A sends to C. Of course, this requires that A knows and wants to contact B, not C. And A will probably get suspicious because suddenly C answers, not B. Anyway, why not do a complete diffie-hellman key exchange on both the incoming and outgoing connoction and then combine both keys to do symetric encryption on top of tor? OK, it is probably a bit paranoid, but... -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
TorChat is a security hazard (Answer)
-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 telli
