I have just started operating a relay on top of the hidden service I had been operating. I started because I want to give back at least as much bandwidth as I use, but it also occurred to me that it might offer increased traffic analysis resistance.
I’m hoping someone more experienced with the network can go over my reasoning.
An onion service chooses two middle relays, as does the client connecting to it. As I uderstand it, those relays don’t know their position in the chain. But an adversary using a bad relay to try and track can infer when it is the last in the chain forwarding to an onion service, because it can see the destination IP address isn’t on the relay list. So when tor is operating solely as a service, my upstream relay knows it’s sending to a service and can log that and use that knowledge to assist with traffic analysis.
However, when I’m operating as a relay plus service, my IP is on the relay directory list, and the upstream relay has no way to tell if it’s sending a packet to a relay or a service. This, along with the increased traffic anyway, may help with traffic analysis resistance.
Is this a correct assessment?
One thing to note is that activity with relays are public things, and up/down history or coarse traffic statistics are public in general, and probably many adversaries will be watching your relays.
This means that uptime patterns for your onion services are correlated with high confidence with the public relays you are running.
Hi, just butting in to this topic, qs I want to do the same, not for security but because I have limited hardware. Is this safe? Can I run it on the same tor instance?
Possibly running a separate Tor instance helps a bit.
Ive just tried it out. It works fine, and yes, I think it would help to some degree, but only if you were an entry or exit node, because the authorities would know if you connected via tor to an address that wasnt another relay. That being said, that last part only applies if your service has to make requests outside of Tor. Otherwise, yes, from what Ive seen it does help.
1 Like
Local instance for the relay and Docker Instance For onion service should be enough. Docker for onion services with limited privileges, with Sandbox 1 option and basic security rules such as a web server pointing to localhost and no open ports in the clearnet of the services exposed as onion As minimum requirements and recommendations, they cannot correlate traffic in 6 hops for onions and 3 for relays if it is well isolated and the circuits change every 10 minutes.
My original premise was flawed, and there is very little, if any benefit to running the relay and hidden service together.
My original premise was this: The final relay before a packet is sent to a hidden service would always be able to tell if it was sending that packet to a hidden service by virtue of the fact that the final hop is being sent to a node that is not an IP on list of relays. By running a relay, you could take away that distinction.
However, as I understand the protocol, a significant weakness in it is that as each relay unwraps a layer from a packet, the packet decreases in size. Tor cell sizes are uniform to start, so each and every relay knows what position it holds in the chain. A relay therefore always knows when it is sending a packet as the final packet to a hidden service simply from how many layers have been unwrapped.
This is, in my view, a fairly significant weakness in the tor protocol and allows bad actor relay operators to collect a lot of data. A relay operator may not know what .onion address is associated with the hidden service it is sending a packet to, but it will always be able to know it is sending to one and that is very useful data for traffic correlation.