1123971 - HSTS entry in SiteSecurityServiceState.txt blocks me from visiting site

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Mats Palmgren (inactive)]

Recently I noticed that my browser was running slow, with multi-seconds long
pauses on the main thread.  Tracking this down I noticed that in the
History menu there were a few w3.org entries that oscillated in the "most
recent visited" list... I have a few tabs with W3C specs in them, e.g.
http://www.w3.org/TR/css3-break/
http://www.w3.org/TR/css3-grid/
after locating them in my several hundred other tabs I saw that they
"hanged", seemingly reconnecting endlessly.  After closing those tabs
everything went back to normal, except I still couldn't load W3C specs
which isn't good in my line of work :-)

So, after creating a fresh profile and copying parts of my default
profile over I found that the culprit is "SiteSecurityServiceState.txt"
which has this entry:
www.w3.org:HSTS 10      16455   1434972354152,1,0

After removing that entry with a text editor the URLs above loads fine.
(I have no clue how I got that entry in that file.)

It seems to me, there should at least have been some kind of error message
in the tabs that couldn't load, and it seems they consumed way to much
resources while trying to reconnect.  There has to be some way for an
ordinary user to get out a situation like this.

The bug occurs in FF38 and FF35 on Linux64.

Comment 1

[Sebastian Zartner [:sebo]]

I was about to create the same report for the same website.

I assume this bug got introduced with bug 775370.
I didn't run mozregression so far. Let me know if it's needed.

Sebastian

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

If this isn't happening on other sites, the most plausible explanation I can think of is that at some point www.w3.org tried out using HSTS but then stopped using it. They then also added a 307 redirect from https://www.w3.org to http://www.w3.org (which is pretty much the worst thing you can do if you've ever used HSTS as a site). At that point, any user who had visited www.w3.org while it was using HSTS (and thus noted it as an HSTS host) stopped being able to visit the site because they would attempt the https url, see the 307 to http, upgrade that to https, and loop indefinitely. (If you put that entry back in your SiteSecurityServiceState.txt and load the site with the network panel open, you'll see the repeated https -> 307 requests.)
We should probably attempt to notice this behavior and terminate the load with an error message if we can.

Comment 3

[kalviskajaks]

I just spent half a day troubleshooting why reddit doesn't load even in safe mode, only to finally narrow it down to SiteSecurityServiceState.txt For an inexperienced user the only solution would have been a new profile. Would that be too much to ask for somebody throw together a patch, and stop the infinite looping...

Comment 4

[fireattack [:fireattack]]

Any update on this? To be, the major flaw/regression here is that the option "forget about this site", or the button in the about:permissions does NOT clear the records in SiteSecurityServiceState.txt.

it used to be for sure, like if you search for "hsts firefox remove" you can see it was the right way to clear HSTS record for certain web site. It's not any more. It needs to be fixed.

Comment 5

[therube]

Another instance where this happens:

URL 1: http://lincc.ent.sirsi.net/client/en_US/lincc/

Load URL 1 (tab 1, if you will).
Works.

URL 2: https://lincc.ent.sirsi.net/client/en_US/lincc/

Load URL 2 in a new tab (tab 2).
This sets an entry in SiteSecurityServiceState.txt.

Go back to (tab 1).
All attempts to open any URI from that page, http://lincc.ent.sirsi.net/client/en_US/lincc/, that reference lincc.ent.sirsi.net end up attempting to load an https:// page, & all fail.

Now, that said...

Comment 6

[therube]

Clear Private Date (Ctrl+Shift+DEL), then selecting 'Site Preferences' /does/ clear SiteSecurityServiceState.txt - entirely, after which the site will work.

So while SiteSecurityServiceState.txt, can be cleared, this is definitely not an easily identified condition, & does not seem to be a "clean" way to go about it (much less manually editing SiteSecurityServiceState.txt).
 
 
(Should Bug 1232586 - No way to delete HSTS records for sites other than manually edit SiteSecurityServiceState.txt be DUP'd to this bug?)

Comment 7

[fireattack [:fireattack]]

(In reply to therube from comment #6)
> Clear Private Date (Ctrl+Shift+DEL), then selecting 'Site Preferences'
> /does/ clear SiteSecurityServiceState.txt - entirely, after which the site
> will work.
> 
> So while SiteSecurityServiceState.txt, can be cleared, this is definitely
> not an easily identified condition, & does not seem to be a "clean" way to
> go about it (much less manually editing SiteSecurityServiceState.txt).
>  
>  
> (Should Bug 1232586 - No way to delete HSTS records for sites other than
> manually edit SiteSecurityServiceState.txt be DUP'd to this bug?)

I created that bug ticket after reading this because I think these two are not the same thing.

This one's title said "HSTS entry in SiteSecurityServiceState.txt blocks me from visiting site", to me it's "working as intended", because it's more like on the website's hand to have such a poor design (and you can reproduce the same behavior on Chrome), not Firefox.

But my bug is more about there is no good way (other than manually edit that file) to revert the HSTS entry. And specially, that was a regression because before you can just use the "Forget about this site" to do that.

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Marcela (Please NI request to Brindusa Tot)]

Hi, I was not able to replicate this on my end using Win 10, on the latest release, beta, and nightly builds, following steps on description nor comments 2 nor 5 https://www.w3.org/TR/css-break-3/ and https://lincc.ent.sirsi.net/client/en_US/lincc/ are loading without hanging and I am able to navigate within both sites.
Since the problem is no longer reproducible, I will close it as resolved-WFM. Please feel free to reopen this bug if you can still reproduce it.