On 10/15/2016 5:12 AM, [email protected] wrote: > NoOp wrote: >> On 10/13/2016 12:42 PM, [email protected] wrote: >>> Mark Bourne wrote: >>>> Rainer Bielefeld wrote: >>>>> Hi, >>>>> >>>>> on some (few) web pages I can not reach the linked contents because my >>>>> unofficial en-US SeaMonkey 2.49a1 (NT 6.1; WOW64; rv:52.0) >>>>> Gecko/20100101 Firefox/52.0 Build 20160930004545 (Default Classic >>>>> Theme) on German WIN7 64bit with my normal User Profile automatically >>>>> replaces "http" in URL by "https". >>>>> >>>>> Example: >>>>> 1. In Browser visit <http://www.draytek.de/> >>>>> 2. In page contents heading line >>>>> ˋclick downloads - Firmwareˊ >>>>> Expected: <http://myvigoreu.draytek.com/download_de/> opens >>>>> Actual: <https://myvigoreu.draytek.com/download_de/> will >>>>> not open because it does not exist. So Error 404. >>>>> >>>>> I see that after a short moment in URL bar "http" becomes replaced by >>>>> "https" >>>>> >>>>> This also happens in Safe Mode without add-ons >>>>> No problem in a newly created User Profile. >>>>> So this problem seems to be caused by my preferences, but I can't find >>>>> the responsible one. >>>> >>>> On first trying, that didn't happen for me. Visiting >>>> <http://myvigoreu.draytek.com/download_de/> stayed on the http: version. >>>> >>>> However, I then changed http: to https:, i.e. >>>> <https://myvigoreu.draytek.com/download_de/>, and got a 404 Not Found >>>> page. Now, when I try going back to the http: version, it automatically >>>> redirects to the https: version. >>>> >>>> Visiting the https: version returns a strict-transport-security header. >>>> That indicates to the browser that, from now on, it should only access >>>> that pages on that domain via https:, not http:, to protect against >>>> attacks which attempt to force use of http:. So when you attempt to >>>> access the page via http:, the browser instead accesses it via https:. >>>> >>>> Since the site can serve the content in question via http: but not >>>> https:, it looks like a misconfiguration of that site's server to me - >>>> either it should be prepared to serve all content via https:, or it >>>> shouldn't send a strict-transport-security header instructing the >>>> browser to only use https:! >>> >>> I should have mentioned I was using SeaMonkey 2.40 on Windows Vista: >>> Mozilla/5.0 (Windows NT 6.0; rv:43.0) Gecko/20100101 Firefox/43.0 >>> SeaMonkey/2.40 >>> >>> You can clear SeaMonkey's memory of having seen the >>> strict-transport-security header as follows: >>> - Close SeaMonkey >>> - Use a text editor to open SiteSecurityServiceState.txt from your >>> profile folder >>> - Search for the line containing "myvigoreu.draytek.com" >>> - Delete that line >>> - Save the file >>> - Open SeaMonkey >>> - You should now be able to visit >>> <http://myvigoreu.draytek.com/download_de/> and see the list of downloads >> >> Appears that these bugs are most related: > > Those bugs are indeed related to HSTS, but I believe the issue Rainer is > seeing is due to HSTS working correctly on the browser, but the web > server he's trying to access is configured such that some content is not > accessible via HTTPS. > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1123971 >> 'HSTS entry in SiteSecurityServiceState.txt blocks me from visiting site' > > It appears that this one may, again, be a mistake in the server > configuration, this time leading to an infinite loop of redirects. > Although, as noted in that report, it would be nice if the browser > detected such a loop and displayed a useful error message rather than > just continuously trying to load the page. > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1119778 >> 'Forget about this site does not clear HSTS setting' >> Fixes Firefox so that you can select: History|Show All History| - >> right click on the Draytek https link and select 'Forget about this >> site' from the dropdown. I cannot find any such option in SeaMonkey, so >> perhaps Rainer can file a bug report requesting the ability to clear >> sites in SiteSecurityServiceState.txt from the 'History' UI. > > That would make it easier to work around the incorrectly configured > server, by using "forget about this site" rather than editing a > SiteSecurityServiceState.txt. With the incorrectly configured server, it > would still be necessary to repeat that workaround following any > subsequent visit to <https://myvigoreu.draytek.com/>. > > In my SeaMonkey 2.40, there is a "Forget About This Domain" option when > I right-click on a domain in the Data Manager. However, draytek.com > isn't listed there since there isn't any data managed by the Data > Manager associated with that domain, and I suspect it wouldn't clear the > HSTS data anyway. I think HSTS status used to be represented as a > "permission", but it was removed from there because users were confused > by the large number of domains appearing in the Data Manager with > "permissions" they hadn't set. >
I reckon that the HSTS problems are going to get worse: http://blogs.adobe.com/flashplayer/2016/09/hsts-support-in-flash-player-23.html http://blogs.adobe.com/flashplayer/tag/sts-header _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
