On 10/15/2016 5:12 AM, mozilla-lists.mbou...@spamgourmet.com wrote:
> NoOp wrote:
>> 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
>>> 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.
>> '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.
I reckon that the HSTS problems are going to get worse:
support-seamonkey mailing list