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?

  • 54
    Hmmmmm... How can you be sure that you are using the real Security StackExchange and not something set up to deceive you by providing you false answers? Even if it is the real Security StackExchange, how can you be sure that the answers you get are good, and not upvoted by many meat-puppets? At the end of the day, you need to gradually build a trusted base of information yourself, and evaluate every piece of information (including all in this thread) critically, and then come to your own conclusions. Similarly, how can you be sure that there is no intentional backdoor in your browser???
    – user21820
    Commented Dec 2, 2017 at 7:08
  • 4
    Furthermore, Lenovo once installed a fake certificate that allows any attacker to decrypt all your HTTPS connections (arstechnica.com/security/2015/02/…). Dell did the same stupidity a short while later (extremetech.com/computing/…).
    – user21820
    Commented Dec 2, 2017 at 7:13
  • 2
    An interesting thought is raised by a colleague of mine who says that his home connection is advertised at 200mbps but his PC has only a 100mbps network card. When he uses fast.com he sees around 80mbps, when he uses speedtest.net he sees 200mbps. Makes me question if his ISP is giving him their own version of speedtest which always shows the advertised rate. I'm not naming the ISP because I've not witnessed it myself so I don't want to make any assumptions or claims to that effect. But I suppose in theory it's possible, and there's not really anything we can do about it
    – Darren H
    Commented Dec 2, 2017 at 13:10
  • 10
    Do the posts seem insipid and inane? If so, it's probably the real Facebook. Commented Dec 3, 2017 at 6:39
  • 1
    How can you be sure that you are using the real Facebook and not some shady side designed to collect your personal data and sell it to advertisers? Oh wait...
    – user130549
    Commented Dec 4, 2017 at 13:21

