Re: Torbutton, CSS3 and window size
- Original Message From: Just A. User just_a_u...@justemail.net To: or-talk@freehaven.net Sent: Fri, December 10, 2010 3:42:19 PM Subject: Re: Torbutton, CSS3 and window size This places us in an interesting legal situation with Mozilla, because technically such a patch means that we can no longer use the trademark Firefox to describe the browser we provide in this case. Is it that bad? Are there any fundamental problems with Iceweasel etc? I do not think Tor Project has to rely on the Firefox brand awareness to distribute Tor Bundle among end users. Maybe, having an independent security-oriented patched branch of Firefox or Chrome can facilitate accepting some of the patches by the upstream. If the Firefox icon were to be changed, shoulder-surfing or screen-capturing adversaries would be able to easily notice it. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Damian Johnson atag...@gmail.com wrote: John mentioned that for him connection resolution doesn't work in the new arm tarball (arm_bsdTest2.tar.bz2). Hans, Fabian: can either of you confirm, and if so what sort of issue is the log indicating? I can't confirm this. Also, there was interest mentioned earlier in a BSD port. Anyone interested in taking up that gauntlet? :P I intend to look into creating a FreeBSD port around Christmas. Fabian signature.asc Description: PGP signature
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: Arm Release 1.4.0
On Sun, 12 Dec 2010, Fabian Keil wrote: Damian Johnson atag...@gmail.com wrote: John mentioned that for him connection resolution doesn't work in the new arm tarball (arm_bsdTest2.tar.bz2). Hans, Fabian: can either of you confirm, and if so what sort of issue is the log indicating? I can't confirm this. I thought we had already determined that this was because of my 4k+ connections. I'm sorry I don't have another node to test on ... Damian, how many connections are on the node that you successfully see the conn list ? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
... Damian, how many connections are on the node that you successfully see the conn list ? I don't recall. It was on amunet and I'll retest this once the relay's back up to speed (we recently switched ISPs so it'll take a few weeks for the BW authorities to send more traffic our way again). I'm sorry, btw, for not applying the patch yet. There was an issue in that it would introduce a couple unnecessary system calls every time the path prefix was fetched, but the trivial fix (caching the results) would mean potentially having the wrong jail path if the connection singleton changes. While addressing this I found a couple other issues I'm also trying to address (unrelated to the patch) so it'll probably be a few more days before I have another tarball to be tested. Cheers! -Damian *** 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
