Closed Bug 1473808 Opened 4 years ago Closed 4 years ago

Authentication on https://www.geoloire42.fr/aigle_cadastre/ fails to load

Categories

(External Software Affecting Firefox :: Flash (Adobe), defect)

All
macOS
defect
Not set
normal

Tracking

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 wontfix, firefox62 wontfix, firefox63 wontfix, firefox64 fixed, firefox65 fixed)

RESOLVED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- fixed
firefox65 --- fixed

People

(Reporter: RT, Assigned: jkt)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Authentication inside this portal (please contact me directly if you want to replicate).
Browser logs: https://pastebin.com/uNjMGDB3
Screen cap: http://recordit.co/9fhZ5C3W8A

This runs fine inside latest Chrome
The reporter mentions this works on ESR 52.9.0
Felipe, any chance you could take a quick look? This seems to have stopped working with Firefox 61 and I wonder if this is website specific. Let me know if you need auth details to replicate.
Now with NI to Felipe
Flags: needinfo?(felipc)
What version of firefox were they testing with? 64-bit or 32-bit?
Flags: needinfo?(rtestard)
(In reply to Jim Mathies [:jimm] from comment #3)
> What version of firefox were they testing with? 64-bit or 32-bit?

64 bit Firefox 61.0.1 - I reproduced on Mac 10.13.5
Flags: needinfo?(rtestard)
OS: Unspecified → Mac OS X
Hardware: Unspecified → All
Flags: needinfo?(felipc)
Hey Romain, can you help find a regression range, or file a pi request for that?
Flags: needinfo?(rtestard)
Andrei, can your team help find a regression range here? Thanks!
Flags: needinfo?(andrei.vaida)
Seems like we need creds, cancelling ni?
Flags: needinfo?(andrei.vaida)
(In reply to Mike Taylor [:miketaylr] (62 Regression Engineering Owner) from comment #7)
> Seems like we need creds, cancelling ni?

I have creds but cannot put them in public, please ping me directly for them by email or slack (rtestard).
Flags: needinfo?(rtestard)
Unable to find a regression range since issue is reproducible for me on every build I tried.

"Your connection is not secure" with Error code: SEC_ERROR_UNKNOWN_ISSUER is presented when the site is loaded which suggests that the certificate is partially invalid. Adding certificate exception loads the website but the authentication does not go through.

On Chrome the website shows as Secured.

Checked on ESR 52.9.0 and older ESR builds and issue still occurs.
Tried with different ESR builds as it might be a NPAPI flash related problem but with no luck in finding a build that authenticates the user.
We're not going to be fixing this in 61 at this point. Can you confirm whether this affects 62+ or not?
Flags: needinfo?(rtestard)
(In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #9)
> Unable to find a regression range since issue is reproducible for me on
> every build I tried.
> 
> "Your connection is not secure" with Error code: SEC_ERROR_UNKNOWN_ISSUER is
> presented when the site is loaded which suggests that the certificate is
> partially invalid. Adding certificate exception loads the website but the
> authentication does not go through.

Is that an error reported by Firefox or Flash? Can you check the certificate's issuer name in Firefox's site information menu?

https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate

In the Website Identify dialog, I see:

  Website: www.geoloire42.fr
  Owner: This website does not supply ownership information.
  Verified by: Gandi
  Expires on: April 23, 2019
Flags: needinfo?(gasofie)
(In reply to Chris Peterson [:cpeterson] from comment #11)
> (In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #9)
> > Unable to find a regression range since issue is reproducible for me on
> > every build I tried.
> > 
> > "Your connection is not secure" with Error code: SEC_ERROR_UNKNOWN_ISSUER is
> > presented when the site is loaded which suggests that the certificate is
> > partially invalid. Adding certificate exception loads the website but the
> > authentication does not go through.
> 
> Is that an error reported by Firefox or Flash? Can you check the
> certificate's issuer name in Firefox's site information menu?
> 
> https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-
> certificate
> 
> In the Website Identify dialog, I see:
> 
>   Website: www.geoloire42.fr
>   Owner: This website does not supply ownership information.
>   Verified by: Gandi
>   Expires on: April 23, 2019


Hi Chris,

This is the information that I see in the page info security:
>   Website: www.geoloire42.fr
>   Owner: This website does not supply ownership information.
>   Verified by: Not specified

Added a screenshot too.
Flags: needinfo?(gasofie)
Interesting! This looks like a mixed content problem (an HTTPS page trying to load HTTP content). The Page Info dialog shows no certificate and the address bar shows a yellow triangle icon (mixed content warning).

Romain's browser log from comment 0 has a warning message related to mixed content, too:

Loading insecure content within a plugin embedded in a secure connection is going to be removed.
Loading mixed (insecure) display content “http://geoloire42.fr/crossdomain.xml” on a secure page

That warning landed in Firefox 60 (bug 1441794). Blocking of insecure plugin content landed in Firefox 59 (bug 1190623) but was backed out in Firefox 61 (bug 1445951) because it broke too many Flash sites.

Is your pref "security.mixed_content.block_object_subrequest" set to false?
See Also: → 1190623, 1445951
(In reply to Chris Peterson [:cpeterson] from comment #14)
> Interesting! This looks like a mixed content problem (an HTTPS page trying
> to load HTTP content). The Page Info dialog shows no certificate and the
> address bar shows a yellow triangle icon (mixed content warning).
> 
> Romain's browser log from comment 0 has a warning message related to mixed
> content, too:
> 
> Loading insecure content within a plugin embedded in a secure connection is
> going to be removed.
> Loading mixed (insecure) display content
> “http://geoloire42.fr/crossdomain.xml” on a secure page
> 
> That warning landed in Firefox 60 (bug 1441794). Blocking of insecure plugin
> content landed in Firefox 59 (bug 1190623) but was backed out in Firefox 61
> (bug 1445951) because it broke too many Flash sites.
> 
> Is your pref "security.mixed_content.block_object_subrequest" set to false?

Yes, the pref "security.mixed_content.block_object_subrequest" is set to false.The site loads after changing it to "true".
My experience is that "security.mixed_content.block_object_subrequest" defaults to "false" on 61.0.2 and that the site loads after changing it to "true".
Per Chris' comment 14, blocking of insecure plugin content landed in Firefox 59 (bug 1190623) but was backed out in Firefox 61 (bug 1445951) because it broke too many Flash sites - we still see the issue in 61.0.2, does this mean this is not related to bug 1190623?
Flags: needinfo?(rtestard) → needinfo?(cpeterson)
Tanvi or Jonathan, this bug is a Flash site that fails with a login authentication error in Firefox 61+ when the "security.mixed_content.block_object_subrequest" pref (from bug 1190623) is FALSE, but loads in correctly when the pref is TRUE. That sounds backwards to me. Do you have any suggestions for what might be happening?

This sounds similar to Comcast video bug 1425828 and HBO/MLB video bug 1441084. The HBO/MLB bug was resolved invalid. Does HBO and MLB video now work correctly in Firefox 61+? The Comcast bug is still open.
Flags: needinfo?(cpeterson) → needinfo?(tanvi)
Sounds backwards to me at first look. I was going to compile without the deprecation warning just in case that is having some issue perhaps?

Is the site testable for you? (for some reason my flash install just crashes linux firefox).
Sounds backwards to me too.  The pref would block a subrequest.  And for some reason, blocking makes the site behave better?
Flags: needinfo?(tanvi)
(In reply to Tanvi Vyas[:tanvi] from comment #19)
> Sounds backwards to me too.  The pref would block a subrequest.  And for
> some reason, blocking makes the site behave better?

Apparently. That is what both Gabi (comment 15) and Romain (comment 16) reported after setting "security.mixed_content.block_object_subrequest" to true. Perhaps the login works because the blocking prevents some other broken Flash from loading? But that wouldn't explain why this site stopped working in Firefox 61.

Testing the site requires a username and password, which Romain can provide.
I'm back to thinking we should move to doing this anyway. Given we disable in 2019 it feels like a lightweight removal.
(In reply to Jonathan Kingston [:jkt] (Away until 20th Aug) from comment #21)
> I'm back to thinking we should move to doing this anyway. Given we disable
> in 2019 it feels like a lightweight removal.

Do we know how frequently loading insecure content within a plugin embedded in a secure connection happens?
We apparently backed it out in Firefox 61 (bug 1445951) because it broke too many Flash sites.
Flash disablement will be done along with other browser vendors, breaking flash ahead of this exposes us to churning users.
We didn't which was the reason for the backout. The deprecation warning gave us stats:

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-18&keys=__none__!__none__!__none__&max_channel_version=nightly%252F63&measure=USE_COUNTER2_DEPRECATED_MixedDisplayObjectSubrequest_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-06-25&table=0&trim=1&use_submission_date=0

It's 0.01% of page loads and less for documents: <0.01%. Over 2 months on nightly it's 30k of page loads which could potentially have been broken in some way if we switch.

The other reason for the backout was there were a few big names in that breakage list which I think since have changed.
This is still marked as 62-affected, with no owner.  We need a crisp decision from product management, please.
Flags: needinfo?(rtestard)
(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #24)
> This is still marked as 62-affected, with no owner.  We need a crisp
> decision from product management, please.

I'm marking as "WON'T FIX" for 62 given the low share of pageloads affected.
It seems this setting broke video playback on Comcast (bug 1425828) and HBO and MLB (bug 1441084) in Firefox 59+ and had to be disabled. Somehow disabling it broke the website reported on this bug.

Next steps
- Chris is talking to Softvision about adding these sites to the Flash smoke tests to get the current picture on HBO/MLB/Comcast
- Based on QA results decide if we mark this bug as WON'T FIX (major site breakage persists after QA) or set "security.mixed_content.block_object_subrequest" default to "true" for 63 and up
Flags: needinfo?(rtestard)
Too late for a fix in 63 but we can still take a patch for 65 and potentially for 64. 

Chris or Romain, any update here?
Flags: needinfo?(rtestard)
Flags: needinfo?(cpeterson)
Jonathan, to fix this bug, I think we want to disable HTTP/HTTPS mixed content blocking for Flash content.

Bug 1445951 attempted to disable mixed content blocking by setting the "security.mixed_content.block_object_subrequest" pref to false (in Firefox 61), but we now suspect the pref logic is backwards (comment 17).

Are these uses of sBlockMixedObjectSubrequest correct?

https://searchfox.org/mozilla-central/search?q=sBlockMixedObjectSubrequest&redirect=false
Flags: needinfo?(cpeterson) → needinfo?(jkt)
See Also: 1190623, 1445951
:cpeterson the logic still seems correct to me, if sBlockMixedObjectSubrequest is true we treat it as mixed script which is what will get blocked in the mixed content blocker.

What I suspect could be happening is the console logging is causing an issue for this site somehow:
https://searchfox.org/mozilla-central/rev/e0c879c86b95bdc752b1dbff6088169735674e4a/dom/security/nsMixedContentBlocker.cpp#949

We could test this by adding another pref that turns this off too. I'll add a patch now but I'm unable to test it because this site is behind an account.
Flags: needinfo?(jkt) → needinfo?(cpeterson)
Assignee: nobody → jkt
If I can get details tomorrow from :RT I can test. If not I think we should just land this patch as is and see if it fixes the problem on this site.
I wasn't actually able to replicate anymore with the details provided. It looks to me like the site fixed itself, can anyone else replicate?
(In reply to Jonathan Kingston [:jkt] from comment #31)
> I wasn't actually able to replicate anymore with the details provided. It
> looks to me like the site fixed itself, can anyone else replicate?

This looks fixed now so I'll resolve.
I'll follow-up with the site owner to check if he made changes.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(rtestard)
Resolution: --- → FIXED
Attachment #9020122 - Attachment is obsolete: true
Flags: needinfo?(cpeterson)
You need to log in before you can comment on or make changes to this bug.