

Onion Pi - Make a Raspberry Pi Into a Anonymizing Tor Proxy - christphrdunder
http://learn.adafruit.com/onion-pi?view=all

======
nikcub
Tor being pitched as a one-stop privacy solution like this is going to
backfire bad at some point in the future. It is good that they have the
warning about cookies, but there are a hell of a lot of other ways you can be
identified.

You simply shouldn't be using the same machine you use with your real identity
with an identity that needs to be anonymous. Even simply things like ntp time
sync request can give you away, let alone features like Windows Update (which
will definitely give you away since they send a machine ID), browser
fingerprinting, evercookies, etc.

Nobody can think of all the different things a machine can send that need to
be blocked or reset, which is why you just use a fresh new machine. It is the
_only_ way to use Tor safely.

Any device that makes it easier to use Tor with your existing computer is bad
for privacy. Especially something being pitched as an 'on/off' switch for
instant privacy.

edit: A good setup is the following: install virtualbox, install a light-
weight linux distro as a tor router, setup a private and isolated network
behind it and then install your 'client' operating system on that private and
isolated network in a second virtual machine. Never use the same client
machine for long and use the virtual machines snapshot feature to blow away
your data every x hours/days (and never use the suspend feature of virtual
machine software, it saves your memory (with passwords, keys, etc.) onto
disk).

~~~
dfc
_Even simply things like ntp time sync request can give you away_

I'd really like to hear more about this one.

Murdoch's hot-or-not required a lot more than an ntp sync request and was
concerned with identifying hidden services.

~~~
nikcub
The theory is that the frequency of requests, timezone, server being used and
time skew (see also[1]) provide enough bits of information to identify a
client.

The exit node or ISP could also forge a response and set the clock a unique
amount of time out of sync which can later be identified over a non-anon
network.

Whonix, the privacy oriented Linux distribution which uses two virtual
machines (an isolating proxy and then a client on a private network) disable
NTP by default and require the user to sync time out-of-band because of these
concerns. There is a section in their docs about NTP[2]

