1976377 - inconsistent default scheme http vs https yields security issues

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect)

Description

[Vincent Lefevre]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0

Steps to reproduce:

1. Type foo.invalid in the address bar.

Actual results:

Firefox tries to open http://foo.invalid/ (with the http scheme).

Expected results:

For consistency with what is displayed, Firefox should try to open https://foo.invalid/ (with the https scheme).

The reason is that https is now regarded as the default scheme: when a URL is displayed in the URL bar, the http scheme is explicitly displayed and the https scheme is no longer displayed. So, following the principle of least surprise, https should also be the default scheme when typing a URL. Doing otherwise yields security issues: an attacker may silently redirect an http request to an https URL under his control (the user would not see that an insecure http request has been involved).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Simon Friedberger [:simonf]]

We already attempt to connect via HTTPS by default. We also provide HTTPS-Only mode which can be turned on in the security settings and it will show a warning for every insecure connection.

The reason that you're seeing HTTP here is probably that Firefox tried to connect over HTTPS and that fails for foo.invalid and Firefox then falls back to HTTP.

Does that alleviate your concerns?

Comment 3

[Vincent Lefevre]

(In reply to Simon Friedberger (:simonf) from comment #2)

The reason that you're seeing HTTP here is probably that Firefox tried to connect over HTTPS and that fails for foo.invalid and Firefox then falls back to HTTP.

If Firefox does this, that's very bad, as this could be used by an attacker who controls the network to transfer the connection to his own domain, which the end user could trust. For instance (I'm using .invalid for the exemple in order to avoid putting existing domains):

1. The end user wants to connect to wanted-domain.invalid (and assumes that HTTPS will be used).
2. Firefox tries to connect to https://wanted-domain.invalid/ (wanted-domain.invalid port 443), but the attacker blocks this connection (there is no way for Firefox to distinguish between an expected failure from a failure due to an attacker).
3. So Firefox falls back to HTTP and tries to connect to http://wanted-domain.invalid/ (wanted-domain.invalid port 80).
4. Since this connection is insecure, the attacker can control the answer and reply with a 301 Moved Permanently and https://wanted-domain2.invalid/ as the location, where wanted-domain2.invalid belongs to the attacker (but the end user does not know that).
5. Then Firefox connects to https://wanted-domain2.invalid/ (location given in the above step), which belongs to the attacker.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Vincent Lefevre from comment #3)

If Firefox does this, that's very bad, as this could be used by an attacker who controls the network to transfer the connection to his own domain, which the end user could trust.

Yes, this is well known, and also it crashes into the expectations of large numbers of users that the web should Just Work. We tried being hardcore and it generated too many unhappy users because there are a zillion edge cases. We were not allowed to ship hardcore by default, but hardcore users can go into settings and turn on "HTTPS-ONLY" mode which eliminates the fallback. "Try HTTPS first" is currently the best we can do by default.

If a user does manage to connect to the site securely at any point before they are attacked, that site has a chance to set an HSTS header. At that point you are then protected for that site as long as you return sooner than the timeout on the site's HSTS setting. A ton of the most popular sites are on the HSTS preload list so this is never a problem for them. And even if a site doesn't have an HSTS entry, if you visit it from a bookmark or from a remembered history entry in Firefox's Awesome Bar then it will also just visit the secure version of the site. And if you type out the https:// part first there is of course no fallback to insecure.

We will continue to revisit this decision in the future and tighten things up when we can.

Comment 6

[Vincent Lefevre]

"HTTPS-ONLY" mode is bad because one can no longer use "http:" at all. What is missing is a mode to prevent the automatic fallback from https to http when the connection to https is not allowed.