How can I be sure that I am using the real Facebook?

Question

I type www.facebook.com into my browser's address bar and press enter, then use Facebook.

Could I actually be visiting a fake Facebook even if I see a URL of https://www.facebook.com and a lock icon by the side of the address bar?

Answer 1

You can confirm that you're on the real Facebook by a variety of ways:

1. Inspect the certificate used to secure the site. Open up your certificate (instructions vary by browser) and see what it says - is it issued to Facebook? Is it in a valid time period? Now, look at who signed that certificate, again, turn a critical eye towards it. Make sure everything makes sense. Go down the certificate chain until you get to the root certificate. Now, go to your favorite search engine and check that none of the certificate vendors have been in the news for a compromised private key. Unfortunately, the CA based ecosystem means you have to just trust the root CA, to some degree.

2. Check the IP address you're connecting to - use your favorite NSLookup tool to see where your DNS is pointing you when you connect to facebook.com. Take that address to google, see if it matches what people commonly say Facebook's public IP address is.

3. See if other people have recently reported issues connecting to Facebook over TLS, or have any concerns. Consider if those concerns seem valid to you, or if they seem like the user is just doing something incorrectly.

Next, take all the data you've gathered from the above points, and any other reconnaissance you've done. Think critically about whether you think it's reasonable that all of the above has been faked by a convincing virus, evil malicious actor on your network, or Mark Zuckerberg having a laugh. Also consider that the issue you want to avoid (submitting or viewing information from Fakebook rather than Facebook) and think if it's possible that the eventual consequences (data leak) could happen in another way, such as a screengrabber or keylogger virus running and just recording your input into the real Facebook. Then, consider if the risk outweights the value you'd gain from logging into Facebook. Then realize that Facebook gives you no value and decide it's not worth the risk.

Answer 2

This is exactly the problem that HTTPS is designed to solve. If you visit Facebook (or any other site for that matter) using a URL that starts with https:// (not http://), then there are a number of security measures your browser will automatically employ to make sure that the site it connects you to really is the one displayed immediately after https:// in the URL bar, and warn you if it's not.

Let's briefly go over these security measures so that you will have a better understanding of how they work and the conditions under which they are effective (or ineffective).

How Domain Names Work

When you first visit a URL like https://www.facebook.com/ the first thing your browser will do is extract the site's domain name from the URL you provided. The domain name is the portion of the URL that comes after "https://" at the beginning of the URL, and before the next "/". In this case, the domain name is "www.facebook.com".

Within the domain name there are multiple labels separated by periods (.). The rightmost label, in this case, com, is the top-level domain. The label to the left of that, in this case facebook, is a subdomain of the top-level domain (.com), and any other labels to the left of that, such as www, are subdomains controlled by that domain's owner. So while a domain like secure.facebook.com is controlled by Facebook (since they own the facebook.com domain name), a different domain like www.facebook.com.login.site would be controlled by whoever owns the login.site domain (probably not Facebook).

This is important for you to understand, because while https://www.facebook.com/ is the correct URL for Facebook, https://other.site.com/www.facebook.com is not, nor is https://www.faceb0ok.com/, https://www.faceboook.com/, or https://www.facebook.com.secure.site/. If the domain name you see in the URL bar does not end with exactly facebook.com, your browser will not know that you really mean to connect to Facebook, and therefore cannot protect you from connecting to a different site that's only pretending to be Facebook.

Domain Name Verification

