Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Er. To interpret what I said the way you did, is to assume I was saying "Tor does nothing, and clients connect directly to servers", which is kind of... silly, to say the least.

The point I was making was that the proximate node to the hidden service--the last one in the onion-routing chain--connects to its destination by using its public IP to talk to the hidden service's public IP. From the perspective of the hidden service, the node proximate to it in the onion-routing chain is a regular Internet peer, which is impossible to distinguish from any other regular Internet peer.

In the end, what Tor gives you is a proxy (to a proxy, to a proxy.) And, from the server's perspective, there's no difference between a proxy and a regular client. It can't tell, by the IP, that the client it's speaking to is a proxy. And because of that, you cannot, at the server-level, block non-proxied clients from speaking to you. Because you don't know which those are.



It's not a proxy in the way you are describing. The node (onion router) most proximal to the hidden service is always connected to by the hidden service, not the other way around.

Thus it is absolutely fine to firewall off all inbound connections on the host running the hidden service, as it will only be making outbound connections - and even those are to a limited set of IP addresses as defined by the guard nodes it has chosen for entry into the Tor network.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: