4 ms·

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.

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.

dublinben 12y ago
Entire operating systems like Whonix already exist to deliver that kind of security.
- nknighthb 12y ago
  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.
  - dublinben 12y ago
    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.
    - nitrogen 12y ago
      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.
    - nknighthb 12y ago
      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#torCleanup https://www.torproject.org/getinvolved/volunteer.html.en#tor... [2] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/container.c https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/... [3] https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores https://www.torproject.org/getinvolved/volunteer.html.en#use...
      - kxo 12y ago
        To be fair: 1600 lines is relatively small. You could probably proof it from anything but business-level error.

dublinben 12y ago

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

nknighthb 12y ago
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.
- dublinben 12y ago
  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.
  - nitrogen 12y ago
    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.
  - nknighthb 12y ago
    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#torCleanup https://www.torproject.org/getinvolved/volunteer.html.en#tor... [2] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/container.c https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/... [3] https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores https://www.torproject.org/getinvolved/volunteer.html.en#use...
    - kxo 12y ago
      To be fair: 1600 lines is relatively small. You could probably proof it from anything but business-level error.