4 ms·
If your plan was to remain anonymous on FB, it would. But that's not what their .onion service is for. The ingenuiety of the hidden service is that FB basicall
by bostik 11y ago
If your plan was to remain anonymous on FB, it would. But that's not what their .onion service is for.
The ingenuiety of the hidden service is that FB basically inverted Tor's idea. Tor is really good at bypassing restrictive net filters, while at the same time it hides your browsing destination. So in effect FB turned a Tor address into their own highly resilient web proxy. Where a proxy normally provides a guarded way out of a network, the hidden service provides an otherwise untraceable way in.
Now, technically it is ~possible to identify FB-Tor traffic from regular Tor traffic. At least in some sense. Because the address is inside the .onion network, there are only half as many routing hops between the client and the server. So if you, as a well funded governmental adversary, first identify nearly all Tor traffic, you can then see which clients receive their responses notably faster than the rest.
These faster roundtrips are very likely using hidden services. If you then drill down even further, I am sure you should be able to identify a reasonably large fraction of your own subjects who are clearly accessing FB and thus stepping around the nationally imposed censure.
For the record, Alec didn't consider the above traffic analysis attack particularly feasible. And we both agreed that the straightforward solution is to get a lot more traffic for hidden services in general. Once FB is not the sole huge site with a hidden service, their traffic cannot stand out.
- ikeboy 11y agoWhat? Hidden services use 6 hops compared to regular traffic's three. They are slower.
- pg_is_a_butt 11y agomaking someone hop 6 times before a marathon is also slower than running a marathon without hopping 6 times first. the guy that hopped 6 times first didn't get run over by a car right out of the gate. lucky coincidence.
- bostik 11y agoOh sorry, the context was missing. This came up in a discussion we had. FB is proposing (and funding) development that would make hidden services faster. One of the measures would be to make [some?] hidden services reachable over 3 hops only. A quick search does not bring anything on the topic up, but it can easily be that I try to search for wrong key words.
- ikeboy 11y agohttps://tor.stackexchange.com/questions/9485/decrease-number-of-hidden-service-hops https://tor.stackexchange.com/questions/9485/decrease-number... links to some proposals for doing so. I thought I remembered something on the Tor blog about that, but didn't find it. But anyway, why would a hidden service with 3 hops look different than a clearnet site visited over tor and 3 hops?
- bostik 11y agoNormally it wouldn't. But as I understand, in FB's case the last hop will be served by a fleet of extremely well connected, high-bandwidth edge nodes. And I would be sorely surprised if they didn't have peering agreements in practically all internet exchanges. So under the faster onion routing, when accessing FB.onion your roundtrip is total of 6 hops. Hops 3 and 4 will be made to an edge node network, so the "last hop in" and "first hop out" will be, on average, faster. Even if the circuit was reconfigured midway through the session, the fast innermost hop would still exist.[~] It's just another timing attack, with passive traffic analysis. I wonder how much one could do with active attacks. ~: I have no knowledge how FB has configured their Tor network connectivity, but I do know that the private key is not held on a single termination point. (The traffic volume is too much for a standalone node.) Hence I am making an educated guess that their onion address is advertised from multiple edge systems.
- ikeboy 11y agoBut there's still no difference between visiting FB.onion under a 3-hop system and visiting Google or Netflix or any of the many sites that have distributed servers. (I suppose that different protocols are being used that have different times, but that seems negligible; wouldn't bet on that though.)
- bostik 11y agoIn that case it looks like I have misunderstood the last hop for hidden services. When using a public site over Tor, the connection looks like this: 1. User connects to a relatively nearby entry node (guard) [hop #1] 2. Guard node routes the packet via a relay [hop #2] 3. Relay routes the packet to an exit node [hop #3] 4. Exit node routes the packet out of the Tor network, and has responsibility for finding the actual destination. Even for a globally available high-traffic site the route from exit node to the nearest edge node has to travel across a couple of networks. Now, under the proposed 3-hop hidden service protocol - when user accesses a hidden service, I had understood that the "exit node" is replaced by the hidden service itself. So the connection would look like this: 1. User connects to a nearby guard node [hop #1] 2. Guard node routes the packet to a relay [hop #2] 3. Relay node routes the packet to the hidden service [hop #3] 4. There is no step four. The packet has been delivered to its destination network. For a random hidden service this probably wouldn't matter much, but if/when the third hop is provided by a globally accessible edge network, the latency between relay and final destination should be quite good. With the elimination of post-Tor routing steps, and with the constantly better latency from relay to the hidden service, I expect the overall latency for this particular Tor circuit to be measurably lower. After all, there are no public hops beyond the circuit termination nodes. So from traffic analysis point of view, Tor/FB traffic should stand out from other Tor traffic. And I think I found some references, at last. Search for "Direct Onion Services: Fast-but-not-hidden services" draft discussion on tor-dev archives.