Re: [tor-dev] bananaphone obfsproxy module

2013-10-29 Thread David Stainton 
Howdy,

Thanks. Your obfsproxy is a nice piece of work.

Bananaphone + Obfs2 sounds cool!
Modular transport chains make a lot of sense...
I like modular transports... recently for fun I wrote a VPN in Python Twisted
[https://github.com/david415/hushVPN]
using twisted consumers and producers.
My idea was to have a modular system where transports could easily be swapped.
Over UDP it's very fast and I was thinking that maybe I could reuse
some of that code to write
packet transports for obfsproxy. For instance Tor over ICMP, DNS etc...
Obfs2 over Bananaphone over UDP?

Right now the david-bananaphone branch is functional code.
I've tested it with ssh. SSH over Markov chains! It's laggy but it works.

Leif's design plans are interesting... He will be better at explaining it.
Perhaps it does something similar to your idea of RHE + Obfs2.

Briefly:

RHE(CRYPTO(HAMMERTIME(TOR)))

- RHE is Banaphone's markov or random weighted Reverse Hash Encoding
- CRYPTO is NaCl crypto_stream
- Hammertime: "adds chaff to a bytestream to impede passive timing analysis"

The goal is to not have any distinguishable patterns in the byte
stream. Is that what Obfs2 accomplishes?

We will do the crypto_stream secret key exchange using NaCl crypto_box
and Elligator;
spewing noise after keys are sent Elligator etc...
We were thinking to first implement the key exchange without
Elligator... and do that part later.

I'm working on the basic key exchange to work in branch
david-bananaphone-keyexchange
https://github.com/david415/obfsproxy/tree/david-bananaphone-keyexchange
I'm currently troubleshooting a problem with the message passing...
Maybe I do not understand your api well enough... I'm getting strange behavior.
It would help if another pair of eyes would look at this.
Perhaps later I will formulate a question regarding the obfsproxy api...

And I was hoping Leif would help me fix this branch:
david-bananaphone-nacl-hammertime
https://github.com/david415/obfsproxy/tree/david-bananaphone-nacl-hammertime

I wrote a naclStreamEncoder coroutine and made hammertime_rh_server
return coroutine chains with the NaCl stream encoders. It doesn't work
at all... really a rough draft scribbling of code that makes the
BananaPhoneBuffer unit tests through an exception...

OK. I will add ALL commandline options to obfsproxy-bananaphone!
OK... bandwidth overhead calculations... I'll take a look and run some tests.

Onward!

David

On Tue, Oct 29, 2013 at 7:19 PM, George Kadianakis  wrote:
> Greetings,
>
> I'm the guy who develops obfsproxy. I recently noticed that you are
> writing a bananaphone module for it. The code looks good and you even
> understood the pretty-much undocumented obfsproxy API! Nice!
>
> BTW, I thought I should let you know that we are currently writing
> software that combines transports together in chains. This means that
> you don't have to worry about data redundancy in bananaphone, since
> you can combine it with an obfuscating transport like obfs2 to create
> the following chain:
> tor data -> |obfs2 encoding| ->|bananaphone encoding| -> tor bridge -> 
> |bananaphone decoding| ->|obfs2 decoding| -> tor data
> This would create a bananaphone-encoded channel which transfers
> obfs2'ed Tor data (so the bananaphone traffic will look uniform, since
> obfs2 data is uniform (whether uniform bananaphone traffic is useful for
> censorship circumvention is a different story))).
>
> FWIW, we are still in the process of writing this transport
> combiner. You can read more about it in:
> https://trac.torproject.org/projects/tor/ticket/7167
> https://trac.torproject.org/projects/tor/ticket/9744
> https://gitweb.torproject.org/pluggable-transports/obfs-flash.git
> We should also create a Wiki page about it soon, I guess.
>
> Anyway, this transport combiner business means that you only have to
> worry about making the bananaphone transport work. It would also be
> nice if the transport was configurable, so that we can tweak its
> parameters easily. I would also be interested in some bandwidth
> overhead calculations :)
>
> BTW, feel free to send me any questions you have about obfsproxy or
> pluggable transports.
>
> Cheers!
>
> PS: Feel free to CC the public tor-dev mailing list in your reply if
> you want.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [Otter/Buoyant] Tor Documentation Pad

2013-10-29 Thread Colin C. 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everyone,

At today's Buoyant Otter meeting, it was determined that we needed a
pad to organize our thoughts regarding the current documentation we
have, and what we need.

I have created a pad at https://zugzug.titanpad.com/3 for this
purpose, and will begin adding resources to it tomorrow.

