Facebook on TOR. There is an explanation.

Today Facebook revealed his hidden service that allows users to access your website more carefully. Users and journalists have asked us for our answers; here are some points to help you understand our opinion.

Part one: Yes, visiting Facebook on Tor is not a contradiction

I didn't realize I should include this section, until today I heard from a journalist who was hoping to have a quote from me on why Tor users wouldn't even use Facebook. Leaving aside the (still very important) questions about Facebook's privacy habits, their harmful real-name policies, and whether or not they should tell you anything about you, the key here is that anonymity is not just hiding from your destinations.

There is no reason to let your ISP know when or if they are visiting Facebook. There is no reason for Facebook's upstream ISP, or any agency that monitors the Internet, to know when or if they are visiting Facebook. And if you choose to tell Facebook something about you, there is still no reason to let them automatically discover the city you are in while doing so.

Also, we must remember that there are some places where Facebook cannot be accessed. Some time ago I spoke to someone from security on Facebook who told me a funny story. When he first met Tor, he hated it and feared it because he "clearly" intended to undermine its business model of learning everything about its users. Then suddenly Iran blocks Facebook, a good chunk of the Persian population on Facebook switched to accessing Facebook via Tor, and he became a fan of Tor because otherwise those users would have been hacked. Other countries like China followed a similar pattern after that. That shift in his mind between "Tor as a privacy tool to allow users to control their own data" and "Tor as a communications tool to give users the freedom to choose which sites to visit" is a great example of the diversity of Tor usesWhatever you think about what Tor is for, I guarantee there is a person who uses it for something you haven't considered.

Part two: we are happy to see a wider adoption of hidden services

I think it's great for Tor that Facebook added an .onion address. There are some compelling use cases for hidden services: for example those described in «using Tor's hidden services for good«, As well as the upcoming decentralized chat tools like Ricochet where each user is a hidden service, so there is no central point to spy to save data. But we haven't publicized these examples much, especially compared to the publicity that the “I have a website the government wants to shut down” examples have had in recent years.

The hidden services they provide a variety of useful security properties. The first - and the one most think - because design uses Tor circuits, it is difficult to discover where the service is located in the world. But the second, because the address of a service is the hash of your key, they are self-authenticating: if they type in a given .onion address, your Tor client guarantees that it is actually speaking to the service that it knows the private key that corresponds to the address. A good third feature is that the rendezvous process provides end-to-end encryption, even when application-level traffic is unencrypted.

So I'm excited that this Facebook move will help continue to open people's minds to why they would want to offer a hidden service, and help others think of more new uses for the hidden services.

Another good implication here is that Facebook is committing to taking its Tor users seriously. Hundreds of thousands of people have been successfully using Facebook on Tor for years, but in today's age of services like Wikipedia who choose not to accept contributions from users who care about privacyIt's refreshing and encouraging to see a large website deciding that it's okay for its users to want more physical security.

As an addendum to that optimism, it would be sad if Facebook added a hidden service, had a problem with trolls, and decided that they should prevent Tor users from using their old address. https://www.facebook.com/. So we should be vigilant in helping Facebook continue to allow Tor users to access them through any address.

Part three: your vain address doesn't mean the world is over

The name of your hidden service is "facebookcorewwwi.onion". For being the hash of a public key, it sure doesn't seem random. Many people were asking how they could do brute force over the entire name.

The short answer is that for the first half ("facebook"), which is only 40 bits, they generated keys over and over again until they got some whose first 40 bits of the hash matched the string they wanted.

Then they had some keys whose names began with "facebook," and they looked at the second half of each to choose those with pronounced and therefore memorable syllables. The "corewwwi" one seemed the best to them - meaning they could come with a history on why it's a reasonable name for Facebook to use - and they went for her.

So to clarify, they wouldn't be able to exactly produce this name again if they wanted to. They could produce other hashes that start with "facebook" and end with pronounceable syllables, but that's not brute force on the entire name of the hidden service (all 80 bits). For those who want to explore math further, read about the «birthday attack«. And for those who want to learn (please help!) About the improvements we would like to make to the hidden services, including stronger passwords and names, see «hidden services need affection" Y the Tor 224 proposal.

Part four: What do we think about an https certificate for an .onion address?

Facebook didn't just put up a hidden service. They also got an https certificate for their hidden service, and it is signed by Digicert so their browsers will accept it. This decision produced some spirited discussions in the CA / Browser community, which decides what kind of names can have official certificates. That discussion is still in development, but these are my early views on this.

For: We, the Internet security community, teach people that https is necessary and that http is scary. So it makes sense that users want to see the string "https" up front.

Con: The .onion handshake basically gives all of that for free, so by encouraging people to pay Digicert we are reinforcing the certification business model when perhaps we should continue to demonstrate an alternative.

For: https actually offers a bit more, in the case where the service (Facebook's server farm) is not in the same place as the Tor program. Remember that it is not a requirement that the web server and the Tor process be on the same machine, and in a complicated configuration like Facebook they probably should not be. One could argue that this last mile is inside your corporate network, so who cares if it's not encrypted, but I think the phrase "ssl added and removed there" will end that argument.

Cons: If a site gets a certificate, it will further reinforce to users that it is "necessary", and then users will start asking other sites why they don't have one. I worry that a fad will start where you need to pay Digicert money to have a hidden service or they will not think it is suspicious - especially since hidden services that value their anonymity would have a hard time having a certificate.

An alternative would be to tell Tor Browser that .onion addresses with https don't deserve a scary pop-up warning. A more meticulous approach in that direction is to have a way for a hidden service to generate its own https certificate signed with its onion private key, and tell Tor Browser how to verify them - basically a decentralized CA for .onion addresses, since they are auto- authenticators. Then they wouldn't need to go through the nonsense of pretending to see if they can read emails on the domain, and generally promoting the current CA model.

We could also imagine a model of pet names where the user can tell their Tor Browser that this .onion address "is" Facebook. Or the more straightforward approach would be to bring a list of "known" hidden service bookmarks into the Tor Browser - such as our own CA, using the old / etc / hosts model. That approach would raise the political question of which sites we should support.

So I haven't made up my mind yet on which direction I think this discussion should take. I support the "we teach users to check https, so let's not confuse them", but I also worry about the slippery situation where getting a certification becomes a required step to have a reputable service. Let us know if you have any other compelling arguments for or against.

Part Five: What's Left to Do?

In terms of both design and safety, hidden services still need affection. We have plans for improved designs (see the Tor 224 proposal) but we don't have enough funds or developers to make that happen. We were talking to some Facebook engineers this week about the reliability and scalability of the hidden service, and we are excited that Facebook is considering putting in development effort to help improve the hidden services.

And finally, speaking of teaching people about the security features of .onion sites, I wonder if "hidden services" isn't the best phrase here anymore. We originally called them "hidden location services," which was quickly shortened to just "hidden services." But protecting the location of the service is just one of the security features they have. Maybe we should have a contest to raffle a new name for those protected services? Even something like "onion services" can be better if they force people to learn what they are.