Supporting the Anonymous Use of Facebook via Tor | Hacker News Reader

Supporting the Anonymous Use of Facebook via Tor

blog.digicert.com

64 pointslambada29 comments

So Facebook can get a .onion cert, but normal people can't? That's a little annoying.

I wonder whether the same effect could be had by using a self-signed cert - would work especially well with a phone app which could pin whatever cert it wanted.

A .onion cert is pretty useless though, besides being revocable I guess. Access to .onion domains is already secured.

Certs don't secure the connection; they establish the identity of the server you're connecting to (i.e. trust).

This should help that. You can be more confident that it's not being man in the middled.

The point is that you should already be confident, because the .onion address itself establishes the identity of the server.

.onion establishes the identity of the key. If they ever lost control of the key and had to replace it, they would need a new .onion domain.

One use:

On https://example.com/ I add:

  <script src="//example.onion/x.js"></script>

x.js contains:

  alert(
      "I notice you can access Tor hidden services. We have"
    + "a hidden service address at example.onion by the way"
  );

The only way this would work when you are using SSL on example.com is if you are also using SSL on example.onion.

That sounds like a flaw that the Tor Browser Bundle should fix by treating all URLs from .onion domains like they treat https: URLs.

TBB is just a repackaged Firefox, I don't think they make any changes or patches to the actual browser code like that.

I had a friend that used the wikipedia page on the silk road to get the silk road address, and he fell for a fake version of the website (someone had changed the wikipedia entry). A cert could protect against that.

A certificate could pin an .onion key to a real entity, if the entity in question wants to do that.

But for a Silk Road-like marketplace? Uh, sure: why don't they incorporate, print business cards, lease an office, do an IPO and invite the FBI to the opening party while they're at it? ;-)

First there needs to be an accepted good way of testing whether it's the right .onion address.

Of course, it will be quite superfluous, because .onion addresses are themselves truncated hashes of keys. Tor's already looking into improving all that.

Well, isn't it the point, that the user can confirm, with help from the browser, that DigiCert has verified that this .onion address is actually Facebook? Maybe you meant something different by "right."

Also, Facebook made a "vanity address" that is pretty memorable, facebookcorewwwi.onion [0]. So, someone else could brute-force a similar address and lure people to it, but presumably they wouldn't be able to get a trusted CA to issue a cert authenticating that they're "the same entity as the one operating facebook.com" (from the article -- I presume facebook.com is also named in the cert, which shouldn't happen unless the CA vetted it.)

[0] https://lists.torproject.org/pipermail/tor-talk/2014-October...

Well, I'm sure you used "will be" advisedly -- until the improvements you mention come about, TLS to hidden services is valuable even though Tor already provides transport encryption. The keys in question aren't really appropriate for modern cryptographic practice, as the Tor developers have been acknowledging. I wrote a little more about this at

https://lists.torproject.org/pipermail/tor-talk/2014-October...

I didn't mention the part about how the public keys are 1024-bit RSA, but it adds to the sense that native hidden service transport encryption is using dated crypto.

Testing if somebody controls a particular .onion address should be quite easy. The SSL provider could just say for example: Create a temporary file containing X at http://youronionaddress/Y - If you can do that, you control the .onion and can have an SSL cert for it.

Or have them sign something with the private key for the onion address. There would also be a much lesser need for certificate revocation as anyone who has access to that private key has total control over the onion address permanently. Also, if they grab the SSL cert off the server they can probably also grab the Tor private key as well. Revocation could only be used to warn others to not trust that onion address but what we need is a way to flag your own onion address as compromised by signing some self destruct note with the private key.

One advantage of the status quo is that DigiCert won't be issuing certs for "facebookcorehttp.onion" or "facebookrotflbbq.onion" or whatever else you might be able to brute-force. If they were issuing those certs, it'd be hard to tell if you were on the actual hidden service operated by the entity known to humans as Facebook -- given how ad-hoc the name "facebookcorewwwi.onion" is, the cert isn't making a useful statement the same way a cert for "facebook.com" is.

And that's not even considering the fact that Tor's transport to hidden services implies authenticity... DigiCert is unable to usefully contribute to the claim "these people own facebookcorewwwi.onion" or "these people own facebookrotflbbq.onion" because Tor is already making that claim strongly, so the only claim they can help with is "these people are/aren't who you think of as Facebook".

If DigiCert were able to issue an EV cert for "Facebook, Inc. [US]", that would be another matter entirely, but the industry rules on EV certificates are tight, and in particular I think there are rules about being in the public DNS. I'd imagine one thing they're working on is being able to issue EV certs for .onion domains.

HBO was granted an SSL certificate by Verisign for "localhost" that was embedded in their iOS app for a while (allowing them to have the iPhone player, which had some SSL requirement I never knew much about, to connect to localhost to stream content, but let the app apply some crazy custom DRM scheme to the traffic). It was found by jan0, when he was working on a Cydia Substrate extension to backport the bug fix for one of the SSL issues that Apple had on iOS 4, and his extension died on someone's phone logging about localhost. He mentioned it on IRC and then left for lunch, so I decided it would be a fun challenge to try to grab it out; two hours later I had disassembled the code and figured out that it had a string that was like "AHdagw%@gcgAWdsa%@fGS3" that it formatted with two strings (replacing the "%@", if you don't know Objective-C), then base-64 decoded that, and used it as the password for a key file, which was something like "Amst3rd4m1sC0ld" (I remember what it said, but not the numbers/caps ;P). I knew it hadn't taken him two hours to figure this out, so I asked him how he did it, and he made fun of me for not using my own tools (in this case, Substrate) to just hook the function that you pass the password to to decrypt a key file :(.

