Re: Re: TorChat is a security hazard (Answer)
2010/12/13 prof7...@googlemail.com: 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 mic...@michaelblizek.twilightparadox.com 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: 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 mic...@michaelblizek.twilightparadox.com 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 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 mic...@michaelblizek.twilightparadox.com 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: Re: TorChat is a security hazard (Answer)
On Dec 12, 2010 7:20pm, Michael Blizek mic...@michaelblizek.twilightparadox.com 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 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/
