1683015 - HTTPS-Only Mode Alert appears on site which supports https

Status: REOPENED

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

Description

[Kevin Locke]

Using Firefox Nightly, if I attempt to visit http://bugs.debian.org/wnpp I am often presented with the "HTTPS-Only Mode Alert: Secure Connection Not Available" page even though the site supports HTTPS. This can be reproduced using:

mozregression --pref dom.security.https_only_mode:true -a http://bugs.debian.org/wnpp

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=de2ff8f555f0bf64418b6693fc3fd75fa6379b90&tochange=c143b57f2a76cfad9a4be52e0ef4aeb7d87fef53

The pushlog suggests it may have been regressed by Bug 1660945.

Comment 1

[Kevin Locke]

Note: When bisecting, be aware that the reproduction is only about 50% reliable for me. If the URL loads correctly, I'd retry once or twice before declaring a revision good. I am reasonably confident in the regression range posted above, having tried de2ff8f5 about 10 times without error.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Hey Julian, can you take a look please? Given that mozregression points to Bug 1660945, probably something todo with our timeout mechanism?

FWIW, sending the background request can be turned off by switching the pref dom.security.https_only_mode_send_http_background_request. Maybe worth testing if switching the pref causes the problem to disappear.

Comment 3

[Kevin Locke]

Thanks Christoph. I'm unable to reproduce the issue with dom.security.https_only_mode_send_http_background_request:false on current nightly. That appears to be an effective workaround.

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

For now this has to go in the backlog - but ultimately we could re-consider our 3000ms timeout, potentially using 4 or even 5 seconds.

Comment 5

[Julian Gaibler]

Hmm, so https://bugs.debian.org/wnpp takes a while to load and http://bugs.debian.org/wnpp responds instantly with a 302 redirect to the HTTPS page.

Maybe we could check the HTTP status code somewhere here and not cancel the channel if it's a 3XX code. We would probably also need to check the header to see if it's redirecting to https and to the same domain to minimize false positives.

Thanks for reporting this bug, Kevin!

Comment 6

[Leli]

the flag for nsILoadInfo::HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS happens after the cancellation through the dom.security.https_only_mode_send_http_background_request

Comment 7

[Tomer Yavor]

Attachment: Bug 1683015 HTTPS-Only Mode Alert appears on site which supports https

Comment 8

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

I'm also seeing occasional "Secure Connection Not Available" for https sites, e.g. https://sso.mozilla.com or https://searchfox.org , mostly when I haven't visited them recently, e.g. first time in a day.
Doing a refresh makes them work again, and it won't fail anymore for a while.
I didn't see anything in the console.

Note: I'm in Australia, pings to US sites can sometimes be slow. Quick test: locally <10ms, >170ms to the US.

Please let me know if I should try something next time this happens.

Comment 9

[Tomer Yavor]

Attachment: Bug 1683015 HTTPS-Only Mode Alert appears on site which supports https. r=ckerschb

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9d14d5ae3863
HTTPS-Only Mode Alert appears on site which supports https. r=ckerschb,JulianWels

Comment 11

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/9d14d5ae3863

Comment 12

[Kevin Locke]

Thanks for all of the attention and work on this issue. I appreciate it!

Unfortunately, I can still reproduce the issue on Nightly 90.0a1 (2021-04-30) (64-bit). Can you confirm that it is fixed?

Comment 13

[Cristian Brindusan [:cbrindusan]]

@Kevin, I am a sheriff and I was marking this bug as fixed automatically with Bugherder after the merge from autoland to central, so I can't confirm that this is fixed (although I've tested using nightly 90.0a1 (2021-04-30) (64-bit) and doesn't reproduce for me).

Comment 14

[Kevin Locke]

Sorry @cbrindusan, bad assumption on my part.

Since I am still presented with the "HTTPS-Only Mode Alert: Secure Connection Not Available" when running

mozregression --pref dom.security.https_only_mode:true -a http://bugs.debian.org/wnpp --launch 2021-05-01

on Linux, I am reopening this bug in hopes that the proper folks can investigate. Let me know if there's anything else I can do to help.

Comment 15

[Tomer Yavor]

Thanks for checking again, and reporting it!
Edit: I can reproduce it too.

Thanks again for pointing it out. I will recheck it.

Comment 16

[Christoph Kerschbaumer [:ckerschb]]

It seems the issue reported here is not completely resolved as of now, but we are tackling that over in Bug 1709320. So I am marking this bug being blocked by Bug 1709320.

Comment 17

[Kevin Locke]

Makes sense. Sounds great. Thanks Tomer and Christoph for investigating and for posting an update!

Comment 18

[brent sweeny]

I'm seeing something similar but I think different:
https-only mode failing to use available https for site

I just enabled "HTTPS-only mode in all windows", and it's repeatedly saying that one site I'm going to has no https and asks if I want to access it using http (just like the help says it will do). The problem is that the link has https explicitly (if I copy and paste the link, it begins with https://), but firefox appears to be going to a link with neither http NOR https. If I type 'https://' at the beginning of the link that firefox is evidently trying to use, it works just fine, OR (as I discovered from reading this thread) reloading it from the "secure connection not available" page also goes correctly to the Https site that was originally called (I have screenshots, but don't see a way to attach them here). Is it possible that firefox is dropping the 'https://' from the beginning of the link? So far I've seen this behavior repeatedly on the ancestry.com site but not on other sites (so far). Unfortunatly, ancestry is a paid site. And if I enable www.ancestry.com in the exceptions, it works, and if I remove that exception, it's back to the broken behavior. (and it's definitely not a timing issue here.)

windows 10, firefox 92.0 desktop, no proxy

Comment 19

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

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

Comment 20

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

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

Comment 21

[Donal Meehan [:dmeehan]]

:Tomer Yavor this has been assigned but never worked on, should this be reassigned?

Comment 22

[Tomer Yavor]

Actually,
unsure if we are willing to fix it.
Since the problem is that the site is answering too slow. If we would change it, it would mean we have to increase our accepting time for an https response. In my case it took more than 24 seconds till the page was loaded...

Comment 23

[Christoph Kerschbaumer [:ckerschb]]

I think we the problem is correctly laid out in comment 5 and we should be able to land the attached patch in some form.

Comment 24

[Tomer Yavor]

Sorry,
my bad. The patch was already landed and so the problem is not related to timeouts anymore.
The reason here is that the redirecting host is bugs.debian.org while the final host is www.debian.org. Which leads here (https://searchfox.org/mozilla-central/source/dom/security/nsHTTPSOnlyUtils.cpp#842,882) to a false bool, so HOM cancels the https channel and displays the HOM error page

So after that patch was already applied it probably makes that bug to a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1653898