-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Wow... I wasn't aware the PT system was so complicated and chaotic under the hood. I assumed it was just a steg tunnel, simply give it address(s), poke data in one end and it pops out the other end, rate is limited by how much data you pull out of the exit buffer. The steg tunnel does the rest, deals with ports, timing, etc.
What I was planning to do was see if I could use it to steg data between my peer nodes (prefers RUDP), run a PT proxy on one node and run another one at the other end, and use it to steg data between the two. At a minimum I will have to have two kinds of connection, a directly connected RUDP peer, a TCP socks peer (TCP socksPT can easily be added). Obviously I will use TCP to/from the PT proxy. That's what I am considering doing but to do such a simple thing really I need to be able to do it with *no* communication with any control ports, transferring control data should be optional not required, unless the process is very simple and documented, it also means the transport will have to be able to fail safe if it tries to communicate back to a/or any system that doesn't support the control port. I don't know if these requirements are workable but would make PT more universally usable which can only be a good thing (imagine if thousands of programs used PT tunnels!). Obviously the more Tor integrated it becomes the less generally useable it is. It appears the PT system is strongly linked specifically to the Tor system, it may be better if PT was a generic system on its own with an easy documented interface and backward protocol for reverse communication (if desired). It would also be nice if all the inner workings of the individual transports are hidden behind a central socksPT proxy, tell it your requested transport, give it address(s) and it connects through (obviously it will never work like a normal socks proxy) and can also feed info back to your program if you provide an open OrPort. Obviously some components of PT cannot be reused like flash proxy transport because it was designed to solve a specific problem unique to the Tor project (not a bad thing) it just means it cannot be reused without much extra code. It occurs to me no matter which way you cut it a PT proxy is never going to be like/or used like a normal socks proxy (PT proxys require a load more config options than normal which standard socks spec cannot provide) so you might aswell go for a slightly extended socksPT version not massively off spec just extended. Socks assumes you will need IP, port, address type, authentication method, password but PT requires a bit more than that so all you have to do is add a few more steps to the chain. "1,2,3" are IPv4,Domain,IPv6, you could easily add "0" no address for flash proxy and "4" multi address string, 2 bytes Size:Word, followed by ";" seperated string eg. "IPv4:127.0.0.1:80; IPv6:0.0.0.0.0.0:800; Dom:www.google.com; ..." for ST. you can also add an extra step to the socks spec for PT config info, or just a simple extra size+data send after the socks hand shake, this would be a better solution than hacking socks which doesn't fit and would allow use of the password field. I appreciate your all busy over there, fixing bugs and security holes I also hear you've got some work to do on the hidden services system aswell. 1) I would suggest separating PT into a totally separate downloadable sub system, you could have a "complete package" with the frame work and all complete modules included, or you could have "separate modules" with the framework and modules downloaded separately which would save repeated downloading (obviously for ease of use still package it pre-configured with the Tor bundles). Being a separate entity will make it easier for the developers to maintain, and easier for developers to integrate it into there own systems, programs can iterate through the folders looking for PT modules or they can add them to there own config files. 2) You don't need encryption to the local host I will encrypt through the tunnel anyway as im sure all actively maintained programs will do aswell, end-to-end encryption through the tunnel is better and easier. Any programs that don't encrypt end-to-end probably aren't secure enough anyway. If you add SSL make it optional, im at a disadvantage here because I don't know how to do SSL yet and plain text is much easier. 2B) Forcing SSL would reduce the uptake of the PT system. 3) TCP and UDP socks interface would be nice so it would cover a larger range of programs, and be more efficient for UDP programs, queuing UDP packets into a reliable TCP stream is pretty easy. My protocol prefers R(reliable)UDP where possible, but my module can do both if needed. If it combined UDP im sure I2P would also use it. 4) Combining PT client and server into a single node is also a good idea. 5) As always K.I.S.S is the key to everything, keep the interface and protocals as simple and generic as possible the same way the Tor socks interface is so simple, ideally (like socks) so simple anyone can write a client for it. And this again is the problem im well aware taking something as complicated as the diverse methods of transport as you have and combining them into one simple protocol/interface or socksPT proxy is an enormous under taking especially as you dont know what your needs are going to be in the future. The simpler it is the more people will use it, the more people use it the less worthwhile there spying and DPI firewalls will be, there was a recent article "Dutch court surrenders allows pirate bay to sail again" http://rayanuk.com/20140130171827024/dutch-court-surrenders-allows-pirate-bay-to-sail-again Dutch court ruled blocking pirate bay was a waste of time because people can get around it (largely thanks to services like Tor *crowd cheers*) and 95% of people where still sharing files regardless. If this was easy to use and integrate all the file sharing programs would use it to bridge between peers, china and iran developers would use it, at some point DPI and packet sniffing will be so useless they wont bother. My point is if firewalls and DPI are worthless, they wont bother spending money on it and we will have won. Isn't that the war we are fighting here? I can see the enormous potential this has, I would say build it and they will come. Im sure many programmers figured out they could use Tors socks proxy port how many emailed you guys? But it was still greatly useful. Imagine the governments surprise they thought Tor was bad, and hidden services where worse, now everyones using stenographic tunnels making there DPI useless and a big waste of money. See the big picture here? I know your time is limited so I'll let you decide how you want to proceed and I'll get on with my code, once I get further I'll see if integrating PT into my project is feasible. ~Shadowman ~TheMindwareGroup themindwaregr...@gmail.com PGP: 0xf4b6586f -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJS7QhxAAoJEKcLVST0tlhv+AIIAKHCPc2KFx+uL6VUzu7tyeBJ GUD/QgD3w4rNmGmGQLQ8Qbt+AHIpEs4Hn7fQuTc4dH2rqXUaqO2OsFR/KjYKM725 MEWmx1PTYzdlpl/ZQLl6CytqPyoF9lFRorfCF1gg5FhTg3KjZx9n7v2PQ1Tr/Rzd gCIrwxY3qgiOHbbhlprXmhlCL8ZJIkMm89y6Dpc9xjzvZa5FrU1CqBRk7oI3f6r/ l/i0lyFSdDr89jsCgUlwUUZwAMF41Mn8v6FkGKfjWqFWD+0Qr/+hY7jVLWserTJa aufnWpavvYRDQFA6W6P6Urv4JeACZ43pWfFTT/D6V1gjKU2Dj5G3RE+hmAyzuB0= =SCN4 -----END PGP SIGNATURE----- -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
