[tor-dev] Development of an HTTP PT
Kevin P Dyer
kpdyer at gmail.com
Mon Nov 25 19:29:05 UTC 2013
Thanks for thinking about HTTP pluggable transports. It turns out to
be a deceptively hard problem!
Do you have any initial high-level goals? Or are you just trying to
figure out *some* way to bootstrap an existing HTTP client/server
architecture to tunnel arbitrary data streams?
On Sun, Nov 17, 2013 at 6:22 AM, dardok <dardok at riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> George Kadianakis:
>> dardok <dardok at riseup.net> writes:
>>> Hi, I am quite new in here but I am interested to help and
>>> improve the TOR system. I am interested in PTs and particularly
>>> in developing a HTTP PT.
>>> I've read some papers ,,, and the ticket #8676 and I
>>> consider that it would be a good idea to make an effort and try
>>> to implement the HTTP PT as is stated in the ticket, that is
>>> using real browser and server services.
>>> After talking with asn, we conclude that a good point to start
>>> this development may be to focus on the HTTP transport part, that
>>> is to know how to control the browser or the server and how to
>>> embed the TOR traffic into the HTTP protocol (requests and
>>> responses). Things such as the data obfuscation, the delays in
>>> the communications and the packet chopping won't be considered,
>>> because it may be used another PT such Scramblesuit to do that
>>> The CLIENT side:
>>> TBB <-> Scramblesuit PT <-> HTTP PT <-> CENSOR NET
>>> and the SERVER side:
>>> CENSOR NET <-> HTTP PT <-> Scramblesuit PT <-> TOR bridge
>>> The important is to know how to embed the TOR traffic already
>>> obfuscated into the requests and responses to avoid suspicion.
>>> Also as I said before, to know how to control a browser binary to
>>> make the HTTP traffic from the client side as much traditional as
>>> possible, for instance using a firefox binary or something like
>>> that. The same must be applied to the server side, implementing a
>>> real NGINX server or an Apache server on port 80 and writting
>>> some CGI to classify the traffic incoming from the TOR clients
>>> through the HTTP requests. The same server may have another CGI
>>> to write and send the HTTP responses to those TOR clients with
>>> the traffic into them.
>>> I would like to find someone interested to work on this topic.
>> Hey there,
>> we discussed this project on IRC and looking at your post it seems
>> that you understood things :)
>> Like I told you, I'm interested in this topic, but my free time is
>> miniscule these days. Still, I'd like to help you out. Do you know
>> what you need help with?
>> If you want, we can organize a meetup in IRC to discuss and plan
>> future work on this.
>> It would be great if you prepared a bit of research on the basic
>> components of this project  so that we can discuss the various
>> options during the meeting. I'll send you an email to find the
>> right date and time for the meeting :)
>> : ways to control a browser from within a PT (selenium?), HTTP
>> covert channels, designs of how a server-side CGI script would
>> work, etc. _______________________________________________ tor-dev
>> mailing list tor-dev at lists.torproject.org
> I've been reading about Selenium web-browser driver thing and I
> consider that is not very handy to do what an HTTP PT client side
> needs, that is to forge HTTP requests and embbed the TOR traffic into
> these HTTP requests.
> It is more oriented to emulated a web user interaction with a real
> browser (such as firefox, chrome, opera, ie, ...) and the interaction
> and testing of web apps from these browsers.
> Also I cannot see how to handle the responses from the server-side
> using this thing. Few functions seem to be interesting regarding HTTP
> protocol handling and manipulation, as I said before most of the
> functions present are related with the user interaction.
> The Python version can be installed easily: pip install selenium
> The already implemented functions can be read on this file:
> I didn't find any useful function to allow a HTTP PT (client side)
> embed the TOR traffic into HTTP requests (maybe some cookie function
> related) and extract the information sent by the HTTP PT server side
> (maybe some get_body_text() or get_text() funtion).
> So I am ready to consider that this option is not be useful to
> implement a HTTP PT client side. Anyway, I would like to discuss this
> point with someone interested in this topic.
> -----BEGIN PGP SIGNATURE-----
> -----END PGP SIGNATURE-----
> tor-dev mailing list
> tor-dev at lists.torproject.org
More information about the tor-dev