2

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?

migrated from stackoverflow.com Apr 5 '17 at 14:13

This question came from our site for professional and enthusiast programmers.

  • 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 '17 at 21:56
  • @Louis Loudog Trottier That's correct but the problem appears before the HTTPS connect is initiated. – ChrisK Apr 3 '17 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 '17 at 2:18
  • 1
    This is why HSTS preloading was invented – niilzon Apr 5 '17 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 '17 at 14:20
5

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 '17 at 13:06
0

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 '17 at 22:05
  • @ChrisK yes, an attacker could - I'm not sure how that is relevant to your question, though – schroeder Apr 5 '17 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.