Closed Bug 1731971 Opened 3 years ago Closed 3 years ago

https-first causes slow http: sites on non-standard ports to time-out too fast

Categories

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

Firefox 91
defect

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- fixed
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- fixed

People

(Reporter: s.pasquier, Assigned: t.yavor)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression, Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

In navigation in private.
time out for a get request on a non standard port (different of port 80) is fixed at 3.5 s.
None parameter detected for this.

Actual results:

invalid time out

Expected results:

the time out use in navigation in private should be the same than in standard mode

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Private Browsing

Hi,
Could you please provide more detailed steps to reproduce this issue? Please also let us know if this is reproducible with addons disabled as well.
Thanks!

Flags: needinfo?(s.pasquier)

We can confirm that it's produce with addons disabled.
To reproduce the issue try this url :

http://83.193.54.35:890/site/

In Navigation in private the response is Timeout
In "Normal" mode the response is ok
The script at this url wait 5 sec before to responde

Flags: needinfo?(s.pasquier)

By the way.
The timeout will occur even in normal mode, if set dom.security.https_first = true.
On the other hand. It can be accessed successfully in private browsing mode, if dom.security.https_first_pbm = false.

So, I think the problem is HTTPS-First Mode.

Component: Private Browsing → DOM: Security
Product: Firefox → Core

Trying to upgrade non-standard ports is a bit odd to start with. It's probably not going to work (a port can't be both TLS and not TLS), but for https_only we might as well try because we're not going to load the http: resource. The only time an upgrade might work is if the original http:// URL was a typo, but maybe we'll get lucky. Given the Address bar still defaults to adding http:// it's not unreasonable to try upgrading non-standard ports for navigations.

The TLS handshake failure actually comes back quickly here (SSL_ERROR_RX_RECORD_TOO_LONG). Why are we using a short timeout check when we fall back to the original URL? I looked around for time prefs associated with https-only/https-first and only found dom.security.https_only_fire_http_request_background_timer_ms which is set to 3000 (3 seconds). I thought that was only used by https-only mode on how long to wait to fire off a potentially-racing http: request, but for kicks I increased it to 6000 and then this URL worked.

According to the Browser Console (not the web tools console) we fire a request to http://83.193.54.35:890/site/ (note: http -- the https attempt doesn't show up). After the timer we fire off another request to the root of the site http://83.193.54.35:890/, and when that answers faster than the /site page we show the timeout error.

It looks like we fell back to using http:// quickly because of the TLS error, but maybe had already started the timer on the racing request. In this kind of case we either need to cancel the timer if we can, or when the timer fires have that code make sure we haven't already given up on TLS connection before it tries the racing connection.

Does that sound about right, Tomer?

Putting this in the backlog for now since you've already got a bunch of higher-priority https-first bugs assigned

Flags: needinfo?(lyavor)
Priority: -- → P3
Regressed by: 1716991
Whiteboard: [domsecurity-backlog1]
Has Regression Range: --- → yes
Summary: In navigation in private : time out issue on non standard port → https-first causes slow http: sites on non-standard ports to time-out too fast

Thank you for reporting!

That is a very interesting bug.
It's very odd because neither https-only nor https-first should upgrade non-standard ports: https://searchfox.org/mozilla-central/source/dom/security/nsHTTPSOnlyUtils.cpp#335,361-371.

@Dan It sounds right!
Yes, https-first uses timeouts probably to provide better performance.

I will investigate it further!

Flags: needinfo?(lyavor)
Assignee: nobody → lyavor

Set release status flags based on info from the regressing bug 1716991

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(ckerschb)
Severity: -- → S3
Flags: needinfo?(ckerschb)
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/autoland/rev/1abb9a7a798b
https-first causes slow http: sites on non-standard ports to time-out too fast. r=ckerschb
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

Is this something we should consider backporting to ESR91?

Flags: needinfo?(lyavor)

Yes sounds good for me!
Sorry for my late answer, I had to think about it.
On one side I would assume our user base that still uses ESR91 might be small but since it can effect a bunch of process I think it would be very valuable to backporting it.

Flags: needinfo?(lyavor)

Comment on attachment 9244956 [details]
Bug 1731971 - https-first causes slow http: sites on non-standard ports to time-out too fast. r=ckerschb

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: HTTPS-First tries to upgrade requests from http to https, but should only do so for standard port 80. While the general upgrading mechanism only considers standard ports our additional mechanism which improves user experience and potentially fires a background request was also firing for non standart ports. In turn, that potential background request could kill the upgraded top-level request.
  • User impact if declined: see above.
  • Fix Landed on Version: 95
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): It's a very self contained patch and only affects requests in PBM to http using non standard ports.
Attachment #9244956 - Flags: approval-mozilla-esr91?

Comment on attachment 9244956 [details]
Bug 1731971 - https-first causes slow http: sites on non-standard ports to time-out too fast. r=ckerschb

Approved for 91.5esr.

Attachment #9244956 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: