[tor-talk] Pluggable transports.

Sat Feb 1 14:45:05 UTC 2014

-----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
TheMindwareGroup at 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-----