Seeing the words "Facebook and "anonymous" together is a little odd, given how use of Facebook, and its policies, is often seen as being the exact opposite of anonymous.

I'm glad I am not the only one that thinks that this is odd. So you can browse anonymously to a site that by its very nature is built around a profile of a REAL person. What happened to just offering up the service under full TLS?

This just looks like a dirty anti-gov protest and mass publicity stunt. It offers a false and wrong sense of security to the users. We have reports of rogue TOR exit nodes that try to insert malware, and we assume that we can actually trust the owners of this infrastructure? I'm sorry, I am all for security, improvements to services that ensure people I don't want seeing my communications, can't, but this? Calling bullshit on this.

You could be a real person and not want to disclose your IP.

They are two separate things.

There's a big difference between the security of exit nodes (which see all the traffic passing through them in the form in which it travels over the Internet) and using .onion addresses, where the intermediate hosts don't see any of the data unencrypted.

To my mind, accessing the general Internet is not what you want to do with TOR -- ideally the service you want to access will also be on .onion, allowing you to avoid exit nodes. In practice, that's not going to be possible in all cases so exit nodes are a necessary evil requiring extra care.

Your country's government has been toppled by a totalitarian junta. You, as a leader of the opposition, use Facebook to mobilize the persecuted democratic counter-revolution. You don't want your government to know where you are, but you need identified access to Facebook.

There, that's why you need the Facebook .onion. You can have reason to fear the initial hops of your packets but not the destination.

It's still useful in helping people to avoid blocks on Facebook. That you're connecting to a Facebook server is still obvious over a TLS connection, but going via Tor that is hidden and your ISP can't find out.

Site down.

Cached version: http://webcache.googleusercontent.com/search?q=cache%3Ablog....

"Facebook would treat users as “hacked’ since their location would vary throughout the world. Using the .onion address prevents the lock-out from occurring."

So anybody wanting to "hack" a Facebook account should do it via Tor and use the .onion address to avoid being detected and locked out? How does that work?

I'm guessing they treat the first login via .onion as a new location and require some additional verification but subsequent ones as if they were coming from a known location. They could achieve the same by just treating all exit nodes as the same location but this looks much more elegant to me.

Why does it matter? It doesn't work!

Sorry, something went wrong

Please try closing and re-opening your browser window.

What does this even mean? How can you use facebook anonymously?

Your use to Facebook is not anonymous but your use to your local ISP or non-technologically-advanced government would be shielded.

Reply on news.ycombinator.com