False CORS detection: Firefox 150.0 doesn't display embedded OpenStreetMap properly on http: site, while 149.0.2 did
Categories
(Core :: DOM: Security, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox150 | --- | wontfix |
People
(Reporter: hemmerling, Unassigned)
Details
(Keywords: 64bit, regression)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:150.0) Gecko/20100101 Firefox/150.0
Steps to reproduce:
If I call my openstreetmap
http://hemmerling.free.fr/html/maps/map01.html
( by using HTML4 code provided at
https://openlayers.org/two/
)
with Firefox both on
Window 64-bit
Android:
WIth Firefox 149.0.2, my openstreetmap is displayed properly.
Now with Firefox 150.0, my openstreetmap is now not displayed properly
WIth Google-Chrome, my openstreetmap is displayed properly.
I have one computer still with 149.0.2, another one with 150.0,
so I see the difference.
Actual results:
False CORS detection:
Openstreetmap is now not displayed properly, instead of the map there are pink squares, with "broken graphics" symbol.
Inspect(Q) displays:
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”. map01.html
window.controllers/Controllers is deprecated. Do not use it for UA detection. OpenLayers.js:550:418
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://c.tile.openstreetmap.org/7/67/41.png. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 301.
Expected results:
The of openstreetmap should have been displayed properly,
a) as the HTML code didn't change
b) as it works with 149.0.2 fine
c) as it works with Google-Chrome fine
d) as there is no fix known by "about:config"
e) there is no reason to fix by "about:config", openstreetmap should work without special configuration settings
Please fix Firefox 150.0, by default back settings back to 149.0.2!
| Reporter | ||
Updated•3 months ago
|
| Reporter | ||
Comment 1•3 months ago
|
||
Android:
I am using Android 15, with Firefox updated to 150.0.
Comment 2•3 months ago
|
||
Seems like this was caused by https://hg-edge.mozilla.org/integration/autoland/rev/a71716992cd910e8c6ce0aee52c2bbbc355c1ded, which removed openstreetmap from the HSTS preload list.
If you upgraded your page to HTTPS this problem would probably go away.
My mapping website climate-maps.com also faces issues since Firefox 150.0 (no issues in 149.0.2) and I have not found a solution yet. Though my problem is not the basemap. My problem is that certain raster (png) tiles (select temperature to see the bug) crash Firefox
| Reporter | ||
Comment 4•3 months ago
|
||
(In reply to Tom S. (please needinfo tschuster) from comment #2)
Seems like this was caused by https://hg-edge.mozilla.org/integration/autoland/rev/a71716992cd910e8c6ce0aee52c2bbbc355c1ded, which removed openstreetmap from the HSTS preload list.
If you upgraded your page to HTTPS this problem would probably go away.
a)
My free host provider "Free.fr" doesn't support "https" :-(, its a legacy vintage but useful service ( it won't be switched off if I die or if I run out of money, search engines know the subdomain since 25years ).
Looks like there’s a problem with this site. Firefox can’t connect to the server at hemmerling.free.fr
Specs:
http://hemmerling.free.fr/info.php
PHP Version 4.4.3
b)
I use the latest version of XAMPP on my Windows10Pro desktop with "PHP/5.3.8", which is compatible to the PHP on "Free.fr" and the version of "Dokuwiki" wiki suitable for PHP4, but which fails with "https" too
Secure Connection Failed. An error occurred during a connection to node4:8502. PR_END_OF_FILE_ERROR
Download:
https://sourceforge.net/projects/xampp/files/XAMPP%20Windows/1.7.7/
Specs:
PHP Version 5.3.8
Though I have bachelor in IT, I feel unable to fix this.
c)
Even if I fix my local XAMPP ( little chance ), anybody with Firefox can't display my OpenStreetmap on my website anymore.
Thats bad.
d)
Might Openstreetmap change its HTML4 code which I run on my website, to fix the problem by the HTML4 code?
Or is it impossible to fix it by the HTML4 code ( I assume so )?
Though I have bachelor in IT, I feel unable to fix this.
e)
May I, or may you ask Mozilla, to put openstreetmap on the "HSTS preload list" again?
If I have to do it, how and where to open a ticket for that?
May OpenStreetmap community do that, with better chance?
How are the chances for success?
I understand that my problem is rare, Free.fr is no popular free service anymore, might be discontinued without notice.
Sincerely
Rolf
| Reporter | ||
Updated•3 months ago
|
Updated•3 months ago
|
Comment 5•3 months ago
|
||
Is it a "false" detection? the CORS spec does not allow the use of CORS on insecure connections. [am I making that up? I can't find that in the Fetch spec or in the secure context spec right now]
c) as it works with Google-Chrome fine
maybe Chrome updates the HSTS preload list on a different schedule than we do. Maybe they have cached a previous "HTTPS upgrade" and at some future time it will expire and break. dunno. When I look at Chrome's network console I see "307" redirects instead of the "301" Firefox gets from the server, but if you look closer it's an "Internal Redirect" and they haven't actually made a request to the site; the "non-authoritative reason" is HSTS. Firefox also implements HSTS as an internal redirect but we don't expose it to devtools. Given the evidence I would expect Chrome to start breaking when the preload list updates percolate through.
The http: site does indeed return CORS headers, but if we think CORS is only allowed on secure connections we will ignore them.
I tried loading the openmap script from a secure URL to see if that would help (it redirects to one anyway) but apparently the script loads the images relative to the document's scheme and not the script's scheme. One trick you could try in the meantime is to add a Content Security Policy (CSP) to force the request upgrades. for example, add the following to the <head> of your document:
<meta http-equiv="content-security-policy" content="upgrade-insecure-requests">
Comment 6•3 months ago
|
||
May I, or may you ask Mozilla, to put openstreetmap on the "HSTS preload list" again?
If I have to do it, how and where to open a ticket for that?
May OpenStreetmap community do that, with better chance?
That is a shared community resource that we don't run and I don't know why they got removed. It could have been by their request, or as a clean-up pass because their site no longer qualifies for inclusion. Either way, the site has to want to be included and send appropriate upgrade headers; it's not anything you could do. https://hstspreload.org/?domain=openstreetmap.org
| Reporter | ||
Comment 7•2 months ago
|
||
Might it be a solution to use the (free?) service of
Cloudflare
or similar services
, which provide https connections to browser clients?
... I don't think so :-(.
Comment 8•2 months ago
|
||
No one suggested that. You already explained enough in comment 4 for us to know that wouldn't work for you.
But I gave you a solution already in comment 5: add a <head> section to your page and put that <meta> tag in it. I've tested it on your site (using DevTools) and it solves the problem. And it will fix Chrome when they eventually update their HSTS preload list and start breaking like Firefox.
I also looked at the documentation for OpenLayers and as I suspected they do default to protocol relative tiles. So you could also fix your site by using explicit "https:" arguments instead of calling "OpenLayers.Layers.OSM()" with no arguments and getting the broken defaults.
my comment 6 was solely addressing your question "e)": neither Mozilla nor the OpenStreetMap "community" (generally) can make the technical changes necessary. Only the administrators of the openstreetmap.org servers can make the technical changes to be re-added to the HSTS preload list. They may have had good reasons to stop supporting HSTS: It solves some problems like yours, but in other situations it can cause problems. And problems like yours can often be fixed by the web app (see above) but when it causes problems those are often not fixable.
Updated•2 months ago
|
Updated•2 months ago
|
Description
•