7 Answers 7


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.

  • 2
    "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." Or even Facebook themselves recording the info you put into the real Facebook.
    – JMac
    Commented Dec 1, 2017 at 19:10
  • 47
    "Take that address to google" How do I know that the website I'm connected to is Google? Commented Dec 1, 2017 at 19:11
  • 4
    @JMac While it can't be taken as a fact, I'm wording my answer as though the user implicitly trusts Facebook with their information. Commented Dec 1, 2017 at 19:30
  • 5
    @EmilioMBumachar Conceivably MZ has the resources to tell someone to set up an entirely fake Facebook that is indistinguishable from the real Facebook, and redirect a specific inbound IP to that server instead. It's the fake Facebook, you could be talking with paid Facebook employees trying to deceive you, and you have no real way to tell that you've been routed to a different web server. Commented Dec 1, 2017 at 19:37
  • 7
    @EmilioMBumachar I cannot tell if "Fecebook" is an accidental or intentional typo (and, if intentional, I can't tell whether it's a example of the domain-squatting covered in these answers or if you harbor ill will toward Facebook). Either way, it's amusing since your comment is about a typo. Commented Dec 1, 2017 at 20:38

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.

  • 9
    Facebook uses preloaded HSTS. When I browse to https://www.facebook.com, among the response headers are Strict-Transport-Security: max-age=15552000; preload Consequently, any modern browser (one that supports HSTS) won't just warn about SSL/TLS issues, but outright refuse to let you connect to Facebook at all.
    – user
    Commented Dec 1, 2017 at 21:39
  • 2
    @MichaelKjörling HSTS preload does not enforce a static public key. It only disables plain http, that's it. Fake facebook could be https, with a proper end-entity certificate, only a different root certificate.
    – kubanczyk
    Commented Dec 1, 2017 at 23:25
  • 3
    @kubanczyk No, HSTS doesn't enforce a particular key (but HPKP could, to some extent, by effectively mandating the use of one of two specified CAs). However, my comment was in response mainly to "and warn you if it's not" in the first paragraph. When HSTS is in use, with a client that implements HSTS as defined, one of its effects is to turn any SSL/TLS warning into a fatal error. So if there is any problem which would cause a SSL warning in a non-HSTS situation, that same problem will prevent the user from browsing a known-HSTS site at all. With preloading, that includes the first visit.
    – user
    Commented Dec 2, 2017 at 14:05
  • 1
    A URL can have a username:password@ before the host name; some scammers used to use this to make facebookcom@scammers-r-us . com/ look like a Facebook URL
    – CSM
    Commented Dec 2, 2017 at 18:57
  • didn't domains have an implicit trailing . (www.facebook.com.), which is the actual top level domain for everything?
    – Brian H.
    Commented Dec 4, 2017 at 12:47

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).

  • 8
    May I suggest adding a bit about not installing untrusted certificates? And about domain names where some of the letters have been replaced with well-chosen Unicode look-alikes? While no decent CA would issue a certificate for a name that looked exactly like Facebook, it could be an issue with less famous domain names. Commented Dec 1, 2017 at 13:37
  • 4
    It is only the proof, that your connection is not intercepted, but not the proof you're using the real facebook. Everybody can get a certificate for domains which look like they may belong to facebook.You need look at the company name in the URL bar. Facebook has an EV certificate, which proofes it is the real facebook, while fakes can only have a DV certificate, which only proofes they are the owners of their (fake) domain.
    – allo
    Commented Dec 1, 2017 at 15:00
  • 6
    @allo, since when facebook uses EV certificate?
    – Crypt32
    Commented Dec 1, 2017 at 17:14
  • 7
    @Sumurai8 Could you elaborate what your picture is showing? I'm assuming Veilig is a translation of Secure. Is this an IDN homograph attack? Did you blank out something after .com?
    – phihag
    Commented Dec 1, 2017 at 18:42
  • 2
    Most comments here are technically true, but not relevant on the level the question was asked on.
    – Anders
    Commented Dec 2, 2017 at 7:59

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.

  • You are absolutely right that one needs to put trust in many things, and one cannot possibly check everything for one-self. However, it is easier to put trust in something that is open, because it means that anyone could potentially check it, so the entity putting in back doors has potentially to expose one-self. Of course, the real pain point in this is hardware, but you may hope that hardware is sufficiently low level not to be able to interfere with sophisticated stuff you do on higher, open layers.
    – entrop-x
    Commented Dec 5, 2017 at 5:05

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.


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 public DNS results?


  • 3
    This does not add to what the other answers provide. Other answers say the same thing without specifically mentioning "China" (which is unnecessary because other countries as well as ISPs and organisations do the same thing)
    – schroeder
    Commented Dec 3, 2017 at 16:57
  • I think China is the first country to have a root CA removed by a browser maker though? First I'd heard.
    – Tomachi
    Commented Dec 5, 2017 at 1:42

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.

  • Welcome to Information Security Stack Exchange! This is a well-written philosphical answer, but I'm afraid it's not the kind of answer we are looking for here. This site is aimed at practical answers ("There is a lock icon that shows you're using SSL/TLS, and the title bar should show the site name in green..."). That said, we also have a Q&A site about Philosophy, that you may find interesting. Commented Dec 4, 2017 at 15:03
  • @Barth: I see what you mean, but my aim was to indicate a genuine difficulty of security with CA. For instance, if you're working in a big company, and you're behind a firewall, the original question how can I be sure that I'm on the real Facebook ? might make sense, if your company has extra root certificates installed in your browser and is snooping on its employees, doing a systematic MITM attack on outgoing facebook traffic. Your ISP is maybe also linked to a CA, and might do the same. How would you find out ?
    – entrop-x
    Commented Dec 4, 2017 at 15:34
  • Of course it answers the question. I'm not criticising anyone, apart from the comment of Barth who claimed that it wasn't an answer, and that the "right" answer should simply be based upon CA. I'm explaining that the real answer to the question comes down to finding out whether the public key one has is genuinely corresponding to the entity one has in mind, and that this could mean 3 different things: "same as previous", "legal entity" or "same as what other people agreed upon". "green lock" is based upon "whatever any single one of a set of given entities (CA in browser) tell me it is".
    – entrop-x
    Commented Dec 5, 2017 at 4:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .