How would a client's web-browser know if a websites is HTTPS only?

Here is the scenario, a client tries to access facebook.com by typing facebook.com in the address bar, the browser automatically goes to the non secure version http://facebook.com but Facebook doesn't allow it, it sends a redirect to the secure version of the website https://facebook.com.

This scenario seems vulnerable to me, an attacker (man in the middle) could intercept the traffic while the connection still was in HTTP and make the server never send a redirect to HTTPS and thus breaking the secure connection.

I'm pretty sure people already thought of this and fixed the problem but how?

Having a list of websites which are HTTPS only that comes with the web-browser doesn't seem to be effective.

Maybe the first time the client connects to the website, it receive a message that says to access the website via HTTPS only for a specific amount of time?

  • That's why certificates are issued and meed to be verified by a 3tr party. If you have a self signed certificate the Man-in-the-middle is possible on the 1st connection if the hacker sends a 'spoofed' certificate. In this case it would be as simple as sending your certificate to your client so he can install it in his browser. But for knowed and public certificate, this is not doable since your certificate need to be 'verified' by a Certificate autority. Like here on SO, it is verfied by DIgiCert.
    – Louis Loudog Trottier
    Apr 3, 2017 at 21:56
  • 1
    @Louis Loudog Trottier That's correct but the problem appears before the HTTPS connect is initiated.
    – ChrisK
    Apr 3, 2017 at 22:02
  • I think this is relevant for you: news.netcraft.com/archives/2016/03/17/… do a google search on HSTS. You are right to be worried according to the link and made me add something to my todo list.
    – Louis Loudog Trottier
    Apr 4, 2017 at 2:18
  • 2
    This is why HSTS preloading was invented
    – niilzon
    Apr 5, 2017 at 14:15
  • it doesn't know - it does what it is told - by a user or the server (or secondary configs)
    – schroeder
    Apr 5, 2017 at 14:20

2 Answers 2


A client's web-browser would know if the website is "https" only by checking if the website is listed in it's HSTS pre-loading list.

As you mentioned, in a classic scenario, a MITM could intercept an http GET request and prevent the redirection to the https version of the website.

This is why HSTS pre-loading was invented : browsers can verify if the visited website is in its HSTS pre-load lists. If it is the case, it will query the https version immediately, without trying the http first. This mitigates the MITM scenario

  • 1
    HSTS Preload List Submission: hstspreload.org (some websites are hardcoded in web browsers as being HTTPS only)
    – baptx
    Jul 9, 2017 at 13:06
  • It's worth noting that there is a non-preload version of HSTS, which boils down to the browser knowing "last time I went to facebook.com, it told me it was HTTPS only, and would be for at-least X more days"
    – 9072997
    Apr 5, 2023 at 20:29

To answer your first question, the browser doesn't necessarily know that the website only accepts HTTPS. It will attempt to load the requested URL and respond according to the server response.

If you open Chrome dev tools and navigate to http://facebook.com, you'll see that the browser receives a 307 Internal Redirect to https://facebook.com. Once it sees that, the browser then issues another request to the secure site.

The web server on the receiving end of the request bears the responsibility of allowing or denying any incoming requests.

  • But the attacker can make the "307 Internal Redirect" response never happen and make something like this: Client -> HTTP -> MITM -> HTTPS -> facebook.com
    – ChrisK
    Apr 3, 2017 at 22:05
  • @ChrisK yes, an attacker could - I'm not sure how that is relevant to your question, though
    – schroeder
    Apr 5, 2017 at 14:21

You must log in to answer this question.

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