2

When we type a web site name without protocol, browsers give the correct web site with it's correct protocol (i.e. http or https)

For example if I type google.com and hit return key, browser gives me the https://google.com

How does browser do this?

  • 1
    “When we type a web site name without protocol, browsers give the correct web site with it's correct protocol.” Are you sure of that? Most of the time the web server handles redirects like that. Don’t know what OS you are on, but try typing in curl -I -L google.com in the command line and see the flow of redirects. – JakeGould Mar 21 '18 at 2:52
  • 1
    And that said, when I do curl -I -L google.com I see a 301 that sends me to http://www.google.com/ and the final destination where I get a 200 doesn’t seem to be HTTPS unless I am reading the headers incorrectly? – JakeGould Mar 21 '18 at 2:54
5

This is not standardized behaviour, as no RFC document says how a client should behave if the user does not specify the protocol. But probably, in most default configurations, clients try to connect using a unsecure connection (e.g. http://) first. They just guess you meant to type http:// in front of your URL.

In that case, it's not the client that figures out that this site is available over a secure connection (e.g. https://), it's the web server that redirects your client's request. So, when typing google.com into your browsers' address bar, your browser first connects to http://google.com, and the webserver at google.com redirects your request to https://google.com. That's why you still end up on the https:// version of google.

You can even try this by manually typing http://google.com in your address bar. Google still redirects you over to https://google.com. But this is not the default behaviour of most webserver software out there, Google had to manually specify a "HTTPS redirect" in their webservers' configuration.

Still, it's possible, that some clients try a https://-connection first, and only connect over http:// if that fails. That's a more secure behaviour, and although it's probably not the default in most cases, there is e.g. HSTS that allows sites to flag themselves as https://, and some Sites may even be pre-flagged in the browser. (As @kicken pointed out, thanks!) Then there are browser plugins (e.g. "HTTPS Everywhere" for Firefox) that implement this procedure. Those plugins come with lists of sites that offer https://-secured connections, and when a user enters the URL of such a site with http:// or with no protocol at the front, the user gets redirected to the https:// version by the browser, not by the webserver, even if the website administrator didn't set up a HTTPS redirection for his site.

  • 6
    HSTS allows a browser to go straight to https for flagged sites. Some sites are pre-flagged in browsers by default. – kicken Mar 21 '18 at 3:40
  • I’ll add that to my post, thanks :) I meant things like that by saying „it’s possible that clients try https first“, but I’ll make this more explicit, you’re right. – LukeLR Mar 21 '18 at 3:59
  • Worth pointing out that an attacker really could hijack that initial unsecure connection and redirect you somewhere other than the https version of the site, in a public WiFi scenario for example. If HTTPS is just stopping a read-only attacker from reading your traffic (credit card numbers), the redirect doesn't hurt. But if HTTPS is all that's saving you from someone injecting a browser exploit into web pages you see or from redirecting you to a clone of the page with a slightly different URL, then that initial unsecured connection means you're screwed. – Peter Cordes Mar 22 '18 at 9:40

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.