Why do browsers default to http: and not https: for typed in URLs?

Question

When I type example.com without any scheme into the browser bar and press Enter it is interpreted as HTTP://example.com, not HTTPS://example.com. Why? And where are the plans to fix this?

(To be clear, I'm talking only about typed/pasted addresses coming from a "lazy" user, not about software-defined actions such as following scheme-relative URLs, window.location = "url" etc. And obviously typing/pasting HTTP://example.com must still work.)

EDIT: As some answers point out sites already can mostly achieve this with redirects + HSTS. The central technical gain would be narrowing the first-connection problem (also addressed by HSTS preload but that can't scale to all sites). I can see how that's a weak justification for breaking things now; what I'm more interested in is whether it's an obvious endgame in 5 years? 10? 20?

I can see several problems on the way to defaulting to https interpretation:

1. User experience with sites that only work over http. Defaulting to https would show an error but the user usually has no idea whether it should work, i.e. whether this site simply never worked over https or is this a downgrade attack.

   If the error page for this situation will contain an easy "did you mean http:...?" link(*), users will get used to clicking that on any site that doesn't work and we haven't gained much(?). And if it's not easy (e.g. user must edit https->http, users won't use such browser.

   EDIT: I should have clarified that the error indication must be different from explicitly going to an HTTPS address which failed — this scenario is not so much "fail" as "the safe interpretation didn't work". And for starters, even "soft failing" automatically to HTTP with a warning bar on top would be OK.

   But I think we still gain 3 things: going to unsecure site is a conscious action, we educate users that unsecure HTTP is not normal, and we put pressure on sites to implement https.

2. Inconvenience of having to type http:// in some cases. IMO completely outweighed by convenience of not having to type https:// in more cases.

3. "Compatibility" with the historical default. I'm not sure if it's enshrined in some standard, but IMO it's clear we'll have to change it some day, so that's not a showstopper.

4. Politics/economics: the CA system has its issues and browsers might be reluctant to pressure site admins to pay them (if they don't otherwise see value in that). Let's ignore money for a moment and pretend Let's Encrypt free CA has arrived.

I can see why making the change right now can be controversial; what baffles me is why it's not widely discussed as the obvious long-term goal, with some staged plan a-la the SHA-2 certs deprection though maybe slower. What I see seems to assume http will remain default practically forever:

• Chrome's move to hiding http:// in URL bar is a step back. The first step towards https default should have been showing http in red; at some later time eventually move to hiding https:// (only showing green padlock)...

• HSTS moves in the right direction but with cautious per-site opt-in. It's both weaker and stronger — sites opt in to forcing https even for explicit http urls, with no user recourse for errors — but the RFC doesn't even mention the idea that https could be a global default, or that browser default scheme is to blame for bootsrap MITM problem.

• I've seen DNSSEC mentioned as future vector for HSTS-like opt-in but again never saw proposals for opt-out...

Also, are there any browsers (or extensions) offering this as an option?

Answer 1

Browsers are applications for end-users. While the majority of sites is available by http (even if they just redirect to https) a significant part is not available by https. Thus your proposal would break web surfing for a very large part of the users. It would break in a way they don't understand. Automatically downgrading to http if https fails would not make sense because an attacker could then just simply cause havoc with connections to port 443 to enforce downgrades.

Once all but a few insignificant sites switched to https one could make the switch to a more secure default, but not yet. End-users would not understand what happened and probably just switch to an alternate browser or get some tips from somewhere on the internet to get back the old behavior.

Security decisions have to be done with and not against the users.

Answer 2

Well, I can presume that a few reasons exist:

1. HTTPS support is not automatically configured on websites. Therefore, why should browsers assume it is?
2. Saying that a website is not accessible unless using a specific scheme would be over the heads of a significant number of users.
3. Switching to HTTPS is not as simple as it seems in some cases. Take Stack Exchange for example.

These are timelines for some popular browsers to fix this:

---

Google Chrome

1. Chrome 46

   Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.

2. Chrome 56

   mark HTTP pages that collect passwords or credit cards as non-secure

3. Chrome 62

   Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.

4. Chrome 68

   the omnibox will display “Not secure” for all HTTP pages.

5. Chrome 79

   Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://.

6. Chrome 81

   Chrome will print a console message warning about all mixed content downloads.

7. Chrome 84

   Chrome will warn on mixed content downloads of executables (e.g. .exe).

8. Chrome 85

   Chrome will block mixed content executables

   Chrome will warn on mixed content archives (.zip) and disk images (.iso).

9. Chrome 86

   Chrome will block mixed content executables, archives and disk images

   Chrome will warn on all other mixed content downloads except image, audio, video and text formats.

10. Chrome 87

    Chrome will warn on mixed content downloads of images, audio, video, and text

    Chrome will block all other mixed content downloads

11. Chrome 88

    Chrome will block all mixed content downloads.

---

Firefox

1. Firefox 51

   web pages which collect passwords but don’t use HTTPS will display a grey lock icon with a red strike-through in the address bar.

2. Firefox 70

   we will start showing a crossed-out lock icon as permanent indicator for sites delivered via the insecure protocols HTTP and FTP.

Answer 3

There's a bigger issue at play here that would prevent your suggestion. The way many web servers are currently configured, you could actually end up on the wrong website if you defaulted to https. This is not true if you default to http.

For example, suppose you have 3 sites all on the same IP address:

http://site.a.com
http://site.b.com
https://site.c.com

On many servers, if you were to attempt to go to https://site.a.com, (instead of http), you will actually be looking at site C, but with a certificate error.

Answer 4

I think there's a real danger of confusing a lot of users, which would make the situation even worse. Trying HTTPS everywhere isn't necessarily a bad idea, but there needs to be some sort of fallback plan for the user when HTTPS isn't available.

Many users aren't interested in warning signs, they just want their content. In many cases, protecting the traffic you get from eavesdropping or MITM attacks isn't strictly necessary, or at least the risk and consequences are much lower than a incorrect certificate on your bank.

Essentially, if the users get a warning sign when they try to get to their favourite HTTP-only site (e.g. a newspaper or some blog), you would have to teach them to ignore the warning, because it can still be OK in this case. Telling users to ignore warnings is generally a terrible idea, unless you really make sure they really understand ignoring that warning is OK, but ignoring others isn't.

Warnings are good, but numerous warnings for relatively low-risk problems are counter-effective, because the users are then likely to ignore all warnings (especially if they don't fully understand them).

Not many non-tech users try to understand the implications of the Firefox warning for a bad cert, for example:

This Connection is Untrusted

You have asked Firefox to connect securely to some.site.example, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified. What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

That's three paragraphs many users will not bother reading, at least not every time they encounter it, if it happens too often.

The main difference with a plain HTTP site is that the plain HTTP site doesn't claim to offer a secure connection. Assuming you can explain that in another three-paragraph message in a similar way. It would be quite common, even for tech-savvy users to be distracted and not read those explanations in full before choosing to proceed.

Many sites use http:// to https:// redirections, sometimes with 301 (permanent) status code or with HSTS. Pre-loaded HSTS is great but rare, HSTS on the first connection is reasonably good compromise.

At the end of the day, it will always be up to the user to expect the connection to be secure when appropriate. The browser can only do so much, but it's up to the user to check that HTTPS is in use when it makes sense to do so, and with the site they expect. It's not particularly different to real life: you don't need to check the passport of every one you ever talk to, but when things matter, you do.

There's a bootstrapping issue that cannot be conveyed within the realm of technology. If users goes to http://www.gmail.com/, they should be redirected to https://www.gmail.com/ or maybe https://mail.google.com/ or https://accounts.google.com/. It's out-of-band knowledge that tells them that they should expect HTTPS on Gmail, and that Gmail is run by Google. (The same out-of-band knowledge that tells them that HTTPS even exists...)

If they're not redirected, to an HTTPS site run by Google (Gmail or login), this is what should ring alarm bells with them. While an automated mechanism could work for a limited number of well-known sites, it's difficult to imagine a system that would work in general. Failing that, you still need the user to carry the responsibility to: (a) know when to expect HTTPS, (b) check that HTTPS is used and (c) check that they're indeed on the site they want. (Unfortunately, some browsers, especially on mobile devices, make that information a bit less visible.)

In my opinion, it's easier to teach a user those three points than to teach them to read the details of the warnings they may choose to ignore anyway.

Of course, you could imagine in the future a world where all the sites use HTTPS. I'm not yet entirely convinced this is necessary. Bad sites can get certificate too, so users will still have to carry the responsibility to check they're on the site they intended to visit anyway.

Trying to teach that plain HTTP is "not normal" is just pushing the problem to the next level. An all-HTTPS web can be a burden for the service providers, while not necessarily providing the benefits you'd expect.

Answer 5

The EFF has a plugin for Firefox (including Android), Chrome and Opera. It's called HTTPS Everywhere and it uses rules to make sure you end up on the right site. For example it'll rewrite example.com to https://secure.example.com/ if it knows that the https version only lives on secure.example.com. It even replaces urls inside links etc.

https://www.eff.org/Https-everywhere

Answer 6

Right now browsers use HTTP by default because it is what has been done for decades. It's not the browser's responsibility to ensure that the website is secure. It relies on the website to make the appropriate redirection and support HTTPS. Typing in google.com will redirect to the HTTPS version just fine. If a website supports HTTPS then it should put up the appropriate redirection. The browser has to be robust.

If the site supports both then it's like saying that your backdoor is left open, but your front door is locked.

Answer 7

Because computers used to be weak and encryption was cpu and internet bandwidth hungry and regarded as uneeded in the infancy of the internet.. You basically pack http in another layer and shove it over the pipe. This extra layer needs to do its own ceremonial tango in order to work, which means extra cpu, extra round trips, extra bandiwdth.. But things are changing, for example recent versions of chrome by default will try https nowadays. On the server side, however, you should setup a redirect as the only web content served on said domain which points the browser to the https flavor of the site.

Answer 8

Any website which requires security should redirect from http:// to https:// automatically. This would make the requirement for the browser to automatically view https:// redundant, and is a simpler solution than having to redirect from https to http for sites without certs.

This is something that shouldn't really be done anyway, which means the browser would have to put in security warnings, unnecessarily bothering the user like those annoying cookie warnings, etc.