OnionCat 0.1.9 now supports IPv4

[Bernhard Fischer]

We have a new version of OnionCat ready which is now capable of
IPv4-forwarding.

Read http://www.abenteuerland.at/onioncat/ for further instructions on how to 
use OnionCat and IP.


Bernhard.


signature.asc
Description: This is a digitally signed message part.

Re: OnionCat 0.1.9 now supports IPv4

[Sven Anderson]

Am 15.09.2008 um 16:16 schrieb Bernhard Fischer:


We have a new version of OnionCat ready which is now capable of
IPv4-forwarding.

Read http://www.abenteuerland.at/onioncat/ for further instructions  
on how to

use OnionCat and IP.



Does it really work in an acceptable way? I ask because "TCP Over TCP  
Is A Bad Idea"[1]. I would expect it to have an awful performance.


[1] http://sites.inka.de/~bigred/devel/tcp-tcp.html


Regards,

Sven

--
http://sven.anderson.de"Believe those who are seeking the truth.
tel:+49-551-9969285 Doubt those who find it."
mobile: +49-179-4939223 (André Gide)

Proposed student project

[Chris Akins]

Hello all.

 

I've been thinking about doing a Tor-related project for my Senior Thesis at
the University of Cincinnati, and I just wanted to check that I wouldn't be
duplicating existing efforts, that the idea makes sense, etc. The basic idea
is to build a zero-configuration Tor relay in hardware that sits between the
home user's router and their computer. Two plugs: one to the outside world,
one to the computer. 

 

The relay would automatically handle all the configuration details, and
render interception almost impossible, barring subversion of the target
machine. The hope is that being able to buy or build a tangible
plug-and-play guarantee of privacy and anonymity would drastically lower the
barriers to entry for normal (that is, non-technical) users. As a bonus,
offloading the computational burden of encryption and decryption would allow
those with lower-end machines to benefit.

 

So - does this sound at all feasible to the more experienced minds here? Am
I asking for trouble from some unsuspected quarter?

I look forward to receiving your feedback, and thank all responders in
advance. Brainstorming re: implementation is also welcome.

 

Many thanks,

Chris

Re: OnionCat 0.1.9 now supports IPv4

[Bernhard Fischer]

On Monday 15 September 2008, Sven Anderson wrote:
> Am 15.09.2008 um 16:16 schrieb Bernhard Fischer:
> > We have a new version of OnionCat ready which is now capable of
> > IPv4-forwarding.
> >
> > Read http://www.abenteuerland.at/onioncat/ for further instructions
> > on how to
> > use OnionCat and IP.
>
> Does it really work in an acceptable way? I ask because "TCP Over TCP
> Is A Bad Idea"[1]. I would expect it to have an awful performance.
>
> [1] http://sites.inka.de/~bigred/devel/tcp-tcp.html
>
>
> Regards,
>
> Sven

What somebody would define as "acceptable" may be different but basically your 
concern about it is right.

TCP over TCP is an issue which has some kind of "rubber-band" effects on the 
packet transmission but that's a problem that share all kinds of VPNs. 
Hopefully TOR will work with UDP eventually because in respect to performance 
this would give lower latencies in my opinion and would also make OnionCat 
more powerful.

Specifically with TOR and OnionCat the rubber-band effect can even be observed 
when sending pings over OnionCat (and that's ICMP over TCP ;).
I'm not sure but I think that's because of the numerous concatenated TCP 
sessions that TOR circuits are built of.

But the real biggest problem currently is the bad performance of hidden 
services in general which overlays all other difficulties.

The advantage of OnionCat is its IP-transparency and together with TOR it is 
location hidden. If someone wants or needs to use hidden services he will 
also use OnionCat, there's not really a difference in performace.

Bernhard


signature.asc
Description: This is a digitally signed message part.

Re: Proposed student project

[Roger Dingledine]

On Mon, Sep 15, 2008 at 02:12:12PM -0400, Chris Akins wrote:
> The basic idea
> is to build a zero-configuration Tor relay in hardware that sits between the
> home user's router and their computer. Two plugs: one to the outside world,
> one to the computer. 

Two thoughts come to mind immediately. First, you will want to use
Tor's transparent proxy interface with iptables / pf:
https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy

You might like Incognito's firewall rules:
https://svn.torproject.org/svn/incognito/trunk/root_overlay/var/lib/iptables/rules-save

For the software side, you should look at coderman's draft thoughts on
a self-contained Tor in a VM:
https://svn.torproject.org/svn/torvm/trunk/doc/design.html

Second, if you want this Tor to be able to act as a relay too (aka a Tor
server), it will need some non-trivial hardware. Exactly what hardware is
needed is an open question, and worth exploring more. The Tor software
development process seems to have cycles where we 1) accidentally cause
Tor to use too many resources, then 2) fix that, then go back to 1.