- -- 
- -Phoul
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJScH3pAAoJEJ01Zvx7KO7Y1c0P/39cMM5fSdx5LIVdfuKVctYx
6hde6OPDvmTPzzTI03MlcYMKRSvH60cJUKCah2J7r2nfEGD3gw0uq0hcn/izc1wr
+de7y3yAofbygFCT1k9v3KBaPi+nezvglqYu+hia9gsKuXf3+cLSATpymxTtUIDN
eOtEIsggCjDv3eD8bs4rSYINI2B+j6V0qj5Lhts0nikbLkoiO/Q34RxELr1DQxot
D+19Lvqb+yVCZE3NEsGyeJEu9hbAwRGgYgB2Qv/CSvbJ7c6SYFx4K0PUbG1ZYlHs
wQ0MB6PoZ3cub4W4jb0R3HwyT++tBARvzbrbALHGehmKCNsY6wZ1ucx36xJB/p6x
ABruNMjzAZhMPAz7yrf9cakOCskqXn10se21yd6EHUlknOKECEwzdCxJxE0Oswph
OjISwL+JAkI5aTC52NGelIwd2VPrYY/2RkOgCnybop7wGsBBqNqrY7pGLiT03NJx
m7MYE0RqJfZUjH++Ym52KU15ycPG2JhRxjnmym8OrvW1TPw0t24mSjfzIR0x90XI
Og7teG9ugxv2rCftdCVMNKLUh8BVOTC7G6GIxeqPlii7IHiHEAqBdxAhXAm945WJ
BjrimEQ0E73s/M/j7mDf7dblZegansvlHXuoBEpJSiT9fZHu3DAlAGvTS0dmBIkF
aMUcspY2nbhD+zCdI4z2
=OVcv
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torsocks 2.x issue - Need eyes on that

2013-10-29 Thread David Goulet 
On 29 Oct (16:41:02), Ian Goldberg wrote:
> On Tue, Oct 29, 2013 at 03:10:50PM -0400, David Goulet wrote:
> > That would work if there is a way I can "differ" the hijack of the
> > syscall symbol... Unfortunately, this is done at linking time thus
> > during run time, the syscall symbol is already hijacked by torsocks.
> > 
> > Let say we don't try to lookup the syscall symbol, the issue is that the
> > original syscall libc pointer will NOT exists within torsocks code so we
> > can't handle call to syscall() because we can't route it to libc. :S
> > 
> > It's really that we get in a kind of "infinite loop" where dlsym calls
> > syscall that calls dlsym and so on. But in the first place, we at least
> > need the libc syscall symbol so we can handle them.
> 
> Might it be possible to use objcopy tricks like --prefix-string or
> --redefine-sym to make the exported version of syscall different from
> the imported version?  Then the torsocks code could just call syscall()
> as a normal libc function, linked by ld.so, but when firefox called
> syscall, it would call torsocks's torsocks_syscall(), or something?

I've played a bit with objcopy and redefining dynamic symbols is not
possible. And a stripped binary makes things harder also...

Unless you know a way to do that, I'll check in an other direction.

Big thanks Ian!
David

> 
>- Ian
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torsocks 2.x issue - Need eyes on that

2013-10-29 Thread Lunar 
David Goulet:
> Now the issue was detected with firefox which uses a custom malloc hook
> meaning that it handles its own memory allocation. This hook uses mmap()
> that firefox redefines to be a direct syscall(__NR_mmap, ...) and
> remember that this symbol is hijacked by torsocks.
> […]
> It's a bit of a catch 22 because torsocks is basically looking for the
> libc syscall symbol but then it gets call inside that lookup code
> path...

Wouldn't one way out be to also hook malloc to use a
static buffer until dlsym() is done? The code snippet in the following
answer is doing just that:


-- 
Lunar 


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torsocks 2.x issue - Need eyes on that

2013-10-29 Thread Ian Goldberg 
On Tue, Oct 29, 2013 at 03:10:50PM -0400, David Goulet wrote:
> That would work if there is a way I can "differ" the hijack of the
> syscall symbol... Unfortunately, this is done at linking time thus
> during run time, the syscall symbol is already hijacked by torsocks.
> 
> Let say we don't try to lookup the syscall symbol, the issue is that the
> original syscall libc pointer will NOT exists within torsocks code so we
> can't handle call to syscall() because we can't route it to libc. :S
> 
> It's really that we get in a kind of "infinite loop" where dlsym calls
> syscall that calls dlsym and so on. But in the first place, we at least
> need the libc syscall symbol so we can handle them.

Might it be possible to use objcopy tricks like --prefix-string or
--redefine-sym to make the exported version of syscall different from
the imported version?  Then the torsocks code could just call syscall()
as a normal libc function, linked by ld.so, but when firefox called
syscall, it would call torsocks's torsocks_syscall(), or something?

   - Ian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torsocks 2.x issue - Need eyes on that

2013-10-29 Thread Nick Mathewson 
On Tue, Oct 29, 2013 at 2:38 PM, David Goulet  wrote:

> To be honest, I am not sure what's the right fix here or if there is any
> way to lookup the symbol in a "special" way that would help here. Any
> idea or questions are VERY welcome :).