Once your browser has the domain name of the site you visit, it will connect to that site using a process known as a TLS handshake. (Again, this is assuming you're visiting the site over https.) As part of this process, the server you connect to (whether the real server or a fake one) must present your browser with a special file known as a TLS certificate. This file must contain a signed statement from a third party known as a Certificate Authority which your browser already trusts. The statement will tell your browser what cryptographic key to use when contacting the website you requested, and your browser will ask the server you connected to (whether real or fake) to prove that it controls that key before it sends any further information to that server.

Because the TLS certificate has to be signed by a third party your browser already trusts, the server you're talking to cannot fake the information in that certificate. And because the certificate contains the real key of the server you're trying to contact (in our case, facebook.com), a fake server won't be able to convince your browser that it is legitimate and your browser will display a warning to you, telling you that the site you're connecting to might be fake.

For more on this process, see How does SSL/TLS work?.

But is that enough?

Can your browser be tricked into loading a page from a fake version of Facebook even if the URL bar says https://www.facebook.com/?

Under normal circumstances, no. Provided you check that you are using https and that the domain name is the right one, these built-in protections will usually be enough to ensure you really are talking to the real facebook.com.

There may be rare circumstances however where someone might be able to impersonate Facebook despite these protections. For example, if you install a custom trusted Certificate Authority on your computer, the owner of that Certificate Authority may be able to impersonate Facebook. At work, your employer may have done something like this already to your work computer, so use caution when browsing the web with a computer you do not own. (Same goes for computers at a school or library.) Malware on your computer might also be able to install its own certificate authority or bypass your browser's protections some other way.

There are also other, more uncommon ways an attacker might be able to trick your browser into connecting to a fake facebook.com, such as compromising a Certificate Authority trusted by your browser, but I won't go into those methods in detail, as they are very unlikely.

If you suspect that, despite these protections, your browser may be connecting to a fake facebook.com without warning you, you might be able to find out if that is the case using some of the methods explored in Adonalsium's answer, but even those methods are in no way foolproof.

But again, for most users, verifying that you are connecting over HTTPS and that the domain name displayed in the URL bar is correct should be enough for you to be reasonably sure you are indeed talking to the real Facebook.

Answer 3

The fact that the URL is https:// (where s stands for security) and that the browser displays the lock in the URL-bar is the proof. This means that the HTTPS protocol is used, where the websites has to provide a certificate proving their identity. So as a user, you need to make sure that HTTPS is used and that you are on facebook.com and not something else (like faceb00k.com).

However, if your device has been hacked or is controlled by someone else (e.g. your employer) you can not be sure about this (or anything, for that matter).

Answer 4

Just to complement the already very good answers, and to follow a bit on user21820's comment above, you build trust by parts and by analyzing.

I just wanted to point out that a basic point of your security setup in the situation you describe is the browser. Whoever wrote the code of the browser you are using has complete liberty of showing you that you are accessing www.facebook.com and displaying the green certificate while connecting you with whatever site they want. You would detect this situation by sniffing the ip traffic from your computer, but not by looking at the browser.

In the end, we all use a setup where we are trusting different persons/companies/institutions: whoever wrote the operating system, whoever installed it, whoever wrote the bios and other firmware in your hardware, whoever wrote the browser, the certificates installed in your system, etc. Most common setups are well-known so that they are more or less trustable, but more than anything we put our trust in numbers: if Microsoft or Google or a computer manufacturer had their software directing to dubious sites or stealing sensitive information, or if Mozilla installs an unsafe certificate, someone among the millions of users would likely notice one way or the other. It doesn't make it impossible for shady things to happen in your system or mine: just unlikely.

Answer 5

The original question can have two aspects. One is "is my data ending up on the real facebook ?". In other words, am I on the site of an imposter ? The other one is: "could there be a MITM attack that is snooping on my connection ?".

In both cases, when the "green lock" appears in the browser, and we assume that the browser is not compromised, and has the right CA certificates, the answer to the question is equivalent to: "could any one of the trusted CA have produced another certificate with the domain name "facebook.com". Now that's a hard question to answer, because in order to be able to verify this, one should in principle need to be able to see ALL certificates issued by ALL trusted CA, which is impossible, as they are not written down in any form of block chain or the like. The token block chain was exactly invented to solve the problem of "proving no double spending" which is akin to the problem of proving "no double certificate".

An argument in favour of CA not doing such would be that a CA's business depends on being trusted, and hence on users not ever finding out that they were tricked by a rogue certificate issued by said CA. If several facebook users would complain that they ended up on fakebook, that would be the end of that CA's business. This is a valid argument to have some trust that CA don't sign certificates to fakebook. However, it is not an argument against CA signing certificates for MITM snoopers (say, state-sponsored snoopers). There is no way to find out if the MITM is just snooping.

With a MITM snooper, at the end of the day, you are really connected to the real facebook of course, but you have no way of knowing whether you're been snooped doing so. I don't know what aspect the original question was emphasising: ending up at facebook but being snooped, or ending up on fakebook. The "CA reputation" only matters for the second aspect.

Answer 6

HTTPS is fairly good but if you are in China you'd hope they have not altered the SSL root CA cert authority such that you get a different result. I guess you could compare that with Google's 8.8.8.8 public DNS results?

http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/

Answer 7

There have been already many excellent answers. I would like to tune in from yet another viewpoint. When taken to the extreme, this becomes philosophical, and you have to draw the line somewhere:

• Does "Facebook" as I think I know it, even exist for real ?

• If it exists, what on earth could it be ?

• How many different Facebooks might exist ?

• Is there a real person by the name of Zuckerberg ? Is he really the boss of Facebook ? Does he have a twin brother ?

One can end up in total solipsism that way, if one puts every piece of received information (by your brain) in doubt. At a certain point, you will have to accept a "hypothesis of reality". That is the anchor of trust for the rest of the authentication information. Maybe you know Mark Zuckerberg in person: you could ask him the true public keys in the certificates of Facebook. But maybe you only know about a thing called "Facebook because other people talked you about it. In that case, how do you know you are on the same Facebook as what they were talking about it ?

So in the end, you might say that you don't care about the absolute nature of Facebook: what matters, is that the "Facebook" you're dealing with, is the same one you were initially dealing with upon first learning about it. If there is, in reality, a genuine second (and even a third, fourth...) "Facebook" out there, but one of them is the one your friends showed you for the first time to make an account, and you can contact them, the only thing you want, is that you are later in contact with the same Facebook as initially. So if you get a public key from one of your friends, that is the public key of the Facebook your friends are using, that's in principle good enough. If your friends were, all of them, systematically, the constant victim of a MITM attack, well, it doesn't matter: that MITM is your Facebook: an entity on the internet. Nobody said that that Facebook was a nice entity...

So, for entities on the internet, what matters often is relative authentication: the proof that you are contacting in successive sessions, the same entity than you contacted the first time. You may realize that apart from the coherence of entity over different contacts, you don't know much about the entity you're contacting.

It can be different if you need the entity to be also a legal moral person that you might like to sue if ever it behaved badly towards you. You should then, strictly speaking, obtain a certificate from the legal instance that has the power of jurisdiction over the entity you'd like to contact, the moral person behind "Facebook". This can be the case if you contact a business partner on the internet, which you don't know apart from the fact that he's on the internet, say, a store on the other side of the world.

Finally, there's a third possibility, and Facebook most probably falls into this category. You want to contact the entity "everybody knows and is well-known". The different channels by which an entity is "well-known" should then also be used to spread the public key of that entity: printed journals, television, different web sites, etc... If the same public key is distributed systematically and coherently by several other entities you also know somehow, you have a strong web-of-trust that signals that you can trust that public key to be the right one of Facebook. This is something that doesn't really work well for relatively unknown entities, because its "web of trust" needs to spread wide enough that it touches different actors you already know and trust which only works for well-known entities. I'm living in Europe, and I'd have a hard time obtaining a web of trust around me that could convince someone in Sidney to be absolutely sure he's dealing with me.

So we have 3 different categories of authentication of entities on the internet, depending on the use case:

• relative authentication: I don't know who you are, but you're the same entity that I contacted earlier

• legal authentication: I can only trust the legal issuer of identities

• web-of-trust authentication: "everybody" knows who it is through different channels, so this is the way to obtain the correct public key: the one everybody is using consistently.

A real-world use case may need the 3 aspects: I want to connect to the "well-known" Facebook "everybody knows" (even if there's a bar somewhere in Kazakhstan called "facebook", that's not the one I want to contact) ; I want to contact the same Facebook upon successive logins (even if there has been a selling of the brand name to another entity, say). And if ever Facebook behaves badly, I want it to be a moral person that I could, eventually, sue in court.

As such, the trust we seem to put in CA is somewhat overdrawn, because we blindly trust entities (CA) to have verified this without checking ourselves, and independently of our use case. After all, maybe the bar in Kazakhstan also has a certificate for "Facebook.net". But it is easier and better than nothing.