55

This question already has an answer here:

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?

marked as duplicate by Rory Alsop Feb 19 '15 at 13:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 8
    A good website would implement auto-redirects to the SSL version. – ps2goat Feb 16 '15 at 22:40
  • 5
    @ps2goat: ...and a better website would (also) use HSTS. Even that still doesn't fully protect the first request, though. – Ilmari Karonen Feb 17 '15 at 5:50
  • 13
    There is a fundamental flaw in the logic of preferring https to http: Where do you get the idea that https is better? The only thing https gains is security in data being transmitted from the client to the server. But that—in and of itself—is not always needed. Nor is your site magically secure because you are using https; for example a “secure” WordPress site using https is fairly vulnerable to attack if the version of WordPress has a security hole in it and an admin does not patch it. There is no real value to defaulting to https. If you think there is, you need to learn more. – JakeGould Feb 17 '15 at 7:43
  • 6
    @ps2goat: auto-redirecting from http to https is not an ideal situation. An attacker could perform a man-in-the-middle attack and not redirect, and display a phishing site instead – Thomas Bonini Feb 17 '15 at 9:57
  • 5
    Vote to reopen. The other posts asks about adoption 'why is https not more popular?'. This question asks specifically 'why do browsers assume http rather than https?' an important question with an interesting security answer. – Colonel Panic Jun 30 '15 at 15:57
25

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.

As for showing insecure websites in red, that is already in progress.

Google Chrome has the following timeline for giving errors on insecure websites:

  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.

  • 1
    Accepted as the only answer with (beggining of) a plan, and good example for (3). Steffen Ullrich and Bruno do a good job elaborating on (2). JamesRyan's comment made a great point that by the time this might be acceptable to users the protocols landscape will be different. – Beni Cherniavsky-Paskin Feb 19 '15 at 17:57
  • 1
    There are plans to move toward HTTPS, first stage is making new features HTTPS-only. blog.mozilla.org/security/2015/04/30/… Although I don't know if any progress has been made since then. – Simon Lindgren Apr 30 '16 at 0:48
  • 1
    I would comment, continuing on Google's progressive fight against unencrypted http, that I expect in very few years browsers to automatically try https first, or even prefer to avoid plain http at all. As @Anonymous pointed in the second part of the answer, the process is in progress. How many is few years? Somebody from Mozilla, Google & Co should try to answer – usr-local-ΕΨΗΕΛΩΝ Jun 3 at 12:21
60

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.

1

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.

  • 1
    I disagree with your last sentence. https doesn't protect the site, it protects the visitor. Maybe a better analogy would be, "Step into our dusty office. Here's a breathing mask that you can wear if you have allergies, asthma, or are just sensitive to dust. But if you step into room X, breathing masks are required for everyone, since we have toxic fumes in there." – TTT Feb 16 '15 at 22:13
  • But that redirection doesn't protect against mitm attacks, because the attacker can simply replace the redirection with a legitimately-looking reply with no security. – kasperd Feb 17 '15 at 9:21
  • 2
    I wouldn't call something that's vulnerable to SslStrip "just fine". Websites can't securely redirect from http to https. HSTS attempts to improve the situation a bit, but it only works reliably for sites that have been included in a list shipped with the browser (preloaded). – CodesInChaos Feb 17 '15 at 14:00
13

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.

  • 3
    Yes, this is the biggest issue. It's usually caused by SNI not being configured for a particular site, so the server defaults to some other site. Also, not all sites on a shared host will have a certificate - how can the browser detect the case of "server is listening on 443 but there is no valid site for this host"? Simple answer: it can't. Not reliably. The same could be said for 80, but that's rarer for historical reasons mentioned in other answers. – Bob Feb 17 '15 at 1:59
  • @Bob If the SNI-aware user agent connects with a server name that isn't among the sites on that IP with a certificate, then the server would just send the IP's default certificate. A subject name mismatch IMO would reliably indicate "no valid site for this host". – Damian Yerrick Feb 19 '15 at 0:52
  • 1
    @tepples That would open you up to a MitM. A MitM attacker could simply substitute a certificate with an incorrect SN or SAN and cause the browser to fall back to HTTP - very very bad. – Bob Feb 19 '15 at 1:37
  • 1
    @Bob If HTTPS is specifically requested (UA has an HSTS preload for this hostname, UA has seen HSTS header on a previous visit, or the user entered https://), the UA would show the name mismatch page. The MITM opportunity would happen only on the first visit to a site not in the preload list when the user declines to specify a scheme, and it'd be no worse than today when HTTP is already assumed. – Damian Yerrick Feb 19 '15 at 1:44
  • @tepples Good point. The other issue remaining (relatively rare, but not unheard of) is a wildcard certificate where some subdomains are not actually accessible through HTTPS but still have a match on the SAN list. There's also an abundance of servers where the HTTPS connection works, but breaks the site (I ran the HTTPS Anywhere addon in the past, that will test for and connect to HTTPS whenever possible [as opposed to Everywhere that uses whitelists], and this became obvious quite quickly) - that goes back to webmasters assuming HTTP and never testing for HTTPS. – Bob Feb 19 '15 at 2:05
0

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.

  • 3
    "recent versions of chrome by default will try https nowadays" — do you have any more details on that? Perhaps you mean trying SPDY by default (which AFAIK only happens on an HTTPS url)? – Beni Cherniavsky-Paskin Feb 17 '15 at 9:17
  • Trying to use https doesn't help against an active attacker if the browser silently falls back to insecure http if https did not work. – CodesInChaos Feb 18 '15 at 14:51
  • 1
    I would also like to add that https costs more money. A good SSL certificate ( which empowers https) can go well over a couple of hundred $$ a year. This and the fact that you need to pay for more bandwidth, more CPU power and more ram to host HTTPS begs the question of why bother for a website such as stackexchange, or wikipedia for that matter. Most of the information is public anyways, and they don't make that much money off the website either. Who will pay for the added security? – user283885 Feb 18 '15 at 15:13
  • 1
    @user283885 For most websites a simple domain validated certificate is enough, and those typically cost around less than $10 per year. Even wildcard certificates aren't "well over a couple of hundred $$". The performance impact isn't that big either. For most websites the biggest cost by far is the time spent setting up SSL. – CodesInChaos Feb 23 '15 at 12:29
  • 1
    @user283885 This is no longer true: letsencrypt.org – user7146 Apr 20 '17 at 8:18
0

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.

  • 2
    Redirecting from http to https loses most of the security benefit of https. – CodesInChaos Feb 17 '15 at 14:02
  • Really? How so? (BTW I mean redirect them as soon as they arrive on the site, so by the time they get to the credit card screen or whatever it is, they are well within https) – colmde Feb 17 '15 at 14:06
  • 6
    A MitM attacker can simply respond to that first unprotected request and omit the redirect. Unless the user notices that they weren't redirected (most won't), the attacker will be able to show them whatever they like. – CodesInChaos Feb 17 '15 at 14:10
  • 1
    @CodesInChaos - I would disagree that "MOST of the security benefit of https" is to prevent MITM attacks. I think the main benefit of https is avoiding sniffed traffic, not the scenario you described. Besides, in your scenario the MITM can completely bypass the real site, and HTTPS would do nothing to prevent that. If you're claiming the user wouldn't notice they weren't switched over to https, they probably wouldn't notice the initial entrance to the site wasn't https either. – TTT Apr 23 '15 at 18:27
2

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

  • 1
    Indeed but it's kinda complimentary: it forces HTTPS on all requests but only to a set of whilelisted sites. The effect is akin to HSTS (with preload) except it wasn't sanctioned by the webmaster. I'm talking about affecting all urls but only when typed-in without a scheme. The "KB SSL Enforcer" plugin is a closer match: it tries HTTPS (with soft fail to HTTP) on first access, and if sucessful "pins" the site to always forced HTTPS. – Beni Cherniavsky-Paskin Feb 18 '15 at 17:40
  • There is, in addition, a plugin that tries websites with HTTPS, sees if they work, and if so, adds them as a rule to your browser. code.google.com/p/https-finder - both together will mean that for any website which supports HTTPS, you will use HTTPS. – Dewi Morgan Feb 19 '15 at 3:39
3

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.

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