Hacker News new | past | comments | ask | show | jobs | submit login

> 5. The adversary's guard can observe the hidden service's IP directly.

So does the guard know that it is a guard and that the traffic comes from a hidden service? I thought Tor worked by jumping from node to node, and that each node didn't know whether the traffic came from the original client/service or from another node in the chain. So each time you make a connection over Tor you're essentially telling a guard node "here's my real IP, send this traffic to this hidden service and return the response please" and you have to trust that they keep it a secret? I feel like I'm missing something here.




The Tor protocol doesn't explicitly signal the guard relay that it is in the guard position. However, the guard relay (call it R) can use several indicators to conclude that the preceding hop (call it S) is indeed the source (e.g. the onion service):

1. S is at an IP address that is not a public Tor relay as listed in the Tor consensus. It's not impossible that S is a bridge (i.e. private Tor relay), but statistically unlikely because using a bridge isn't all that common.

2. During circuit construction, S extends the circuit beyond R two times. I don't see why Tor couldn't easily create dummy circuit extensions to fool R, but it doesn't (probably because there are so many other indicators that this change alone wouldn't solve the problem).

3. R observes what appear to be HTTP-level request-response pairs between it and S at about the same round-trip time (RTT) as the RTT R observes between it and S at the TCP layer, which should only happen if there were no more hops beyond S.

If I recall correctly, Kwon et al. [0] describe several more statistical indicators of being a guard for an onion service.

Also, you are right that a client doesn't tell the guard node the destination (e.g. the onion service) of its traffic. The guard node is not trusted with that because it already directly observes the client, and so giving it the other side would deanonymize the connection.

[0] https://www.usenix.org/conference/usenixsecurity15/technical...




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

Search: