Hacker News Reader

Comment by praptak | Hacker News Reader

If I ever set up a hidden service I'll make sure it lives on a box that has no public IP whatsoever. Preferably a physical box.

View on HN

Unfortunately, the technology you need to do that is not yet finished: https://trac.torproject.org/projects/tor/ticket/9498

ETA: I should have said "one possible technology"; there may be others, but I am pretty sure that an IP-less Tor node requires that you play the Tor Bridge game and stream the Tor protocol over a non-IP link. I have had a prototype of this design running, but have yet to have it to a point I consider robust.

This looks like it's unrelated.

praptak didn't say IP-less, but no public IP. If the server has an IP in the 192.168.1.X range, that doesn't tell an attacker much, supposedly.

how?

The simplest case is trivial. You place the hidden service box (HSB) and the Tor gateway (TG) on private IP space, and deny the HSB all connectivity to anything except the TG.

Ideally you actually place the HSB and TG in different network segments so packets from the HSB must pass through a router to get to the TG and vice-versa, ensuring a compromised HSB has no possibility of sniffing any incriminating broadcast traffic to/from the TG.

Then you shill your service with a pseudonym connected to your real name so they find you anyway

All of the stuff that I expect to leak or get hacked lives on box A in a private network. The second host in this network would be the Tor gateway B, hardened, stripped down of any unnecessary stuff. Its only function would be to route traffic to/from A into Tor. Obviously it would have to be connected to the public internet but at least it would have much less software that can be hacked.

As an additional security measure, B could live behind a firewall that only let connections to Tor nodes. (yup, it might be a PITA to set up.)

Not that big a PITA, I don't think. People already use Tor exit node lists to block activity from Tor exit nodes, you're kind of just looking for the inverse.

Shouldn't be hard to create a script to generate e.g. iptables rules that permit connections to Tor public relays.

The security benefit is a bit marginal, though. The public relay list is basically world-writable.

Entire operating systems like Whonix already exist to deliver that kind of security.

We're really talking about two different kinds of "security" here. There's blocking access to anything but a Tor gateway (including in the case of a compromise at the kernel level), and blocking access by the Tor gateway to anything but Tor relays.

But that raises another point I'd neglected. On the Tor gateway, you can block access to the public internet by anything other than the Tor process.

The security benefit against maliciousness is iffy, since the most likely route of compromise for a Tor gateway that's been set up with even a little care is the Tor process, but it certainly reduces the chance of accidents.

How do you actually target the Tor gateway machine though? You can attack a Hidden Service, because there must be a webserver that responds to requests. The Tor gateway just passes traffic from the network to your client device.

How do you actually target the Tor gateway machine though?

Not the OP, and I don't know much about Tor's protocol, but at a guess one might start with deliberately malformed layers of the onion, so you route through a Tor entry node, the outer onion layer is removed, then the packet is forwarded to a Tor relay.

The Tor relay then unwraps the next layer of the onion, but the data within that layer is deliberately malformed to trigger a bug in the Tor code running on that relay.

There's a lot of work that goes on both before and during that "just".

Bugs can exist even in code most of us would consider trivial. The Tor daemon is definitely not trivial, and the project itself points out that it needs work![1]

Here[2] is "just" container.c from the Tor project. It's one very small part of the project that does fairly simple things any professional developer ought not have much trouble understanding.

It's almost 1600 lines. Are you telling me you can guarantee there are no bugs of potential security significance in that file?

They also want to make Tor even more multithreaded than it already is[3]. Threaded code never has bugs, right?

Any software is a potential attack vector. Tor is no different.

[1] https://www.torproject.org/getinvolved/volunteer.html.en#tor...

[2] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/...

[3] https://www.torproject.org/getinvolved/volunteer.html.en#use...

To be fair: 1600 lines is relatively small.

You could probably proof it from anything but business-level error.

Reply on news.ycombinator.com