1M People Use Facebook Over Tor
151–160 of 168 posts
Re: 1M People Use Facebook Over Tor
#152Earlier quoted context omitted.
Normally 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 h…
But 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.)
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.
Re: 1M People Use Facebook Over Tor
#153Alec Muffet has done a lot of work to get Facebook running on TOR and he's a true believer. I really enjoyed working with him when I was at Facebook. He also did a lot of work to get .onion domains to be recognized by registrars as a special purpose domain name. This let us issue certificates on .onion. I don't know if the story behind the facebookcorewwwi.onion domain name itself has been talked about much, but we w…
It took me only 24 hours and about $200-300 in compute to hit Blockchains hidden server key which is: blockchainbdgpzk.onion I'm pretty sure it's the second most trafficked site after FB If anyone is looking at setting up a hidden service and wants a memorable name I still have the cluster setup. Matching 10 characters isn't much of a challenge - it's why hidden service addressed on their own don't provide identity a…
Re: 1M People Use Facebook Over Tor
#154It's funny that they say people use Tor "for a variety of reasons related to privacy, security and safety". They left out "firewall circumvention", which I have to believe is the #1 reason, at least in China.
Re: 1M People Use Facebook Over Tor
#155Earlier quoted context omitted.
That's really interesting. Are you able to tell us how long those 500k cores were running for before the facebookcorewwwi.onion name was found?
We generated many candidates beginning with facebook, so I don't recall when that one was found--it just happened to be the one that looked the best. There's a number of backup memorable domains that we kept the keypairs for just in case facebookcorewwwi gets compromised somehow. I don't remember how long we ran it for, but IIRC we had enough candidates to stop after a week or two. I'm guessing something like 100-200…
Re: 1M People Use Facebook Over Tor
#156Earlier quoted context omitted.
The name of .onion address is the hash of a public key, so you can't choose it, or rather the only way is to generate random public and private key pairs and to keep the one that interest you. Facebook must have generated an awful lot of key pairs to get "facebookcorewwwi". By the way, I hope they deleted the other generated pairs…
I have good faith that they didn't, or certainly not all of them. When Alex described the entire process they went through, he also smirked that should that primary key ever get compromised they have several others, almost as good, ready as drop-in replacements. I do think he also mentioned that they only cared about keys that had their required prefix; all others were destroyed without anyone ever having access to t…
Re: 1M People Use Facebook Over Tor
#157I've recently tried using FB via TOR (Browser) for the first time, but was unable. After entering the onion address and my FB credentials, I was informed that the account is temporarily blocked (presumably because of first access via TOR). I was presented with an option of unblocking it by recognizing a few photos of friends and matching them to names - but unfortunately, all those photos showed as blank, white squar…
Re: 1M People Use Facebook Over Tor
#158I've recently tried using FB via TOR (Browser) for the first time, but was unable. After entering the onion address and my FB credentials, I was informed that the account is temporarily blocked (presumably because of first access via TOR). I was presented with an option of unblocking it by recognizing a few photos of friends and matching them to names - but unfortunately, all those photos showed as blank, white squar…
Report this as a bug and it will get routed to Alec and promptly fixed. The issue here is that constructing the page requires pullling from different places (cdn, etc) and sometimes someone changes the way things are set up internally to deliver this and the person making the changes is not aware of the mods needed to deal with the .onion support.
Re: 1M People Use Facebook Over Tor
#159Earlier quoted context omitted.
Report this as a bug and it will get routed to Alec and promptly fixed. The issue here is that constructing the page requires pullling from different places (cdn, etc) and sometimes someone changes the way things are set up internally to deliver this and the person making the changes is not aware of the mods needed to deal with the .onion support.
As I said, I've already reported as a bug via FB, weeks ago, haven't heard from anybody since then. Is there some other way I should use? As to the root cause, that's what I suspected, and it also tells me that the TOR gateway seems not well covered by tests and thus prone to breaking. And you won't know, as TOR users have no way to report in-band.
Re: 1M People Use Facebook Over Tor
#160Earlier quoted context omitted.
But 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.)
In 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 actu…
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.