So some versions of Tor are much more friendly, cpu and memory wise,
than others. The current 0.2.1.5-alpha version is quite good I believe.

> The relay would automatically handle all the configuration details, and
> render interception almost impossible, barring subversion of the target
> machine.

You may find that some config details, like how much rate limiting the
user wants to put in place, are hard to guess automatically.

--Roger

Re: Proposed student project

[Jonathan Addington]

On Mon, Sep 15, 2008 at 1:25 PM, Roger Dingledine <[EMAIL PROTECTED]> wrote:
>
> On Mon, Sep 15, 2008 at 02:12:12PM -0400, Chris Akins wrote:
> > The basic idea
> > is to build a zero-configuration Tor relay in hardware that sits between the
> > home user's router and their computer. Two plugs: one to the outside world,
> > one to the computer.
>
> Two thoughts come to mind immediately. First, you will want to use
> Tor's transparent proxy interface with iptables / pf:
> https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy
>
> You might like Incognito's firewall rules:
> https://svn.torproject.org/svn/incognito/trunk/root_overlay/var/lib/iptables/rules-save
>
> For the software side, you should look at coderman's draft thoughts on
> a self-contained Tor in a VM:
> https://svn.torproject.org/svn/torvm/trunk/doc/design.html
>
> Second, if you want this Tor to be able to act as a relay too (aka a Tor
> server), it will need some non-trivial hardware. Exactly what hardware is
> needed is an open question, and worth exploring more. The Tor software
> development process seems to have cycles where we 1) accidentally cause
> Tor to use too many resources, then 2) fix that, then go back to 1.

> So some versions of Tor are much more friendly, cpu and memory wise,
> than others. The current 0.2.1.5-alpha version is quite good I believe.
>
> > The relay would automatically handle all the configuration details, and
> > render interception almost impossible, barring subversion of the target
> > machine.

Building on Roger, another point, esp. regarding interception; an
automatic (singned) binary update would be a good idea. You (or
whoever maintained the project) could simply test the latest versions
and update it when needed. (Bugs are found, performance is improved,
etc.)

Just my pseudo-developer two cents...

> You may find that some config details, like how much rate limiting the
> user wants to put in place, are hard to guess automatically.
>
> --Roger
>


--
[EMAIL PROTECTED]

Re: OnionCat 0.1.9 now supports IPv4

[7v5w7go9ub0o]

Bernhard Fischer wrote:

On Monday 15 September 2008, Sven Anderson wrote:

Am 15.09.2008 um 16:16 schrieb Bernhard Fischer:

We have a new version of OnionCat ready which is now capable of
IPv4-forwarding.

Read http://www.abenteuerland.at/onioncat/ for further instructions
on how to
use OnionCat and IP.

Does it really work in an acceptable way? I ask because "TCP Over TCP
Is A Bad Idea"[1]. I would expect it to have an awful performance.

[1] http://sites.inka.de/~bigred/devel/tcp-tcp.html


Regards,

Sven


What somebody would define as "acceptable" may be different but basically your 
concern about it is right.


TCP over TCP is an issue which has some kind of "rubber-band" effects on the 
packet transmission but that's a problem that share all kinds of VPNs. 
Hopefully TOR will work with UDP eventually because in respect to performance 
this would give lower latencies in my opinion and would also make OnionCat 
more powerful.


