https-first causes slow http: sites on non-standard ports to time-out too fast
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
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)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
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
Comment 1•3 years ago
|
||
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.
Comment 2•3 years ago
|
||
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!
Reporter | ||
Comment 3•3 years ago
|
||
We can confirm that it's produce with addons disabled.
To reproduce the issue try this url :
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
Comment 4•3 years ago
|
||
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
.
Updated•3 years ago
|
Comment 5•3 years ago
|
||
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
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
•
|
||
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!
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Set release status flags based on info from the regressing bug 1716991
Updated•3 years ago
|
Comment 9•3 years ago
|
||
The severity field is not set for this bug.
:ckerschb, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
bugherder |
Comment 12•3 years ago
|
||
Is this something we should consider backporting to ESR91?
Assignee | ||
Comment 13•3 years ago
|
||
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.
Comment 14•3 years ago
|
||
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.
Comment 15•3 years ago
|
||
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.
Comment 16•3 years ago
|
||
bugherder uplift |
Description
•