Hi there,
During the first two weeks of my GSoC project, I have implemented a HTTP CONNECT-based pluggable transport. In short, I use HTTP CONNECT semantics to establish a secure channel between the client and the bridge. Specifically, this is the scenario:
1. Connection establishment:
+------------------------------+
|CONNECT bridge_ip:443 HTTP/1.0|
|User-agent: blablabla |
+------------------------------+
|
|
+----------+ | +----------+ +----------+
| client |----->| proxy |----->| bridge |
+----------+ +----------+ | +----------+
|
|
+------------------------------+
| (Establish a connection) |
+------------------------------+
2. Data relay
+------------------------------+
| (Encrypted Payload) |
+------------------------------+
|
|
+----------+ | +----------+ +----------+
| client |<----->| proxy |<----->| bridge |
+----------+ +----------+ | +----------+
|
|
+------------------------------+
| (Encrypted Payload) |
+------------------------------+
I hope the diagrams above are self-explanatory. It is only my initial attempt to get familiar with HTTP protocol. Once I make sure it is working correctly under squid proxy I will upload it to the repository.
The use of CONNECT method is restricted in many networks, so it is better to implement the HTTP transport using the usual HTTP methods as POST, GET, etc. In the next stage, I plan to implement a new HTTP transport based on BOSH[1]. There are many issues to care about (in order of priority):
* bi-directional data transfer over HTTP
* proxy cache
* HTTP request/response encoding
* encryption
* scanning resistance
Have a nice weekend!
[1]: http://xmpp.org/extensions/xep-0124.html
Best,
Chang
Sent from my mobile device. Sorry for the brevity.
> This is rather exciting. Do you think that this method can be adapted to
> build the pluggable transports bundles?
Yes.
I originally started working on this so I could submit a patch to include
the tor-fw-helper in the TBB.
But since the helper is only needed in the PT bundles,
reworking their build process seems the more productive route.
I'll see what I can do.
> This is currently done
> semi-manually, with a makefile that builds the pluggable transports,
> unzips the bundle, copies in some files, and re-zips the bundle.
>
> https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/Ma…
>
> We also have instructions for setting up a build VM from scratch--which
> it sounds like is what Vagrant does--but I guess we would instead use
> whatever is the build machine for the vanilla bundle.
>
> https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/Ma…
>
> It would solve a lot of problems for us to have the PT bundles built at
> the same place and time as the vanilla bundles.
Hey friends,
i want to inform you that i am working on a complete new control tool
for Tor. I know some people use Vidalia for it, but i never liked the
program and the people i showed vidalia often got confused.
So i started to rewrite it from scratch and i am close to the release of
the source code. (Currently i need to clean up some classes in there)
I had a few things on my feature list for the new control tool and i
want to share/discuss it with you. Because maybe some of my ideas are
bad or maybe you have some additional ideas for features.
A: "native work flow". Thats one of the main goals of my rewrite. The
current Vidalia does things a little bit different than people are used
to do it. So they get confused, because it does not behave "naturally".
So instead of QT i used GTK and followed as always the GNOME HIG.
(http://developer.gnome.org/hig-book/3.5/)
B: "Multi configuration setup". What do i mean by that? Well, in my case
for example i use Tor on my laptop and i am often in different places
where i need different settings for tor. For example, if i am at home i
can give tor all the bandwith i have, because at home i don't care. In
my company on the other hand i cant do that. I am allowed to run Tor in
the company, but with a bandwith limit of 2000kbit/s. (Yes, my company
allows this ... well, i am the technical directory, so it was my call :) )
But i need a different Tor configuration there. Or if i am giving a talk
and only have mobile internet connections i need every bit of bandwith
for checking my emails so i want no server, only Tor client support.
Currently i have multiple torrc files for that and always move them
arround. That works for command line junkies like me, but even i am
anoyed to do this multiple times a day.
So i added the "multi configuration" support into the tool. This allows
you to define multiple configurations and simply change them with a
click from the gnome2 notification panel.
C: "GUI for config settings". Well, some users are simply not ready to
modify config files on there own. So i provide a simple gui (tab based)
for all config options i found in the normal torrc file. Always with an
explonation (with needs spellchecking, because my spelling sucks in
german and is even worse in english :) ) so the user can deside what an
option would to.
D: "Notifications": My control tool uses the normal desktop
notifications to inform the user about changes in the running tor
application. For example if there is a problem building the circuit or
something you get the notifyd message and can simply react to events
without having the arm log open all the time.
Thats just a quick overview of what i am duing right now. The source
code will be released soon and is of course 100% open source. If you
have some addiional ideas, feedback, wishes, ... i would like to hear them.
Thanks and greetings
Leo
PS: I am Germam and very sorry for every spelling error i did above.
--
Leo Unglaub
Nachreihengasse 39 / Top 7
A-1170 Vienna
Austria
Phone: 0650 / 6575103
Website: http://www.leo-unglaub.net
Twitter: http://twitter.com/LeoUnglaub
Send with Mozilla Thunderbird on Linux (Debian)
Hi all,
In the first 4 weeks of my GSOC project steganography browser add-on,
I have implemented the basic UI parts in first two weeks, and later I
spent more time on web content downloading part. Up to now, I have
finished downloading image and get them as bytes. Now when you right
click on an image and click on test button, you will be getting the
byte format of image which can be used with steganography algorithms
to write messages. Since I'm mainly concentrating on features rather
than algorithms now,
my plan for next 2 week is to extend the file downloading for video
and sound files.
You can find the source code under git repository [1].
[1] https://github.com/rharishan/Steganography-Browser/
--
Hareesan
Ian Goldberg:
> On Wed, Jun 26, 2013 at 03:55:58PM -0400, David Goulet wrote:
>> Hi everyone,
>>
>> For those who don't know, I've been working on a new version of Torsocks
>> in the last three weeks or so.
>>
>> https://lists.torproject.org/pipermail/tor-dev/2013-June/004959.html
>>
>> I just wanted to give a quick status report on the state of the development.
>>
>> The DNS resolution is working for domain name (PTR) and IPv4 address.
>> Currently, Tor does not support IPv6 resolution but the torsocks code
>> support it.
>>
>> Hidden service onion address resolution is also working using a "dead IP
>> range" acting as cookie that is sent back to the user and mapped to the
>> .onion address on the hijacked connect().
>>
>> I've changed quite a bit the configuration file (torsocks.conf) to fit
>> the style of tor (torrc). At this point, the tor address and port can be
>> configured as well as the "dead IP range" mention above. More is coming
>> but pretty simple for now.
>>
>> Logging is working, connection registry and thread safety as well. There
>> is also a compat layer for mutexes and once I start porting the project
>> to other *nix system (BSD, OS X, ...) probably more subsystem will be
>> added to that compat layer.
>>
>> So, in a nutshell, some libc calls still need to be implemented, *moar*
>> tests and other OS supports. I'm confident to have a beta version to
>> present to the community in a couple of weeks (if nothing goes wrong).
>>
>> Feel free to browse the code, comment on it, contribute!, etc...
>>
>> https://github.com/dgoulet/torsocks/tree/rewrite
>
> Are non-blocking sockets, select/poll/etc. (especially at connect()
> time), and optimistic data on the to-do list?
Yes! Good point I should have put the todo list. So yes, non block socket support.
For optimistic data, it is kind of tricky. I can use it for DNS resolution
without a problem because torsocks control the complete flow of data from
opening a SOCKS5 connection to closing it after the DNS response is received
however for actual real data (sendmsg, send, ...) a connect is needed before so
it would means that a connect() call will return "yes OK socket connected" but
where in fact it is not really true. So, when the first data are sent, there is
a possibility that the Tor connections failed or even we block for an unknown
amount of time during the send*/write() call.
Now the question is, is this the kind of behavior that would be acceptable
meaning basically lying to the caller at connect() and possibly blocking I/O
calls and returning something like ECONNRESET or ENOTCONN if the Tor socks5
connection fails.
This is *real* tricky especially with non blocking socket, if torsocks needs to
do some possible blocking call for the SOCKS5 replies during an I/O call from
the caller that is not suppose to block. Furthermore, having pending data that
*might* come at any time on the connection from the SOCKS5 negotiation, the
caller could put the file descriptor in poll() mode, wake up and try to receive
the data but where in fact it's the socks5 reply... it's possible to handle that
but it seems here a VERY intrusive behavior. Does optimistic data worth it here
vis-a-vis the complexity of handling that it and high intrusiveness ?
Cheers!
David
>
> Thanks,
>
> - Ian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi *,
The first two weeks of working on my GSoC project[0], which has been
dubbed "EvilGenius", are nearly over. and I just wanted to share a bit
of the experience I made during that time.
EvilGenius is a tool that - much like Descartes' idea of an "evil
genius", it "presents a complete illusion of an external world,
including other minds, to Descartes' senses, where in fact there is no
such external world in existence." (Source: Wikipedia), it distorts
the guests' view of the real internet, in short, it creates a virtual
environment that simulates censorship in order to verify OONI's
nettest modules.
So, after getting started with vagrant, the virtualization abstraction
layer used for my project, i started simulating a virtual netwotrk and
configuring the hosts to act as if they were connected to each other
and the rest of the internet through a router that is part of the
simulated environment.
the "precise32" box is used as base image for all nodes, and I created
scripts that configure the network and packed it up in a nice vagrantfile.
Then I began deploying ooniprobe and oonibackend and executed the
first successful tests.
Next week, I will begin working on censoring environments.
Have a nice weekend everyone!
Johannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRzKDWAAoJEAgie5o3Q/JpUhAQAIt2WEpDsNyLVDuSdMBM0ETf
q0sOxdx20Q6o77J93FJ4ZBJRzpBX4mlsE4t22Dl/TPgnHu3b+DG+dvVhfCBrQOqw
wGUuA6/X/khCikAOo+f3T9fNtaHKw54phW1Tw9Yj3Gea7SBN5ZikfXKjIIHOT+lu
n0xqWVzxAxqGOETy0byDznsdgc2OfaR2NkdxzCsLlZTLtE75h/EQ3U96ZCej8lw/
xmZZUD+q+4ZCE6bBKTebufQeh0eI/rUPgo0UX1rNLgUapfCs9oLVIF+8nwBKBU0j
E2myEOUbXMCxtTURbHikRQKzGKlsXMCEqqSatik37Rc3VaeVdkxNiiyXFVRwzTr0
IwRTibzJ8hD+aqh9d9VDD6s7dIdRio42p+XzD8jswFltEyYcbBGeAFFiybdNeeE2
EFb7n7iHz7Gr1csezyma1fdqvvMHZaaeCMTqeRENQtBaazOnqDwrGJn83r/FC7QF
m8i+3eVDm8suM7CzYvuYi8YSIhF7yMVerIBOcBSZ2A929SVKtQFT4by1V2Jc4pz+
0ZJV4teS8xct0wjhpDLANBCXgnV07OO6Z6EgLhcWpJBWoZDONDaxikH7clmTlzdg
w/9ZktL3Ac3PjhSdMjOI/TKqc68+CHQ7ln1mG+YtSimMjf5Abpx1wPgLLILmzFNS
lpZ2vev2pW0DsCnvs946
=abNV
-----END PGP SIGNATURE-----
Hi all. Without much ado here's my status report for June...
* Stem: Migrated to the Mock module
Our homemade mocking framework has served us well, but over time it
taught me one very important lesson: writing a mocking framework is
hard. On the surface it seems pretty simple: apply and revert a set of
monkey patches. But how do you monkey patch class methods? What about
alias imports like the os module? And god forbid you want to mock
python's open() function.
I'm finally taking a lesson from one of my coworkers and using a
library for this. Python has several options but the most common is
PyPI's mock module, which became part of the standard library in
Python 3.3...
http://www.voidspace.org.uk/python/mock/https://gitweb.torproject.org/stem.git/commitdiff/101cf0b?hp=65846e8
========================================
* Arm: Pruning the torTools utility
Arm's torTools module was a wrapper around TorCtl that provided
caching, thread safety, and a better API. Now that we're using stem
it's obsolete, and my aim is to completely eliminate it from the
codebase. This is easier said than done however. This month I pruned
vast swaths of the module, reducing it from 2768 lines to 1020...
before: https://gitweb.torproject.org/arm.git/blob/refs/heads/release:/src/util/tor…
after: https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/torTools.py
Doing this required some expansions on stem's part. Added
functionality includes...
* get_pid() and get_user() methods in the Controller
* system functions for getting a process' start time and FreeBSD jail path
* the system module's call() wasn't respecting exit codes
========================================
* Stem: Remote descriptor fetching
Throughout the month Karsten and I have been bouncing ideas back and
fourth concerning a stem API for remote descriptor fetching...
https://trac.torproject.org/projects/tor/wiki/doc/stem#RemoteDescriptorFetc…https://lists.torproject.org/pipermail/tor-dev/2013-June/004957.html
I have some s3krit ideas for improving this that will address both our
use cases even better (spoiler: future style instances). We're coming
up on a four day weekend so hopefully I'll be able to start
implementing this soon!
========================================
* Stem: Expanded FAQ with answers to common Stack Overflow questions
I took a pass over the tor related questions on Stack Overflow
(http://stackoverflow.com/questions/tagged/tor), answering fifteen
that concerned controller scripting. The vast majority of those
unfortunately were some variation of 'how do I programmatically change
my IP?' which I answered with a Stem FAQ entry...
https://stem.torproject.org/faq.html#how-do-i-request-a-new-identity-from-t…
The only question I thought was especially interesting went along the
lines of 'How do I check the IPs of the exits I'm presently using?'. I
answered this with a FAQ entry too...
http://stackoverflow.com/questions/9777192/how-do-i-get-the-tor-exit-node-i…https://stem.torproject.org/faq.html#how-do-i-get-information-about-my-exits
========================================
... and a handful of smaller tasks...
* Investigated the descriptor version provided via tor's 'GETINFO
ns/*' options. Contrary to to the spec it turns out these have been v3
all along, and stem now parses them as such. (#7953)
* Our automated Jenkins test runs caught their first instance of tor
regression. This concerned LOADCONF's behavior after merging a branch
for ticket #6752 (#9122).
* Handful of GSoC tasks (welcome/sorry emails after acceptance was
announced, and org admin prep for the program's start)
* Added msg_type argument to ControlMessage.from_str() (request by
meejah, #8605)
* Investigated cache consistency issue (thanks to Ravi, #7713)
* Fixes for ONLINE target (patch by Jeremy, #8692)
* Minor revisions to how consensus bandwidth-weights are validated (#6872)
* Addressed an arm issue with certain TERMs (#9064)
* Answered some questions from Sreenatha that came up while
migrating Tor Weather to Stem
(https://lists.torproject.org/pipermail/tor-dev/2013-June/005035.html)
Cheers! -Damian
(Sorry for cross-posting, but I think this is a topic for tor-dev@, not
tor-talk@. If you agree, please reply on tor-dev@ only. tor-talk@
people can follow the thread here:
https://lists.torproject.org/pipermail/tor-dev/2013-June/thread.html)
On 6/6/13 7:32 PM, Norman Danner wrote:
> I have two questions regarding a possible research project.
>
> First, the research question: can one use machine-learning techniques
> to construct a model of Tor client behavior? Or in a more general form:
> can one use <fill-in-the-blank> to construct a model of Tor client
> behavior? A student of mine did some work on this over the last year,
> and the results are encouraging, though not strong enough to do anything
> with yet.
>
> Second, the meta-question: is it worthwhile to answer the first
> question? It seems to me that if the answer to the first question is
> "yes," then the solution could be used to (at least) provide better
> simulations of Tor (e.g., via Shadow or ExperimenTor). This possibly
> naive thought would imply that the answer to the second question is "yes."
>
> I'd be interested to hear responses to my second question, either
> validating my naive thought or explaining why the first question isn't
> worth answering. I'd accept responses to my first question, too, in
> case this has already been done.
Hi Norman,
yes, it's worthwhile to answer this question! I can imagine how at
least Shadow and the Tor path generator would benefit from better client
models. User number estimates on the metrics website might benefit from
them, too.
I found two tickets where we asked similar questions before, and maybe
there are more tickets like these:
https://trac.torproject.org/projects/tor/ticket/2963https://trac.torproject.org/projects/tor/ticket/6295
Some very early thoughts:
- How do we make sure that we ask a representative set of people to
instrument their clients and export data on their usage behavior? If we
only ask people who read their favorite news site twice per day, our
client model will be just that, but not representative for all Tor
users. (Still, we would know more than we know now.)
- Can we somehow aggregate usage information enough to make it safe for
people to send actual usage reports to us? I could imagine having a
torrc flag that is disabled by default and that, when enabled, writes
sanitized usage information to disk. For this we need a very good idea
what we're planning to do with the data, and we'll need to specify the
aggregation approach in a tech report and get it reviewed by the community.
Are your student's results available somewhere?
Best,
Karsten