1658924 - Implement TRY-HTTPS-FIRST and automatically fall back to http if it doesn't work

Status: RESOLVED FIXED

(Core :: DOM: Security, task, P3)

Description

[Christoph Kerschbaumer [:ckerschb]]

Currently we provide three options in about:preferences

• always use https
• use https in private browsing mode
• never use https-only

Let's add a fourth option:

• Try HTTPS first. If not available, fall back to http.

Please note that this fourth mode would only try to upgrade the top-level load to https and leave subresources untouched. Basically HSTS but without the server side redirect :-)

Comment 1

[Christoph Kerschbaumer [:ckerschb]]

Hey Matt, within this bug we would like to do something similar than what we did within (https://phabricator.services.mozilla.com/D85300).
That is:

• upgrading a top-level to https
• sending an http background request with a delay
• if the http request comes back first, it's a strong indicator that the https upgrade will result in a timeout.

Question being:
When calling DocumentLoadListener::Cancel() we end up within docshell::DisplayLoadError. Now we actually do not want to show an error page in that case, but basically redirect the upgraded https request back to http. I hope there is some mechanism in DocumentChannl which permits doing that? Is there?

Thanks!

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

I think Bug 1060546 suggests the same (probably even a dupe). Adding See Also: 1060546 for now.

Comment 3

[Darkspirit]

Almost a dupe of bug 1158191

Comment 4

[Matt Woodrow (:mattwoodrow)]

Do you want DocumentLoadListener to inherit the existing http request that has returned, or do you want to just start another http request?

Looking at the current code it seems that the http request isn't configured correctly to be used as the 'real' response, but maybe that could be changed. Solving this seems harder, but might be the best performing approach.

If we want to just start a new one, then take a look at a DocumentLoadListener::MaybeHandleLoadErrorWithURIFixup.

This handles the case where the existing load has failed, but we can use the URIFixup code to generate a new URI. If so, it initiates a new load with that new URI.

Assuming we can detect the 'https upgrade request got cancelled because the http test resolved first' case from OnStartRequest, then we should be able to do something similar to initiate a new load.

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

Attachment: Bug 1658924: HTTPS-First - Try https first and automatically fall back to http if it doesn't work for top-level requests.

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #4)

If we want to just start a new one, then take a look at a DocumentLoadListener::MaybeHandleLoadErrorWithURIFixup.

Thanks for the info Matt. We can detect https-only related errors and in the attached WIP patch I have implemented something closely similar to MaybeHandleLoadErrorWithURIFixup which apparently does exactly what we want - thanks for the info!

Comment 9

[Daniel Veditz [:dveditz]]

Note if we fall back AUTOMATICALLY this can be used adversarially -- MITM can block the https request to get timeout behavior, or reply with a bogus cert that triggers our "must be a hosting service" heuristic. Probably fine to be the default, as long as the option to TURN IT OFF is clear in the UX so people are not relying on a sense of security that isn't what the default configuration offers.

Comment 10

[M E]

Anyone else think it would be better to NOT implement this?
I think it’s perhaps devolution to add this, as I can think of
How about instead if an HTTPS page loads fails to load, cut the number of steps the user has to take to switch to http:// ? for example, if the user
a) (double) clicks on https://, just the S is highlighted, or
b) ” , the S is removed, and [return] initiates http. (preferred)
c) Some other more novel UI change.

I agree with Daniel’s facts but question the opinion.

(I am also wondering: if an HTTPS connection is already established, could an MITM attack (or even mere noise) degrade the connection? currently/if this is enabled? Answer should be no; I can’t recall/wonder, respectively.)

Given uncertainty how users (especially typical/security-clueless users) actually respond to security UI stuff, I’m NOT confident my opinion is right. But I have a good track record on https issues.

Comment 11

[promeneur]

I agree with Christoph.

Lets the user choose what is good, usage or security. Just add an option "Try HTTPS first. If not available, fall back to http".
This is a good compromise between the two opinions.

"https everywhere" does this by default. I use "https everywhere" since the very beginning. It is more comfortable.

EFF people have the same security target. That why they create "https everywhere" for many years.

Comment 12

[Christoph Kerschbaumer [:ckerschb]]

Attachment: Bug 1658924: Implement HTTPS-First and automatically fall back to http if secure top-level connection is not available

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b2615a656e4
Implement HTTPS-First and automatically fall back to http if secure top-level connection is not available r=necko-reviewers,JulianWels,mattwoodrow,dragana

Comment 14

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/7b2615a656e4