Re: [tor-talk] Pluggable transports

[TheMindwareGroup <themindwaregroup@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hmmm... I've been thinking about all this stuff, and reading up on the
PDFs.

I think "the parrot is dead" is a little over strict in his analysis,
I highly doubt they have technology as good as this yet and probably
wont have any time soon, so yes in the future he is right but simply
to hide the protocal from passive analysis which is what the PTs are
designed to solve, it will work fine.

But as pointed out to complete the solution PT is only one part of the
solution, to resist active probing you would have to code a full web
server for example. Yes hes right 100% mimicing is impossible, you'll
never be able to totally mimic a specific web server for example
timings and everything, but you dont have to *any* web server works on
the internet as long as its RFC compliant (also you could use a single
url on the web server as the tor hand shake, because the RFC would
force them to allow arbitrary urls but if they started doing url
filtering tor web badges/flash proxy badges would also be vulnerable).
The problem is a single hole must be allowed to get the Tor handskake
through which will make the mimic 99% accurate instead of %100, its
this 1% behavior difference they will use, I also suspect they will
get the PT code and try a Tor hand shake through a PT to test for Tor
nodes anyway, and *horror* what they might do when all nodes look like
web servers they might try PT Tor hand shaking on all web servers just
to make sure, when that day comes it will be bad.

But I reckon PTs will work fine for now and resistance to active
probing will vastly improve it and that should be good enough for
several years til we can find a better solution (if there is one).

I was thinking about PTs and think I may have a workable solution...

I thought either PTs could use socks4/5 and force the PTs to work like
a standard socks proxy, this would be ok for single tunnel PTs and
Flash proxy, but more complex systems like stegotorus would be a
problem you could either stuff all the IPs into the password field
this hack could kindda work but may not fit or you could send multiple
single socks connections through it each with a single IP (wont work
on standard socks).

Normal programs could use it but they wont be able to use the full
functionality of the PT and obviously cannot benefit from the reverse
control data, this solution is ok or in some ways might be better,
because even though socks is hacked and limited at least you can do it.

Or you could use a slightly modified socksPT, what you could do is use
socks 4/5 like normal, but if you put 99 in the version byte it
activates the extended PT socks interface with added address types and
steps to the handshake. This might be a better solution, socks can use
it, but programs with PT support can use the extra functionaily.

Or make a mini socksPT Proxy just to hide the internals of the PT
system, with socks input and converts it to the socksPT output, with
configs, proper settings, it could also have a control port to do
proper PT communication for you.

Program >>> socksPT Proxy >+>> Flash proxy
                           +>> Stegotorus
                           +>> Dust
                           ..

I hope this is useful.

Im trying the idea of a system implemented as separate modules with
intercommunication and see how it turns out.

Program <---> MSat Routing service <---> Other MSat routers <--->...
              /\                       > Other MSat routers <--->...
              |                        > Other MSat routers <--->...
              \/
              MSat probe <---> Internet...

Programs interface with the system, the MSat routers communicate, as a
last resort if the satellite cannot boot into the network, they
activate there beacon (open fixed port that helps lost nodes find the
network and each other), it launches a probe that scans IP blocks,
starting with the my local one, till it finds other MSat routers.
Because the MSat routers are connected as a DHT web one node should be
sufficient to get onto the network. There might also be many small
groups of disconnected networks that may or may not be connected to
the collective swarm. As long as two nodes are connected they can talk
to each other, when you have 3 now 3 people can communicate, no
centrality what so ever. How ever it may be helpful to have fixed
domain seed nodes to speed everything up but if they block them it
doesn't matter. Every successful boot into the network gives you info
to help you boot in later on.

But the idea is other modules can be added, new modules can talk to,
or register to be informed about certain kinds of info from the other
modules, as long as you can talk the resources language you can use
the existing resources. Common transfer language might be helpful here
(like xmpp/xml) but im just making it simple commands and see how it goes.

~Shadowman

~TheMindwareGroup
TheMindwareGroup@xxxxxxxxx PGP: 0xf4b6586f
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJS9PeiAAoJEKcLVST0tlhvPqoIAInV2qjo0eX1OMrPmjUoqbXJ
/L3K+sJzTA124wcG2kxwp3DpETbyeC8Jw4HybKUhf2yUXwE6mj0LFLXVJAywqsn1
z5CYm/VqH7qb7Wjwz1iFUJt3KLsdKsOVNJXz0afi5hq1dho+wX42CQJqDm8qvAGl
Gt3WiEL6Vx36iLDOQs2Ktnd570pRVlXQf2/IGNpp+HYH1N/n64EKWQdpsyn0Kqwc
2HB2iTdoUbJ151Rlg2sXBy5Wof5K6k663nTNkeSOTNlCJs7X0SHVmSZeu4EAoczc
xtIckR6R+sYs0zw6jqXbWo49VnSlrlbefsYTR+XwnXfKJYr/fxGw9O8boJ7BiMU=
=lq2q
-----END PGP SIGNATURE-----
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk