How can Facebook's Tor Onion be constantly accessible with the massive bandwidth demand?

Question

Background: (you can skip if you already know the details of Facebook's Hidden Service) In 2014, Facebook unveiled their Tor Hidden Service that let people from restricting governments access Facebook freely (because Facebook was being blocked in many key countries).

Tor is a networking protocol that routes any TCP traffic through 3 random servers (that are voluntarily run by any individual so that it remains decentralized) in layers of encryption, slowly stripped down until the exit node, where all Tor-based encryption is finally stripped by the node and sent on to it's destination, which sends data back through the circuit in reverse. This is what most people use Tor for, however there is another (apparently not very well known) feature called Hidden Services.

A Tor Hidden Service (I call them Onion Services, Tor Onions, or just Onions) is, in a nutshell, a computer that is running the Tor software with certain configurations enabled that allow them to run a Hidden Service (which is as easy as un-commenting 2 lines in the centralized configuration file). This "opens up" virtual ports in a virtual firewall that allow anyone with a certain address (a 16-character string of random numbers and letters ending in .onion, calculated by the hash of the Onion Service's public RSA key) to connect to the service anonymously, being routed instead through 6 Tor nodes and meeting in the middle, called a rendezvous (where the connection never actually leaves the Tor network and is truly end-to-end encrypted). This makes it so that the Onion Service knows nothing of the user's location, and the user knows nothing of the Onion's location. For anybody in between, it's practically impossible to detect the location or even interaction of either the user or the Onion service.

The user is able to find the Hidden Service by using the address in the distributed hash table, hosted by Tor Nodes who elect to host them by enabling an "HSDir" flag, because the Hidden Service published a "descriptor," a small file that includes very basic information (the Onion's public key, and a bit of signed data that includes very important information [what this question is really about]: introductory nodes). The introductory node is a very important node (an Onion service chooses 3 of them) that is the only node that is in between all traffic that flows between Tor users and the Tor Hidden Service. It is the node that "introduces" the Hidden Service to the network.

Okay now to the actual question

There have been known attacks that can temporarily take down Hidden Services, namely one where any Tor node can set itself up to be a Hidden Service's introductory point at a given time. From there, they can deny all traffic that goes to the Hidden Service, effectively taking it offline.

Now the internet is filled with crappy people. That being said, why don't people do this to big-name Onions constantly, like Facebook? Or even why don't the governments attempting to block Facebook in their country attempt to take down these measly 3 nodes that control the entire connection to Facebook through Tor?

Okay okay, assuming that this is just because people like facebook and don't want to disrupt it, why isn't this happening with other hidden services, like The Pirate Bay, or The Imperial Library of Trantor? Are there safeguards against this attack of which I'm unaware of?

Assuming that there are safeguards against it that popular Onion Services use, there are still only 3 nodes that control the entire connection to a service, and Tor is known for being extremely low-bandwidth. So how can only 3 (randomly selected) introductory nodes support the massive bandwidth going towards Facebook's Onion?

I mean, the only reason Facebook made this available was so that people from other countries could access Facebook, so there is an entire country-worth of people going through only 3 weakly-connected nodes. How can facebookcorewwwi.onion possibly be constantly available and fast?

--EDIT-- Apparently I was mistaken; there is no attack that allows a Tor node to place itself in a position allowing itself to become the introductory node of a Hidden Service. I was thinking of a similar attack on Hidden Service Directories instead. This could still have an effect on the uptime of a Hidden Service, as the HSDir could refuse to serve the descriptor, but with the use of a program such as OnionBalancer, this becomes increasingly difficult as more HSDir nodes hold the descriptor. Thank you for this information, canonizing ironize.

Answer 1

First of all to entirely deny service to an onion service you'd need to take 6 positions in the hidden service directories hashring constantly.

You need to generate long term identity keys for all 6 of them and be able to obtain the HSDir flag, which requires a specific amount of uptime and stability, I believe currently >=96 hours (#17660). This means you need to calculate the keys to put yourself in the correct position on the hashring to act as all 6 HSDirs 96 hours prior to you getting into position.

Now, that's not infeasible but the attack is actually incredibly obvious, the HSDirs not serving descriptors published to them can easily be observed and tested, this would make your relays "bad" and they could be investigated and ejected from the consensus and you'd be back to square one, so you may be able to perform the attack but it wouldn't be incredibly efficient. It would certainly be disruptive, though.

This attack still works, in spite of using OnionBalance (more on that later). The solution to this, in the next generation of onion services, is that there will be a randomized element in the consensus, a random number generated by the directory authorities. This random number will be put into the mix when deciding which HSDirs to publish to and fetch descriptors from. This random seed in every consensus makes it impossible to calculate ahead of time which keys you'd need to control to get in position, since you can't know in advance what the random value will be.

The directory authorities are already generating and publishing this shared random value, it can be seen here, in anticipation of next generation onion services being made available. More on shared random and other improvements and work being done for the next generation onion services can be found on this blog post.

OnionBalance helps balance the load of people connecting to an onion service, by spreading the load over multiple Tor instances. By taking the introduction points for multiple onions and republishing them under one unifying onion identity, when a client picks an introduction point at random from the descriptor it in effectively picks one of the multiple Tor instances at random. This both helps balance load and protects against attempts to denial of service the introduction point. The descriptor for the facebookcorewwwi onion has 10 introduction points, currently. This is something that can be engineered against by the service provider, unlike the number of HSDirs which needs to be shared between client and service so they are able to know where to look to find the correct descriptor.

Other options that are available to improve the performance, in cases like Facebook's where they may not deem it important to hide the location of the server but just want to gain the benefits of an onion service, is to use Single Onion services. If configured, the server will connect directly to the clients offered rendezvous point without building a full circuit first. This helps reduce and latency in the building of the circuit and potential overloading of a chosen guard. For more information see the announcement blog post (where Shared Randomness was also first announced and added).