On 10/13/2016 12:42 PM, mozilla-lists.mbou...@spamgourmet.com wrote:
Mark Bourne wrote:
Rainer Bielefeld wrote:
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".
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
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
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
- 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.
'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.
'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.
support-seamonkey mailing list