Closed Bug 1394698 Opened 2 years ago Closed 2 years ago

Page rendering differs between nightly and beta/release

Categories

(Core :: Security, defect)

Unspecified
Windows 10
defect
Not set

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr52 --- disabled
firefox55 --- disabled
firefox56 --- disabled
firefox57 --- affected

People

(Reporter: alice0775, Unassigned)

References

Details

(Whiteboard: [parity-Chrome][parity-Edge])

Attachments

(1 file)

The problem is only on Nightly build.


Reproducible: always

Steps To Reproduce:
1. Open https://www.janbambas.cz/links/


Actual Results:
Button color is red


Expected Results:
Button color is gray


Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=689f6fee184628d3dd968e3b6518cc811cfb3e43&tochange=e1b0aaa20f1098b08537b2e13f9e97ee9759d4c7

Suspect: Bug 1246540
Attached image screenshot
Indeed, setting security.mixed_content.use_hsts=false fixes the problem on Nightly build.
I think that nightly only preferences is a factor contributing to increasing regression in release.
Whiteboard: [parity-Chrome][parity-Edge]
(In reply to Alice0775 White from comment #0)
> The problem is only on Nightly build.
> 
> 
> Reproducible: always
> 
> Steps To Reproduce:
> 1. Open https://www.janbambas.cz/links/
> 
> 
> Actual Results:
> Button color is red
> 
> 
> Expected Results:
> Button color is gray
> 

This is interesting!  Those buttons are inside an iframe that I load via https from the main document, but the iframe refers css and js (from the same domain) via plain http.  This iframe is a static page not under control of the Wordpress installation that I've recently updated to https, which also included css/js references from wordpress controlled html (inspect the source of /links/) to be via https.  Only document responses have strict-transport-security: max-age=31536000; includeSubDomains response header.  There are no redirects to https generated by the site when you request a script via plain http.

So, what is the interesting thing here?  Since we've already received response for the root document (/links/ in this case) we must have an HSTS entry for www.janbambas.cz in the strict security database.  Hence, I would expect that the iframe referenced css/js would automatically be upgraded by necko to https as part of the HSTS logic.

This should work independently of bug 1246540, IIUC!

(And - *red* is the expected color of the buttons, actually...)


> 
> Regression window:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=689f6fee184628d3dd968e3b6518cc811cfb3e43&tochange=e1b0
> aaa20f1098b08537b2e13f9e97ee9759d4c7
> 
> Suspect: Bug 1246540
Flags: needinfo?(kmckinley)
Note that https://www.janbambas.cz/moz/board.php (the iframe content) does NOT response with any strict-transport-security headers.
Yes, security.mixed_content.use_hsts=false would prevent the css and js in the iframe from loading since it changes the order of mixed-content/HSTS evaluation, and css and js are both blockable. This is expected behavior for HSTS priming.
Flags: needinfo?(kmckinley)
This appears to be intended behavior for HSTS priming. If we're going to turn off HSTS priming in nightly that would be a different bug, and we already have a bug to ship HSTS priming (though it's looking like we might not at this point). When we reach a decision eventually nightly and release will match, one way or the other.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.