Facebook and TOR address question

[rogerver]

I just noticed that Facebook's custom onion is: https://facebookcorewwwi.onion/

That leads me to a few questions:

1. Is all but the last character custom?
2. If so, does that mean that with an obtainable amount of processing power, intentional Tor address collisions are possible?
3. What does that mean for the security of accessing such sites?

Some related discussions here: https://www.reddit.com/r/onions/comment ... _hardware/

[GaryDavisIRL]

I just noticed that Facebook's custom onion is: https://facebookcorewwwi.onion/

That leads me to a few questions:

1. Is all but the last character custom?

I believe only the "facebook" section of their .onion address is custom. As you know, the more custom characters you attempt to mine, the more difficult it is. From what I've read, they mined a number of addresses with the 'facebook' prefix and chose the most suitable / most easily remembered.

2. If so, does that mean that with an obtainable amount of processing power, intentional Tor address collisions are possible?

Intentional Tor address collisions are definitely possible, yeah. If you look at Roger Dingledine's blog post on Facebook setting up a .onion address [https://blog.torproject.org/blog/facebo ... ttps-certs], there's a very well set out comment beneath it which I've quoted here, with the relevant section in bold/italic:

Comments on part four:

There's another reason for wanting to have https to an onion address: guarantee that no other .onion site is proxying/MITMing the service's data stream, by showing that the .onion address has a key actually possessed (or at least authorized) by the one who owns the site.

The entire reason for third-party certification in TLS is to guarantee that you're talking with who you think you're talking to. Sure, Tor is self-authenticating, in that you can guarantee you're talking with "someone who has access to the key necessary to claim the .onion address". This is useful in a lot of circumstances. But, when your adversary can carry out low-cost attacks (such as low-cost ad campaigns which claim that access to your service can be gained at a particular .onion address that your adversary holds the private key to), it becomes much more important to have a third-party attestation of just who is providing the service, and who actually possesses the private key in question.

It is possible to use TLS without a server certificate. However, the web browser threat model is basically "the secure website must not be impersonated or transparently proxied". This is why web browsers specifically do not permit uncertified TLS. (Of course, there's a lot of legitimate anger that this works as an extortion racket; I personally support having multiple user interfaces for unauthenticated versus unauthenticated keyed versus third-party certified versus third-party extended validation, so that site operators can choose for their own sites what threat level they're willing to impose on their users, and turn it into an uncoerced market. Ultimately, .onion addresses provide unauthenticated-keyed connections, even though the browser doesn't understand how to provide any kind of useful UI with it.)

Right now, the CA/Browser Forum is debating how or even whether to put .onion addresses in TLS certificates. The debate appears to hinge on the idea of "alternate DNS roots", which are alternate entry points into alternate directories to look up names versus IP addresses. These have already existed, and have already had name-collision problems when ICANN chose to authorize new root names under its system that alternate DNS root providers had already allocated. A short-term fix for this could be for Tor to approach ICANN to ensure that it will not allocate a new .onion TLD, thus reserving it for the Tor network, for some (renewable) number of years. I don't know how likely this might be. This would cause some problems down the road, though, for other onion-routing topologies and softwares.

There's a couple of alternatives for how to handle certification of the .onion address. Certifying the .onion key at the Tor layer is not useful, because Tor does not have a certification field. This means that the certification of a Tor key would have to assign that key to the webserver as well; there's no communication between the web browser and the Tor software to verify that the key used for the .onion address and the certificate presented by the webserver even match. (Cryptographic digests inherently suffer a vulnerability called the "birthday attack": multiple messages can exist that compute to the same digest value. It is always important to check if the key itself matches, without simply checking that the digest itself matches.)

And please, get out of the thought that only the Tor browser is going to be used with Tor. Other protocols can use it, and other browsers can be used with it after setup; you can bet that as Tor catches on with service providers, other browsers are going to configure themselves to use Tor.

.onion name certification alternative 1: Certify the .onion key, and require the TLS server to have access to that specific certified key as the certificate for the TLS endpoint. I don't recommend this option, because it would increase the risk of that specific key being compromised and the "brand" of the .onion name being rendered worthless. It also flies in the face of good webserver key hygeine, which suggests that after a period of time you should always rekey your webservers.

.onion name certification alternative 2: Rely on the fact that the .onion name is already hashed and cryptographically bound to that key, and use that hash as the "proof of authority to use the name". Then, include the .onion name in a standard certificate over a separate keypair. I believe that this would be more secure and would lessen the potential risk to the brand, by reducing the attack surface against the name key. However, there are potential additional caveats to this option, as well. One is that CABF has deprecated SHA1 as providing less of a security strength than it is comfortable with. Another is that .onion addresses only encode half of the SHA1 in the first place, thereby halving the security strength that CABF is already uncomfortable with.

CABF is risk-averse and caveat-averse. Remember that Facebook could mine 40 bits of the SHA1. Computers are only becoming faster and more capable, and mining hashes efficiently is a known problem with documented approaches. This means that before too long 80 bits are going to be able to be mined cost-effectively, and Facebook's .onion name is going to suffer a collision. What will it do when that happens? (A bit of back-of-the-envelope arithmetic suggests that if every person on Earth [7.125 billion in 2013, according to Google] had a computer that could calculate 20-bit digest collisions in 8 seconds, like @ErrataRob on Twitter claimed that his did, it would take 20.58 minutes to try 2**40 possibilities. This doesn't mean that a collision would be found in 20.58 minutes, but the numerical possibility doesn't bode well in light of botnets and zero-day vulnerabilities.)

Ultimately, Tor is going to need to switch to a stronger digest algorithm, and encode more bits into the name. This is for the security of everyone, including the services who operate .onion servers. Determining how it's going to approach this problem should be a priority; as Tor is the de-facto manager of the .onion namespace, though, it's vital that it have a plan to do so. This will become even more important if/when ICANN officially allocates the management of the .onion TLD to Tor.

Ultimately, I'd like to see .onion be deprecated, for a .tor TLD that addresses the issues. The amount of work that would need to go into this, though, may be prohibitive.

3. What does that mean for the security of accessing such sites?

Some related discussions here: https://www.reddit.com/r/onions/comment ... _hardware/

Can't be of any help there, I'm afraid!