[1]
[http://www.reddit.com/r/onions/comments/10usgv/clock_skewing...](http://www.reddit.com/r/onions/comments/10usgv/clock_skewing_a_clever_unconventional_means_of/)

[2]
[http://sourceforge.net/p/whonix/wiki/Advanced%20Security%20G...](http://sourceforge.net/p/whonix/wiki/Advanced%20Security%20Guide/#network-
time-synchronization)

~~~
dfc
At first glance the first two paragraphs are hand wavy enough that it is
pretty clear that you exaggerated when you said "simply ntp synch requests"
and things get a lot worse after paying any attention to the details in your
post.

Timezones and NTP? NTP does not use time zones so I am not sure what that has
to do with anything.

Exit nodes forging ntp responses? That is going to be pretty tough. Last time
I checked tor has a tcp fetish and ntp is squarely in the udp camp.

I checked the reddit link. Lets skip over the fact that you said "identify a
client" and the reddit link is about hidden services. In order to work it
requires that the hidden service serves http, serves http over plain ipv4, and
is running on a computer that is also a relay. So that is not "simple" but
most importantly it has very little to do with ntp requests.

I'm not going to lie, I stopped reading the whonix documentation after the
first three paragraphs and i have pasted them below:

    
    
      Don't wonder... To prevent against time zone leaks, the system clock
      inside Whonix was set to UTC. This means it may be a few hours before
      or ahead of your host system clock. Do not change!
    
      On the host. If you were a user of TorBOX 0.2.1 or below and removed
      NTP, restore it now.
    
        sudo apt-get install ntpd
    

Can you see why I stopped reading when I did? It seems like you may have
disremembered the details of the "simple ntp synch requests" can give a way a
users identity attack.

------
dfc
Some people who are running tor on their pis are getting messages about your
computer being to slow. If you see these messages and are curious about the
cause arma posted a good explanation today to tor-relays:

 _The current theory is that these happen when your relay becomes the hidden
service directory, or introduction point, for a popular hidden service. So
these are basically roving hotspots that move around the network. In the case
of the hidden service directory the pain lasts about a day, and in the case of
the introduction point, it lasts for some function of the duration of the
introduction point (could be a while) and the time that the hidden service
descriptor is fresh (15 minutes or so). Based on the logs here, it sounds like
it might be the introduction point in these cases.

Here are some tickets to look at:

[https://trac.torproject.org/projects/tor/ticket/3825](https://trac.torproject.org/projects/tor/ticket/3825)

[https://trac.torproject.org/projects/tor/ticket/4862](https://trac.torproject.org/projects/tor/ticket/4862)

[https://trac.torproject.org/projects/tor/ticket/8950](https://trac.torproject.org/projects/tor/ticket/8950)

Also, the switch to the new ntor circuit-level handshake should reduce the cpu
requirements for create cells (in addition to being more secure). So once more
people have switched to ntor, these hotspots shouldn't be so bad. It is
unclear if that's the same as 'shouldn't be bad'. :)

[https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposa...](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/216-ntor-
handshake.txt*)

Full context:

[https://lists.torproject.org/pipermail/tor-
relays/2013-June/...](https://lists.torproject.org/pipermail/tor-
relays/2013-June/002184.html)

------
CoffeeDregs
[Might I hijack this thread? Yes? Thank you.]

OT: I looked at adding a TOR proxy to my personal VPS and pretty quickly
decided against it __* since it 's tough to limit the proxy to _legitimate
traffic_. By "legitimate traffic", I mean traffic for people who _really need_
privacy. By "really need", I don't mean Bittorrent (yes, I use it, too, but
I'll deal with the consequences), porn, etc.

I'm really not interested in running a bunch of not-mine-but-pisses-off-
Comcast traffic on my cable modem, but I'd love to run a TOR proxy. Anyone got
any pointers on running an effective, not-annoying proxy?

Back on topic: if I can sort the question of how to limit not-awesome traffic,
I'd happily run a TOR exit node on my Linode and I'd buy a Rasperry Pi to run
one at home.

__*[https://forum.linode.com/viewtopic.php?t=7328](https://forum.linode.com/viewtopic.php?t=7328)

~~~
dfc
If node operators could pick and choose whose traffic they carried tor would
not be what it is.

If you dont want to handle the stress of dealing with exit traffic run a relay
only node:

[https://www.torproject.org/docs/faq.html.en#ExitPolicies](https://www.torproject.org/docs/faq.html.en#ExitPolicies)

~~~
CoffeeDregs
Agreed, but one can hope, yes? For example, if I could probably kill not-
interesting traffic if I could traffic-shape the traffic (e.g. you can't run
more than 10kB/s averaged over 60 seconds through my node, which is plenty to
browse the web securely but isn't enough to download Star Trek 2.) The
question remains: are there ways to _manage_ (not prevent) this issue?

~~~
dfc
No, I don't hope. If relay operators can "peel back the layers of my onions"
and see the traffic the entire security model is out the window.

Edit: I just saw your restatement of your question. Check out the bandwidth
management features and set your relay to only allow exit traffic to port 443.
More info on the bandwidth management can be found here:

[https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#Wha...](https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#WhatbandwidthshapingoptionsareavailabletoTorrelays)

~~~
gizmo686
The security model of Tor allows the exit nodes to see all the traffic in
'plaintext' (indeed, the design of Tor requires it). What the security model
requires is that the exit nodes not be able to identify who sent the packets
originally.

I put "plaintext" in quotes because they can only see what you want to send to
the server, which could be encrypted outside of the context of Tor.

Although I think it is illegal to spy on the data you pass as an exit node, a
point that is often not said is that by the design of Tor, you are showing
some random person the content of all of your requests, which opens up a whole
new attack vector for eavesdropping and man-in-the-middle attacks.

------
CWilliams1013
See also: The Grugq's PORTAL of Pi project:
[https://github.com/grugq/PORTALofPi](https://github.com/grugq/PORTALofPi) and
its cousin for OpenWRT-based personal routers:
[https://github.com/grugq/portal](https://github.com/grugq/portal)

------
malandrew
This is really cool because if plug-n-play tor devices become cheap enough to
be disposable, then I can see people just adding them to open wi-fi networks
with bandwidth caps in order to increase the number of tor exit nodes, which
is actually pretty low for such a vital service. Last time I checked there
were like 800-1000 exit nodes in existence.

------
frakkingcylons
If you want to run a headless Tor relay, I highly recommend using this
graphical monitoring client called 'arm'

Link: [http://www.atagar.com/arm/](http://www.atagar.com/arm/)

------
iuguy
If you're going to do this, please act as a tor relay (not a public relay) by
adding something like this to your torrc:

    
    
        ORPort 9001
        BridgeRelay 1
        Exitpolicy reject *:*

------
zokier
I can understand people already owning the necessary hardware doing this, but
buying $95 kit which essentially makes for a lousy WLAN router seems bit odd.
Surely it would make more sense to buy purpose-built WLAN router (for $95 you
can get quite fancy one), and install Tor on that?

------
synchronise
Out of curiosity, would there be much point in swapping out Tor for i2p in
this sort of setup?

~~~
stuaxo
I think this can work, I'm fairly sure I got this working on kurobox (another
ARM based computer) - you need to find a java implementation + you're good to
go.

