Opened 5 years ago

Last modified 3 months ago

#8557 new defect

Audit and possibly enable safebrowsing

Reported by: mikeperry Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-pref, tbb-firefox-patch
Cc: cl34r, g.koppen@…, francois@…, luke.crouch@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

TBB currently disables safebrowsing. I would like to answer the following questions before we enable it:

  1. Does Firefox stop fetching safebrowsing data if the browser is inactive? The spec says the list is updated every 30 minutes, but doesn't say anything about user activity.
  2. The data itself is authenticated, but it is also served over HTTP, and the protocol supports requesting specific lists and segments. This introduces the ability of exits to repeatedly block list segments in an attempt to create a supercookie in the client that appears like it can persist for up to 6 hours (based on the retry behavior in https://wiki.mozilla.org/Phishing_Protection:_Design_Documentation#Client_Backoff). Is there a way for exits/websites to read this supercookie at will?
  3. Related: Should we clear the safebrowsing list data on New Identity (or does this just cause a lot of pointless network overhead)?
  4. Clearing the list data might also cause an immediate re-download of all lists and segments. Does it? Do we care about leaking this to the exit (who can then infer that we just clicked New Identity)?
  5. It looks like we definitely would need to clear the MAC key on New Identity. How do we do that? Does doing so invalidate our previous list data?

Child Tickets

Change History (13)

comment:1 Changed 5 years ago by mikeperry

Description: modified (diff)

comment:2 Changed 5 years ago by gk

Cc: g.koppen@… added

comment:3 Changed 5 years ago by cl34r

Heres what I have been able to collect so far:

  1. Does Firefox stop fetching safebrowsing data if the browser is inactive? The spec says the list is updated every 30 minutes, but doesn't say anything about user activity.

Not to my knowledge. The goal is to keep the list up to date such that when you do browse, you're browsing with an up-to-date list for protection.

  1. The data itself is authenticated, but it is also served over HTTP, and the protocol supports requesting specific lists and segments. This introduces the ability of exits to repeatedly block list segments in an attempt to create a supercookie in the client that appears like it can persist for up to 6 hours (based on the retry behavior in https://wiki.mozilla.org/Phishing_Protection:_Design_Documentation#Client_Backoff). Is there a way for exits/websites to read this supercookie at will?

I'm not entirely sure about this one. I might ask about it on the Firefox mailing list.

  1. Related: Should we clear the safebrowsing list data on New Identity (or does this just cause a lot of pointless network overhead)?

I believe it's stored in urlclassifier3.sqlite (if you wanted to clear it).

  1. Clearing the list data might also cause an immediate re-download of all lists and segments. Does it? Do we care about leaking this to the exit (who can then infer that we just clicked New Identity)?

Eventually, yes, it does cause a re-download. As for the exit leaking, I'll leave that up to higher authority.

  1. It looks like we definitely would need to clear the MAC key on New Identity. How do we do that? Does doing so invalidate our previous list data?

You can request a new MAC key without invalidating the previous list data, but it's probably easier (and safer) just to use the protocol over HTTPS and not use MAC keys at all. Furthermore, a MITM could block updates but should not be able to insert/remove a specific site from the list. There's now an option to use the protocol entirely over HTTPS and ditch the MAC / "wrapped key", which is now in use by Chrome. We should ask Mozilla how to enable this in Firefox.

I'm still looking into this a bit. I will try to ask some questions on the Firefox mailing list and see if I can get anymore answers.

comment:4 Changed 5 years ago by cl34r

Also, it appears that Firefox transmits your normal Google cookies with safebrowsing requests for "quality of service".

comment:5 Changed 3 years ago by erinn

Keywords: tbb-firefox-patch added

comment:6 Changed 3 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Owner: changed from mikeperry to tbb-team

comment:7 Changed 3 years ago by vynX

The freshclam tool of the clamav package provides the facility of mirroring safebrowsing data sets from the clamav servers. Safebrowsing could therefore be configured to run from the local data only and stop interaction with Google servers for so little gain.

comment:9 Changed 3 months ago by fmarier

Severity: Blocker

The Safe Browsing service has changed a lot since this ticket was filed.

I wrote a detailed blog post about the Firefox implementation and I keep this wiki page up-to-date with everything I know about the service and our implementation.

A few quick notes:

  • it's all HTTPS now
  • there are no more MAC keys
  • list fetching is not based on user activity, it's on whenever the browser is running
  • the cookie has a unique origin attribute so it's not mixed with the other Google cookies (and I believe it will be gone in V4 of the API, Fx 56+)

comment:10 Changed 3 months ago by fmarier

Cc: francois@… added

comment:11 Changed 3 months ago by groovecoder

Cc: luke.crouch@… added

comment:12 Changed 3 months ago by fmarier

Severity: BlockerNormal

Looks like I accidentally changed the priority while adding comment 9.

Not sure what the original priority was so I'll just reset it to normal.

comment:13 Changed 3 months ago by sjmurdoch

Cc: sjmurdoch removed
Note: See TracTickets for help on using tickets.