Specifically with TOR and OnionCat the rubber-band effect can even be observed 
when sending pings over OnionCat (and that's ICMP over TCP ;).
I'm not sure but I think that's because of the numerous concatenated TCP 
sessions that TOR circuits are built of.


But the real biggest problem currently is the bad performance of hidden 
services in general which overlays all other difficulties.


The advantage of OnionCat is its IP-transparency and together with TOR it is 
location hidden. If someone wants or needs to use hidden services he will 
also use OnionCat, there's not really a difference in performace.


Bernhard


Is there a performance difference between IPv4 and IPv6 (TCP over TCP)? 
I'd presume none; and I'd also presume that a UDP vpn would work fine.


(Thanks for developing OnionCat!)

Fwd: Post Confirmation 807ccc3983b12bd9

[Jonathan Addington]

Can someone explain why I get this message every time I post? Or
delete whatever email address sends this back to me?

I don't post often, but it is annoying when I do.


-- Forwarded message --
From: TypePad <[EMAIL PROTECTED]>
Date: Mon, Sep 15, 2008 at 1:36 PM
Subject: Post Confirmation 807ccc3983b12bd9
To: [EMAIL PROTECTED]


Reply to confirm your message with the subject of:

   Re: Proposed student project



-- 
[EMAIL PROTECTED]

Re: OnionCat 0.1.9 now supports IPv4

[Bernhard Fischer]

On Monday 15 September 2008, 7v5w7go9ub0o wrote:
> Bernhard Fischer wrote:
> > On Monday 15 September 2008, Sven Anderson wrote:
> >> Am 15.09.2008 um 16:16 schrieb Bernhard Fischer:
> >>> We have a new version of OnionCat ready which is now capable of
> >>> IPv4-forwarding.
> >>>
> >>> Read http://www.abenteuerland.at/onioncat/ for further instructions
> >>> on how to
> >>> use OnionCat and IP.
> >>
> >> Does it really work in an acceptable way? I ask because "TCP Over TCP
> >> Is A Bad Idea"[1]. I would expect it to have an awful performance.
> >>
> >> [1] http://sites.inka.de/~bigred/devel/tcp-tcp.html
> >>
> >>
> >> Regards,
> >>
> >> Sven
> >
> > What somebody would define as "acceptable" may be different but basically
> > your concern about it is right.
> >
> > TCP over TCP is an issue which has some kind of "rubber-band" effects on
> > the packet transmission but that's a problem that share all kinds of
> > VPNs. Hopefully TOR will work with UDP eventually because in respect to
> > performance this would give lower latencies in my opinion and would also
> > make OnionCat more powerful.
> >
> > Specifically with TOR and OnionCat the rubber-band effect can even be
> > observed when sending pings over OnionCat (and that's ICMP over TCP ;).
> > I'm not sure but I think that's because of the numerous concatenated TCP
> > sessions that TOR circuits are built of.
> >
> > But the real biggest problem currently is the bad performance of hidden
> > services in general which overlays all other difficulties.
> >
> > The advantage of OnionCat is its IP-transparency and together with TOR it
> > is location hidden. If someone wants or needs to use hidden services he
> > will also use OnionCat, there's not really a difference in performace.
> >
> > Bernhard
>
> Is there a performance difference between IPv4 and IPv6 (TCP over TCP)?
> I'd presume none; and I'd also presume that a UDP vpn would work fine.
>
> (Thanks for developing OnionCat!)

No, there's no difference. It's more or less the same code.
As I wrote before UDP would perform better but I have no influence on that -- 
TOR is based on TCP.

Bernhard


signature.asc
Description: This is a digitally signed message part.

Re: Proposed student project

[Kyle Williams]

 Hello Chris,

My response is inline with the message thread.


On Mon, Sep 15, 2008 at 11:25 AM, Roger Dingledine <[EMAIL PROTECTED]> wrote:

> On Mon, Sep 15, 2008 at 02:12:12PM -0400, Chris Akins wrote:
> > The basic idea
> > is to build a zero-configuration Tor relay in hardware that sits between
> the
> > home user's router and their computer. Two plugs: one to the outside
> world,
> > one to the computer.
>
> Two thoughts come to mind immediately. First, you will want to use
> Tor's transparent proxy interface with iptables / pf:
> https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy


Yup, this is what you want to use.


> 
>
> You might like Incognito's firewall rules:
>
> https://svn.torproject.org/svn/incognito/trunk/root_overlay/var/lib/iptables/rules-save
>

Incognito has a couple of good additional rules which might be of use.


>
> For the software side, you should look at coderman's draft thoughts on
> a self-contained Tor in a VM:
> https://svn.torproject.org/svn/torvm/trunk/doc/design.html
>

Based on the best transparent Tor solution, this is a must read! ;)


>
> Second, if you want this Tor to be able to act as a relay too (aka a Tor
> server), it will need some non-trivial hardware. Exactly what hardware is
> needed is an open question, and worth exploring more. The Tor software
> development process seems to have cycles where we 1) accidentally cause
> Tor to use too many resources, then 2) fix that, then go back to 1.
>