My first thought -- and I don't know how good it is -- is that perhaps
you could just *not* look at syscalls that occur during the dlsym
calls that you launch? In other words, disable the syscall override if
the current thread is already inside the dlsym() call inside your
syscall override.

Would that work?  What would it break, if anything?
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torsocks 2.x issue - Need eyes on that

2013-10-29 Thread David Goulet 
On 29 Oct (14:58:44), Nick Mathewson wrote:
> On Tue, Oct 29, 2013 at 2:38 PM, David Goulet  wrote:
> 
> > To be honest, I am not sure what's the right fix here or if there is any
> > way to lookup the symbol in a "special" way that would help here. Any
> > idea or questions are VERY welcome :).
> 
> My first thought -- and I don't know how good it is -- is that perhaps
> you could just *not* look at syscalls that occur during the dlsym
> calls that you launch? In other words, disable the syscall override if
> the current thread is already inside the dlsym() call inside your
> syscall override.

That would work if there is a way I can "differ" the hijack of the
syscall symbol... Unfortunately, this is done at linking time thus
during run time, the syscall symbol is already hijacked by torsocks.

Let say we don't try to lookup the syscall symbol, the issue is that the
original syscall libc pointer will NOT exists within torsocks code so we
can't handle call to syscall() because we can't route it to libc. :S

It's really that we get in a kind of "infinite loop" where dlsym calls
syscall that calls dlsym and so on. But in the first place, we at least
need the libc syscall symbol so we can handle them.

David

> 
> Would that work?  What would it break, if anything?
> -- 
> Nick
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Torsocks 2.x issue - Need eyes on that

2013-10-29 Thread David Goulet 
Hi everyone,

I stumble upon an issue when testing torsocks[1] with firefox. I'm still
wondering how this can be fixed thus I need more eyes on this :). The
issue is that torsocks gets into a deadlock during the initialization
phase within the libc.

Here it is. This new torsocks version hijacks the "syscall" symbol
(syscall(2)) in order to intercept applications that decides to do some
network operations with that interface. To do that, the torsocks library
constructor (executed before the application main()) lookup the original
symbol in the libc (dlopen(3)) and is used for unhandled syscall values
(for instance open(2)).

Now the issue was detected with firefox which uses a custom malloc hook
meaning that it handles its own memory allocation. This hook uses mmap()
that firefox redefines to be a direct syscall(__NR_mmap, ...) and
remember that this symbol is hijacked by torsocks.

Torsocks constructor calls dlsym() to get the original libc syscall
symbol. This call locks a "loading lock" inside the libc:

dlfcn/dlsym.c +68: __rtld_lock_lock_recursive (GL(dl_load_lock));

Just after, dlerror_run is called which does a calloc() which then calls
the firefox malloc hook and calls syscall() for mmap that torsocks
hijacks. In torsocks, syscall() make a check on the original libc
syscall pointer to see if it's NULL or not and if NULL, tries to look it
up with dlsym(). And there you have the deadlock.

dlsym --> LOCK --> dlerror_run --> calloc --> syscall() --> dlsym() -->
dlerror_run --> DEADLOCK.

It's a bit of a catch 22 because torsocks is basically looking for the
libc syscall symbol but then it gets call inside that lookup code
path...

To be honest, I am not sure what's the right fix here or if there is any
way to lookup the symbol in a "special" way that would help here. Any
idea or questions are VERY welcome :).

Hope this explanation is clear enough, this is a "not that trivial"
issue.

Cheers!
David

[1] https://github.com/dgoulet/torsocks.git


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] REMINDER: Buoyant Otter outreach, training, & documentation in an hour.

2013-10-29 Thread Tom Lowenthal 
Tor psyops group,

We'll be meeting in #tor-dev in just under an hour to scheme, plan,
and otherwise prepare out ongoing outreach, training, and
documentation efforts.

See y'all in an hour.
-Tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Help me guague how full your plate is via regular check-in conversations

2013-10-29 Thread Tom Lowenthal 
Hello fighters for freedom,

When applying for grants, planning future work, and otherwise thinking
about what capacity we have leftover to do things in the future, it's
really useful to know who's doing what and how much of it. I get some
of this information from our sponsor/project-specific meetings, but it
doesn't seem to be the full picture, so I'd like to trot out that old
chestnut of regular one-on-one chats.

This means that I'd like to spend between thirty and sixty minutes
talking with each of you, once every week or two. I'd like to
calibrate the frequency so that we can get calls down to 30 minutes
each, with room to kvetch and have a conversation that's a little more
than just rattling off deliverable status and time assignments.

I think that the right group for this is the folks who post to
tor-reports. If you post to tor-reports, please get back to me by the
end of the week with your availability for a regular weekly check-in,
as well as any thoughts you have about medium, format, or anything
else. If you're not currently on tor-reports and think you should
check in, or vice versa, you should probably drop me a line too.

Any questions or suggestions?

-Tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev