Re: [tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread Dave
If you want to confirm whether a UDP or TCP port (or range of ports) is being blocked or not, try http://www.firebind.com ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Python TorCtl development questions

2011-06-11 Thread Damian Johnson
> I have begun using the Python TorCtl package to develop a gui TOR > controller. Great! What are your planned use cases for this gui? Kamran is also beginning work on a gtk gui for arm (http://www.atagar.com/arm/ - a python project that uses torctl) so that might be of interest too. We'd certain

Re: [tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread Ian Goldberg
On Sat, Jun 11, 2011 at 07:14:52PM +, Jacob Appelbaum wrote: > > On 06/11/2011 07:58 PM, Ian Goldberg wrote: > >> Yes, but the client (say, inside China) is perfectly capable of > >> artificially fragmenting its SYN packet.  It shouldn't be too hard to > >> check what actually happens in this c

Re: [tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread Jacob Appelbaum
> On 06/11/2011 07:58 PM, Ian Goldberg wrote: >> Yes, but the client (say, inside China) is perfectly capable of >> artificially fragmenting its SYN packet.  It shouldn't be too hard to >> check what actually happens in this case?  (At least, for the current >> GFW configuration.) > > No it wouldn'

Re: [tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread tagnaq
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/2011 07:58 PM, Ian Goldberg wrote: > Yes, but the client (say, inside China) is perfectly capable of > artificially fragmenting its SYN packet. It shouldn't be too hard to > check what actually happens in this case? (At least, for the curr

Re: [tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread Ian Goldberg
On Sat, Jun 11, 2011 at 07:21:53PM +0200, tagnaq wrote: > On 06/11/2011 06:59 PM, tagnaq wrote: > >> Hmm. I wonder what happens if the packets are fragmented so that the > >> TCP port information isn't in the first fragment... > > An IP packet must be very small to fulfil this scenario (first IP

Re: [tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread tagnaq
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/2011 06:59 PM, tagnaq wrote: >> Hmm. I wonder what happens if the packets are fragmented so that the >> TCP port information isn't in the first fragment... An IP packet must be very small to fulfil this scenario (first IP fragment is so sm

[tor-dev] Will people running a relay be blocked from accessing CN destinations?

2011-06-11 Thread tagnaq
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian, I made a new thread to avoid this discussion in the 'The Torouter and the DreamPlug' thread. > On Thu, Jun 09, 2011 at 11:47:10PM +0200, tagnaq wrote: >>> > > Doesn't "make random people into public (middle-only) relays" have the >>> > > (well

Re: [tor-dev] The Torouter and the DreamPlug

2011-06-11 Thread Ian Goldberg
On Thu, Jun 09, 2011 at 11:47:10PM +0200, tagnaq wrote: > > Doesn't "make random people into public (middle-only) relays" have the > > (well maybe not "problem", but "issue"?) that when GFW blocks them, they > > (the random people who bought an Excito/etc.) won't be able to connect > > to anything

[tor-dev] Python TorCtl development questions

2011-06-11 Thread Sean Robinson
I have begun using the Python TorCtl package to develop a gui TOR controller. So, I am looking at the TorCtl source to understand how to use it properly. In this examination, I have begun adding comments, renaming vars to be more explicit, etc. How open are the developers to these changes?

Re: [tor-dev] The Torouter and the DreamPlug

2011-06-11 Thread Fabian Keil
Fabian Keil wrote: > and...@torproject.org wrote: > > > On Fri, Jun 10, 2011 at 07:12:25PM +, ja...@appelbaum.net wrote 1.7K > > bytes in 39 lines about: > > : I did not suggest a backdoor! I suggested a method of remotely helping > > > > This comes across as "it's not a backdoor, it's a h

Re: [tor-dev] Too many cooks spoil the broth---or: how about we clean up the wiki?

2011-06-11 Thread Karsten Loesing
On 6/11/11 2:41 PM, and...@torproject.org wrote: > On Sat, Jun 11, 2011 at 08:17:35AM +0200, karsten.loes...@gmx.net wrote 2.5K > bytes in 34 lines about: > : > Do you plan to fix links in the mailing list archives as well? How > : > about links in our e-mail inboxes? > : > : Nope. But we could

Re: [tor-dev] The Torouter and the DreamPlug

2011-06-11 Thread Fabian Keil
and...@torproject.org wrote: > On Fri, Jun 10, 2011 at 07:12:25PM +, ja...@appelbaum.net wrote 1.7K > bytes in 39 lines about: > : I did not suggest a backdoor! I suggested a method of remotely helping > > This comes across as "it's not a backdoor, it's a highly secured front > door that onl

Re: [tor-dev] The Torouter and the DreamPlug

2011-06-11 Thread andrew
On Fri, Jun 10, 2011 at 04:15:43PM +, ja...@appelbaum.net wrote 15K bytes in 322 lines about: : I think we should re-flash with an OS that makes hardening a priority. We : should only harden the OS in the sense that we should strip out anything : that we do not require for our uses. Debian and

Re: [tor-dev] The Torouter and the DreamPlug

2011-06-11 Thread andrew
On Fri, Jun 10, 2011 at 07:12:25PM +, ja...@appelbaum.net wrote 1.7K bytes in 39 lines about: : I did not suggest a backdoor! I suggested a method of remotely helping This comes across as "it's not a backdoor, it's a highly secured front door that only law enforcement will have access to in o

Re: [tor-dev] Too many cooks spoil the broth---or: how about we clean up the wiki?

2011-06-11 Thread andrew
On Sat, Jun 11, 2011 at 08:17:35AM +0200, karsten.loes...@gmx.net wrote 2.5K bytes in 34 lines about: : > Do you plan to fix links in the mailing list archives as well? How : > about links in our e-mail inboxes? : : Nope. But we could add redirects for those pages linked from the : mailing list