Opened 3 years ago

Last modified 4 months ago

#18589 assigned defect

Tor browser writes SiteSecurityServiceState.txt with usage history

Reported by: cypherpunks Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-disk-leak
Cc: arthuredelstein, mcs, gacar Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor browser (hardened-6.0a4) writes a file called SiteSecurityServiceState.txt that has a list of sites I've visited. E.g. it has "en.wikipedia.org" and that definitely wasn't there after I first ran TB. It didn't appear right away when I visited Wikipedia but eventually made it to disk (maybe it writes every few minutes or just at shutdown).

I have all history disabled in privacy prefs (except cookies but they're only till shutdown according to the dropdown). I expect TB will not write history without consent, and I did not approve or even get a warning about this file. I don't even see an obscure option (about:config) to disable it. I guess I'll try symlinking /dev/null, and otherwise write some $LD_PRELOAD to fail the open().

I understand there are security benefits but unless the user has enabled some form of history I don't think it's acceptable. You could ship a default file with popular sites preloaded.

Child Tickets

Change History (18)

comment:1 Changed 3 years ago by gk

Status: newneeds_information

Hm... is this file still there for you if you close the session? And does it come back after you deleted it while Tor Browser was closed? According to https://bugzilla.mozilla.org/show_bug.cgi?id=1230559 this should help.

comment:2 Changed 3 years ago by gk

Keywords: tbb-disk-leak added

comment:3 Changed 3 years ago by gk

It comes back at least. The implementation of that feature is in https://bugzilla.mozilla.org/show_bug.cgi?id=775370.

comment:4 Changed 3 years ago by gk

Keywords: tbb-newnym added
Priority: MediumHigh
Severity: NormalMajor
Status: needs_informationassigned

And it is not cleared after closing the session, sigh.

comment:5 Changed 3 years ago by mcs

Here is an article that Google turned up which includes some ways to mitigate this problem; none are ideal though: http://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/

comment:6 Changed 3 years ago by bugzilla

Clear All History / Site Preferences clears SiteSecurityServiceState.txt
So, why was tbb-newnym added?

And it is not cleared after closing the session, sigh.

Because FF clears it after exiting PBM, but in TBB it is permanent.

Keywords tbb-disk-leak added

No leak, file is in profile folder as any other preference.
UPDATE: Design Guide classifies HSTS as a privacy threat rather than a security pref (it's both, in fact), and it was fixed by #2950, so it's a regression.

Last edited 3 years ago by bugzilla (previous) (diff)

comment:7 Changed 3 years ago by arthuredelstein

Cc: arthuredelstein added

comment:8 Changed 3 years ago by gk

Keywords: tbb-newnym removed

The NEWNYM issue is dealt with in #19995.

comment:9 Changed 3 years ago by mcs

Cc: mcs added

comment:10 Changed 2 years ago by gk

Cc: gacar added

We might want to look at the amount of sites that provide HSTS/HPKP headers while not being on the preload list. If the amount of those sites is small (or if the amount of those sites in the top 1,000,000 sites is small?) we might want to think about clearing the state after a session as well.

comment:11 in reply to:  10 Changed 2 years ago by gacar

Replying to gk:

We might want to look at the amount of sites that provide HSTS/HPKP headers while not being on the preload list. If the amount of those sites is small (or if the amount of those sites in the top 1,000,000 sites is small?) we might want to think about clearing the state after a session as well.

I compared the preloaded STS sites on mozilla-central [0] to top 1 million sites that send STS headers [1].

There were:

  • 18317 preload sites
  • 39408 sites that send STS headers in top million

Only 1883 of the 39408 STS sites found in the preloaded list. I took include_subdomains into consideration when matching the domains in two list.

[0]: https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc
[1]: https://scans.io/study/scott-top-one-million (version: 14/3/2017)

comment:12 Changed 2 years ago by gacar

Although the number of preloaded STS sites is small, popular STS sites are more likely to be included in the preload list:

Site rank # of preloaded STS sites
/
# of STS enabled sites
Top 10 33%
Top 100 24%
Top 1K 16.5%
Top 10K 12.5%
Top 100K 8.5%
Top 1M 4.7% (1883/39408)

Anyways, I think the privacy risk of revealing browsing history still outweighs the potential security benefits.

PS: I should also note that I couldn't completely reproduce the problem with 6.5.1 and 7.0a2 on Linux 64. Although I visited several sites that send HSTS headers, only a few TPO and AMO-related domains (aus1.torproject.org, www.torproject.org, aus1.torproject.org) added to the SiteSecurityServiceState.txt  (something to do with the chrome vs content connections?).

comment:13 in reply to:  12 ; Changed 2 years ago by gk

Replying to gacar:

PS: I should also note that I couldn't completely reproduce the problem with 6.5.1 and 7.0a2 on Linux 64. Although I visited several sites that send HSTS headers, only a few TPO and AMO-related domains (aus1.torproject.org, www.torproject.org, aus1.torproject.org) added to the SiteSecurityServiceState.txt  (something to do with the chrome vs content connections?).

Interesting. Does the same happen with a vanilla Firefox 45.8.0esr? How did you test that?

comment:14 in reply to:  13 Changed 2 years ago by gacar

Replying to gk:

Interesting. Does the same happen with a vanilla Firefox 45.8.0esr? How did you test that?

No, Firefox 45.8.0esr stores the HSTS and HPKP pins from all sites.

I start with a fresh profile, visit HSTS/HPKP enables sites such as github.com, ssllabs.com and metrics.torproject.org. Then I close the browser and check the SiteSecurityServiceState.txt contents.

Vanilla ESR stores GitHub, ssllabs and metrics.torproject.org HSTS (and HPKP where available) pins, whereas TB only stores entries related to torproject.org.

comment:15 Changed 2 years ago by cypherpunks

Tor Browser does that only for requests from its parts that are not in Private Browsing. See #20491.

comment:16 Changed 13 months ago by bloginfo

You can disable this history , by giving the false value to the network.stricttransportsecurity.preloadlist key in about:config.

comment:17 in reply to:  16 Changed 13 months ago by gk

Replying to bloginfo:

You can disable this history , by giving the false value to the network.stricttransportsecurity.preloadlist key in about:config.

Well, it seems you disable at least part of the strict security feature that way, but that's what we do not want to do. We only want to avoid writing the usage history to disk.

comment:18 Changed 4 months ago by arma

irc discussion clarifying what remains on this ticket:

> so maybe #18589 is finished, since it's only the internal chrome stuff that gets recorded? so long as this is a result of an active configuration choice made by tor browser, and not a coincidence that will get reverted later by accident?
<GeKo> yes, that could be the case. however, there might be timestamps stored that give hints on when the update checks happened
<GeKo> so, there are still trade-offs here
<GeKo> and someone needs to track down what actually happens
<GeKo> and whether that's okay in all (corner)-cases
<GeKo> then we can make a decision of either fixing the bug or closing it as won't fix and adjust our design doc
Note: See TracTickets for help on using tickets.