X
Tap here to go to the mobile version of the site.

Support Forum

Firefox does not clear HSTS “cookies” when closed after a private session

Posted

Based on some information on the internet (e.g. here: http://www.securitynewspaper.com/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/), Firefox deletes HSTS information after a private browsing session.

My understanding is that this would mean that the "SiteSecurityServiceState.txt" file located in the Firefox profile directory (under \AppData\Roaming\Mozilla\Firefox\Profiles) is cleared.

I am running FF 42.0 and have configured it (under Options > Privacy) to "Always use private browsing mode" but for some reason this file is not getting cleared.

In fact it looks like it is actually getting populated by Firefox with specific entries.

I am saying this because I cleared the file manually a couple of hours ago and since then I have run a few test sessions (browsing the web for some time, with that "Always use private browsing mode" enabled) and closed the browser after each test session. Now when I checked the "SiteSecurityServiceState.txt" file, it looks like it has the same entries as before.

Based on some information on the internet (e.g. here: http://www.securitynewspaper.com/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/), Firefox deletes HSTS information after a private browsing session. My understanding is that this would mean that the "SiteSecurityServiceState.txt" file located in the Firefox profile directory (under \AppData\Roaming\Mozilla\Firefox\Profiles) is cleared. I am running FF 42.0 and have configured it (under Options > Privacy) to "Always use private browsing mode" but for some reason this file is not getting cleared. In fact it looks like it is actually getting populated by Firefox with specific entries. I am saying this because I cleared the file manually a couple of hours ago and since then I have run a few test sessions (browsing the web for some time, with that "Always use private browsing mode" enabled) and closed the browser after each test session. Now when I checked the "SiteSecurityServiceState.txt" file, it looks like it has the same entries as before.

Modified by darkavenger

Chosen solution

during a session this information is stored in RAM memory - once you close firefox (and you are not in private browsing mode), the changes are written into that file in your profile folder. did you file bug 1230559 as well? if so i think we could re-purpose it to deal with the bug i've described in my prior answer...

edit: so in conclusion, please try to delete the file while firefox is not running in order to address the issue!

Read this answer in context 2

Additional System Details

Installed Plug-ins

  • NVIDIA 3D Vision Streaming plugin for Mozilla browsers
  • NVIDIA 3D Vision plugin for Mozilla browsers
  • 5.1.40728.0
  • XVL Player for NPAPI browsers Ver. 14.1a

Application

  • Firefox 42.0
  • User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
  • Support URL: https://support.mozilla.org/1/firefox/42.0/WINNT/en-US/

Extensions

  • Browsing Protection by F-Secure 2.148.3561 (ols@f-secure.com)
  • FiddlerHook 2.6.0.4 (fiddlerhook@fiddler2.com) (Inactive)
  • RECAP 0.9.2.2.1-signed (info@recapthelaw.org) (Inactive)

Javascript

  • incrementalGCEnabled: True

Graphics

  • adapterDescription: NVIDIA Quadro 4000
  • adapterDescription2:
  • adapterDeviceID: 0x06dd
  • adapterDeviceID2:
  • adapterDrivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
  • adapterDrivers2:
  • adapterRAM: 2048
  • adapterRAM2:
  • adapterSubsysID: 078010de
  • adapterSubsysID2:
  • adapterVendorID: 0x10de
  • adapterVendorID2:
  • direct2DEnabled: True
  • directWriteEnabled: True
  • directWriteVersion: 6.2.9200.17461
  • driverDate: 8-7-2015
  • driverDate2:
  • driverVersion: 10.18.13.5382
  • driverVersion2:
  • info: {u'AzureContentBackend': u'direct2d 1.1', u'AzureCanvasBackend': u'direct2d 1.1', u'AzureFallbackCanvasBackend': u'cairo', u'AzureSkiaAccelerated': 0}
  • isGPU2Active: False
  • numAcceleratedWindows: 1
  • numTotalWindows: 1
  • supportsHardwareH264: False
  • webglRenderer: Google Inc. -- ANGLE (NVIDIA Quadro 4000 Direct3D11 vs_5_0 ps_5_0)
  • windowLayerManagerRemote: True
  • windowLayerManagerType: Direct3D 11

Modified Preferences

Misc

  • User JS: No
  • Accessibility: No
philipp
  • Top 25 Contributor
  • Moderator
5154 solutions 22828 answers

hi, the testpage referenced in the article was http://www.radicalresearch.co.uk/lab/hstssupercookies - please try if it assigns the same ID to you in different firefox sessions (i couldn't reproduce the issue when no history is kept).

hi, the testpage referenced in the article was http://www.radicalresearch.co.uk/lab/hstssupercookies - please try if it assigns the same ID to you in different firefox sessions (i couldn't reproduce the issue when no history is kept).
jscher2000
  • Top 10 Contributor
8025 solutions 65554 answers

Thanks for the link, philipp.

When I test the site in a regular window, then open the URL again in a second tab, it can read the code it set. Similarly, if I open the site in a private window, a second tab in the private window can read the code set in the first private tab. But I couldn't make it cross over between regular and private windows.

In case it matters, I have cookies set to expire when I close Firefox (but I didn't close Firefox during this test).

(As an aside, the article referenced in the original question seems to be copied from this article: http://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-fire...)

Thanks for the link, philipp. When I test the site in a regular window, then open the URL again in a second tab, it can read the code it set. Similarly, if I open the site in a private window, a second tab in the private window can read the code set in the first private tab. But I couldn't make it cross over between regular and private windows. In case it matters, I have cookies set to expire when I close Firefox (but I didn't close Firefox during this test). (As an aside, the article referenced in the original question seems to be copied from this article: [http://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/])

Question owner

Hi philipp,

the test page works as expected: the values it stores seem to be deleted when I close my (private) browsing session.

However (and I do apologize as this was probably not very clear) my question was about values already present in the "SiteSecurityServiceState.txt file. This file has a bunch of entries which, if I clear them, seem to be eventually added back by Mozilla.

Examples of these are shown in the image below. Note that it has entries e.g. for Facebook even though I do not explicitly visit FB (I do not have an FB account).

So perhaps the issue is that private browsing does delete new entries from this file but that Firefox for some reason keeps it populated with pre-defined entries?

Or otherwise this is some bug...is this file populated with entries in your system?

Hi philipp, the test page works as expected: the values it stores seem to be deleted when I close my (private) browsing session. However (and I do apologize as this was probably not very clear) my question was about values already present in the "SiteSecurityServiceState.txt file. This file has a bunch of entries which, if I clear them, seem to be eventually added back by Mozilla. Examples of these are shown in the image below. Note that it has entries e.g. for Facebook even though I do not explicitly visit FB (I do not have an FB account). So perhaps the issue is that private browsing does delete '''''new''''' entries from this file but that Firefox for some reason keeps it populated with pre-defined entries? Or otherwise this is some bug...is this file populated with entries in your system?

Modified by darkavenger

philipp
  • Top 25 Contributor
  • Moderator
5154 solutions 22828 answers

thanks for the follow up - i tested a little bit and could reproduce an issue that looks a bit like this: entries "collected" before firefox was set to always run in private browsing mode remain in this file (though some other cached entries and history data gets cleared once you set "never remember history" - so it may be a minor bug here that this is not extended to the HSTS list). maybe this happened for you as well? in this case simply delete this file & the entries shouldn't come back.

firefox also contains a preloaded list of hsts-hosts - but this is stored elsewhere and isn't suitable to be used for tracking purposes. more information is available at https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

thanks for the follow up - i tested a little bit and could reproduce an issue that looks a bit like this: entries "collected" before firefox was set to always run in private browsing mode remain in this file (<s>though some other cached entries and history data gets cleared once you set "never remember history" - so it may be a minor bug here that this is not extended to the HSTS list</s>). maybe this happened for you as well? in this case simply delete this file & the entries shouldn't come back. firefox also contains a preloaded list of hsts-hosts - but this is stored elsewhere and isn't suitable to be used for tracking purposes. more information is available at https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

Modified by philipp

Question owner

Thank you for your response, philipp.

I have in fact cleared the file before and the values are eventually added back to it (as in that case in my original post).

I will dig into this and check if I can find where they come from.

On another note I suspect that that test page (at http://www.radicalresearch.co.uk/lab/hstssupercookies) does not store it's "cookie" in the "SiteSecurityServiceState.txt" file but somewhere else.

I am saying this because of following test steps that I did:

1. opened the "SiteSecurityServiceState.txt" file open in Notepad++ 2. took at note (or screen shot) of the "SiteSecurityServiceState.txt" file (still open in Notepad++) 3. navigated to the test page at http://www.radicalresearch.co.uk/lab/hstssupercookies 4. took a note of the tracking ID provided by the test page. Left the page open. 5. reloaded the "SiteSecurityServiceState.txt" file (using File > Reload from disk) 6. took at second look at the "SiteSecurityServiceState.txt" file (At this point there was no difference to how it looked like in Step 2) 7. cleared the "SiteSecurityServiceState.txt" file and saved it. It was now empty. 8. closed the tab that had the test page open but did not close the browser. 9. re-opened a new tab and navigated to the test page. Noticed that it gave me the same number as previously. 10. reloaded the "SiteSecurityServiceState.txt" file (using File > Reload from disk) However at this point "SiteSecurityServiceState.txt" is still blank.

In conclusion it looks like the test page is saving it's "cookie" somewhere else than in "SiteSecurityServiceState.txt". As such it may not be suitable for testing the HSTS persistence.

Thank you for your response, philipp. I have in fact cleared the file before and the values are eventually added back to it (as in that case in my original post). I will dig into this and check if I can find where they come from. On another note I suspect that that test page (at http://www.radicalresearch.co.uk/lab/hstssupercookies) does not store it's "cookie" in the "SiteSecurityServiceState.txt" file but somewhere else. I am saying this because of following test steps that I did: 1. opened the "SiteSecurityServiceState.txt" file open in Notepad++ 2. took at note (or screen shot) of the "SiteSecurityServiceState.txt" file (still open in Notepad++) 3. navigated to the test page at http://www.radicalresearch.co.uk/lab/hstssupercookies 4. took a note of the tracking ID provided by the test page. Left the page open. 5. reloaded the "SiteSecurityServiceState.txt" file (using File > Reload from disk) 6. took at second look at the "SiteSecurityServiceState.txt" file (At this point there was no difference to how it looked like in Step 2) 7. cleared the "SiteSecurityServiceState.txt" file and saved it. It was now empty. 8. closed the tab that had the test page open but did not close the browser. 9. re-opened a new tab and navigated to the test page. '''Noticed that it gave me the same number as previously.''' 10. reloaded the "SiteSecurityServiceState.txt" file (using File > Reload from disk) However at this point "SiteSecurityServiceState.txt" is still blank. In conclusion it looks like the test page is saving it's "cookie" somewhere else than in "SiteSecurityServiceState.txt". As such it may not be suitable for testing the HSTS persistence.
philipp
  • Top 25 Contributor
  • Moderator
5154 solutions 22828 answers

Chosen Solution

during a session this information is stored in RAM memory - once you close firefox (and you are not in private browsing mode), the changes are written into that file in your profile folder. did you file bug 1230559 as well? if so i think we could re-purpose it to deal with the bug i've described in my prior answer...

edit: so in conclusion, please try to delete the file while firefox is not running in order to address the issue!

during a session this information is stored in RAM memory - once you close firefox (and you are not in private browsing mode), the changes are written into that file in your profile folder. did you file bug 1230559 as well? <s>if so i think we could re-purpose it to deal with the bug i've described in my prior answer...</s> edit: so in conclusion, please try to delete the file while firefox is not running in order to address the issue!

Modified by philipp

philipp
  • Top 25 Contributor
  • Moderator
5154 solutions 22828 answers

Helpful Reply

as existing cookies are kept when switching firefox from "remember history" to "never remember history" as well, i think this was the expected behavior anyway and not a bug as i've first thought.

as existing cookies are kept when switching firefox from "remember history" to "never remember history" as well, i think this was the expected behavior anyway and not a bug as i've first thought.

Question owner

Thanks philipp, it could well be that FF was running earlier when I cleared the file, and that for this reason the entries were eventually put back.

I noticed in the tests I did today that when FF puts the entries back, it does not do so when it is closed but when it is eventually re-launched.

So it could be that 1. initially the entries where from the time before I had enabled to always surf in Private Mode 2. when I cleared the entries from "SiteSecurityServiceState.txt", I did it while FF was running 3. I did not use FF for a while after clearing the entries. So then when I eventually launched FF again it added the entries back at that time. So then when I eventually launched FF again it added the entries back at that time.

Now I cleared the file again a couple hours ago (while FF was not running) and have since been surfing the web without the entries coming back.

Misunderstanding how it is expected to work was probably the cause of my problem with that test site as well. I had assumed that it would have added some entries to the file while FF was running (and that these would have been deleted when closing FF because of my private browsing mode). Instead it did not use the file at all because of my private browsing mode.

And yes I had opened the bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1230559. I have now closed it with an explanation.

Thank you for your help.

Thanks philipp, it could well be that FF was running earlier when I cleared the file, and that for this reason the entries were eventually put back. I noticed in the tests I did today that when FF puts the entries back, it does not do so when it is closed but when it is eventually re-launched. So it could be that 1. initially the entries where from the time before I had enabled to always surf in Private Mode 2. when I cleared the entries from "SiteSecurityServiceState.txt", I did it while FF was running 3. I did not use FF for a while after clearing the entries. So then when I eventually launched FF again it added the entries back at that time. So then when I eventually launched FF again it added the entries back at that time. Now I cleared the file again a couple hours ago (while FF was not running) and have since been surfing the web without the entries coming back. Misunderstanding how it is expected to work was probably the cause of my problem with that test site as well. I had assumed that it would have added some entries to the file while FF was running (and that these would have been deleted when closing FF because of my private browsing mode). Instead it did not use the file at all because of my private browsing mode. And yes I had opened the bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1230559. I have now closed it with an explanation. Thank you for your help.