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.
But anyway, why would a hidden service with 3 hops look different than a clearnet site visited over tor and 3 hops?
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.
(I suppose that different protocols are being used that have different times, but that seems negligible; wouldn't bet on that though.)
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.
Anyway, skipping the third hop would decrease user anonymity, because you'd only need two relays to cooperate to identify the user and who they're connecting to. Regular tor requires all three to cooperate.
The proposal uses a rendezvous point instead of an exit node, but that shouldn't affect speed as far as I see.
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.