I've been working on a 400MHz StrongARM XScale PXA255 CPU, 16MB of Flash
storage, and 64MB of RAM, and 2 x 100Mbps Ethernet ports.
With better memory management with the newer 2.x alpha versions of Tor, this
seems very realistic now.
Right now TorVM can run as a client on as little as 16MB of RAM, so I think
64MB will cover it.
I believe coderman has been using the TorVM as a server, so he would have a
better answer as to how much RAM it uses running as a server node.

The benchmarks[1] for crypto on this are as follows (sorry if the spacing is
off).
   16 bytes64 bytes256 bytes   1024
bytes  8192 bytes
aes-128 cbc 3113.35k3187.56k3207.59k
3206.59k3213.99k

 sign  verify sign/s  verify/s
rsa 512  0.0162s 0.0016s 61.9635.0
rsa 10240.0946s 0.0053s 10.6190.2
rsa 20480.6269s 0.0190s 1.6 52.7
rsa 40964.4033s 0.0700s 0.2 14.3

Running a server would be possible, but it would be much slower than if you
ran it on your P4.
In it's current state, it take about 60 seconds to boot.


>
> So some versions of Tor are much more friendly, cpu and memory wise,
> than others. The current 0.2.1.5-alpha version is quite good I believe.
>

So far, it has been very good with the memory usage compared to older
version which consumed hundreds of MB.


>
> > The relay would automatically handle all the configuration details, and
> > render interception almost impossible, barring subversion of the target
> > machine.
>
> You may find that some config details, like how much rate limiting the
> user wants to put in place, are hard to guess automatically.
>

There are a few things that you may want to take into consideration:
- How would you configure the device in different environments? (Work vs
Home vs On the road).
- How do you handle being behind a proxy?
- What if the router on the LAN is using MAC filtering?
- What if you want to run a hidden service?
- How do you update it?

I've been focused on this for awhile now, and have solutions to most of the
questions people find themselves asking about this type of implementation.
The goal has been to get the same level of transparency that you see in
JanusVM or TorVM into hardware.
As a matter of fact, I got my first build for the hardware working last
night.  Funny you should ask about this today! :)
Next step is to bring Tor 0.2.1.5-alpha into the build (on today's to-do
list).
The last step will be the Universal User Interface with different Profiles
(work, home, etc..), and it'll be finished.

I'm hoping for my Tor on a stick by this weekend!
(Fingers crossed as builds take about 1.5 hours to complete and bugs are a
bitch)

Best Regards,

Kyle

[1]  http://docwiki.gumstix.org/index.php/Benchmarks

Re: Fwd: Post Confirmation 807ccc3983b12bd9

[Alexander W. Janssen]

Jonathan Addington wrote:
> Can someone explain why I get this message every time I post? Or
> delete whatever email address sends this back to me?

You're maybe posting not with the same email-address as you subscribed.

> I don't post often, but it is annoying when I do.

Maybe it's just that.

Alex.



signature.asc
Description: OpenPGP digital signature

Re: Proposed student project

[coderman]

On Mon, Sep 15, 2008 at 12:17 PM, Kyle Williams
<[EMAIL PROTECTED]> wrote:
> ...
> I believe coderman has been using the TorVM as a server, so he would have a
> better answer as to how much RAM it uses running as a server node.

i have been able to run a middle node with 32M guest VM (8M free below
32M limit in OS) for days.  dir cache and exit will increase this, as
does the amount of traffic.

i know some people have used quite a bit less for client only on
routers with 8-16M, and others who need a lot more memory for their
high traffic nodes.  sorry i don't have more quantified results; your
mileage will vary :)

best regards,

NoScript 1.8.1: tor integration (finally!)

[Marco Bonetti]

Looks like the "torbutton vs noscript" war has come to an end ;-)
After pinging Maone about this issue some times ago[1] and, more
important, after the PdP incident[2][3], which probably start it all,
we've now a new "https" feature for NoScript which will enable only
scripts from trusted secure sites, it can be turned "always on", "always
off" or "When using a proxy (recommended with Tor)".

Go out and test this feature!
(and, maybe, update the FAQ[4] :-P )

ciao

[1]: http://archives.seul.org/or/talk/Aug-2008/msg00181.html
[2]: http://hackademix.net/2008/08/14/petko-was-playing-with-fire/
[3]: http://hackademix.net/2008/09/10/noscript-vs-insecure-cookies/
[4]: https://www.torproject.org/torbutton/faq.html.en

-- 
Marco Bonetti
Slackintosh Linux Project Developer: http://workaround.ch/
Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/
My webstuff: http://sidbox.homelinux.org/

My GnuPG key id: 0x86A91047