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: 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/
Re: [p2p-hackers] Help needed: Autonomous NAT traversal test [Was: enabling bridges on NATed clients]
Hi! On 16:35 Sun 07 Mar , Eugen Leitl wrote: - Forwarded message from Christian Grothoff christ...@grothoff.org - From: Christian Grothoff christ...@grothoff.org Date: Sun, 7 Mar 2010 12:30:53 +0100 To: or-...@freehaven.net, or-...@seul.org, or-t...@seul.org, gnunet-develop...@gnu.org, help-gnu...@gnu.org Subject: Help needed: Autonomous NAT traversal test [Was: enabling bridges on NATed clients] User-Agent: KMail/1.12.4 (Linux/2.6.31-14-generic; KDE/4.3.5; i686; ; ) Reply-To: or-talk@freehaven.net Dear all, In order to more thoroughly answer sird's question (for GNUnet, possibly for Tor and generally for anyone interested in P2P), a group of people (including Andreas Mueller, Samy Kamkar, Nate Evans and myself) would like your help. I had some thoughts about building a library for applications which do fancy things with the underlying network. Primarily, because I have a project which will likely be more useful, if applications take proper use of it. (see http://michaelblizek.twilightparadox.com/projects/cor/internet_exit.html ) To my mind such a library should do *way* more than NAT transversal, if it is supposed to be generic: - Provide OS abstractions - Provide socks proxy (which BTW have a way for opening ports on the other side) abstractions - Use its own configuration file, if the application does not override things at runtime. This way, the user can configure everything even if the application does not provide ways to set certain parameters. Also, an application name parameter should be passed to the lib, so that the config file could contain different parameters for each application. - Maybe provide some addressing abstractions, so that applications can run within IPv4/IPv6/.onion/... networks without changes. - Provide ways to set things like IP_TOS, so that external shapers are easier to setup. - Make sure that e.g. TCP_CORK is always set when possible. - Do throttling the proper way and *not* by usleep, but by setting TCP_CONGESTION or smaller tcp window sizes if possible. usleep should only be the last resort. When using usleep or smaller tcp window sizes, the lib should be able to figure the proper parameters out by itself e.g. by pinging a fixed IP and looking at the response times when the net is under load. - Provide a way for the application to tell the library which connections are important and which connections need throughput or low latency. -Michi *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [p2p-hackers] Help needed: Autonomous NAT traversal test [Was: enabling bridges on NATed clients]
Hi! On 11:18 Sun 07 Mar , Stephen Williams wrote: I've been lurking for a while. Apologies that I've missed most of the conversation. Michael Blizek wrote: ... - Do throttling the proper way and *not* by usleep, but by setting TCP_CONGESTION or smaller tcp window sizes if possible. usleep should only be the last resort. When using usleep or smaller tcp window sizes, the lib should be able to figure the proper parameters out by itself e.g. by pinging a fixed IP and looking at the response times when the net is under load. Rate-based end-to-end flow control with bandwidth estimation, usually needed at both the communications and application level, is the way to solve most related problems. I can detail and provide references. It turns out not to be very hard to implement in most cases. Recently, we called this pro-active flow control to try to distinguish it from simple window-based flow control. There is a thing called congestion avoidance which should take care of the flow control. In linux, you can select the algorithm per-socket - and you can sometimes set a low priority one. The bad thing is that this congestion avoidance is triggered by packet loss. On slow lines with big buffers, this might be too late. Using the latency for flow control also has its down sides, like convergence issues. Anyway the point is that usleep is one of the worst mays of doing the throttling on the sending side (it is ok on the receiving side). The reason is that the TCP/IP stack will create lots of small packets (increases CPU usage of routern) which have the push flag set (which triggers ACK sending without delay, which causes even more small packets). - Provide a way for the application to tell the library which connections are important and which connections need throughput or low latency. Yes, need a standard way to provide and propagate these hints. Also, need to provide visibility of preferences of routers (i.e. intermediate systems) along the pipeline if possible. This allows things like bandwidth throttling to be visible, enforced, and accounted for (perhaps by opening additional channels). IP has a way to do this. It is called TOS field, but it is rarely used. There is little point on TP networks anyway. If there is not enough backbane bandwith, everybody will try to get as much as possible and nobody will set the TOS field. They will rather randomise ports and do encryption and traffic normalisation to prevend being slowed down. I think this parameter is mostly interesting before the traffic leaves into the internet. -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/
