[tor-bugs] #8557 [Firefox Patch Issues]: Audit and possibly enable safebrowsing

[Tor Bug Tracker & Wiki]

#8557: Audit and possibly enable safebrowsing
----------------------------------+-----------------------------------------
 Reporter:  mikeperry             |          Owner:  mikeperry
     Type:  defect                |         Status:  new      
 Priority:  major                 |      Milestone:           
Component:  Firefox Patch Issues  |        Version:           
 Keywords:  tbb-pref              |         Parent:           
   Points:                        |   Actualpoints:           
----------------------------------+-----------------------------------------

Comment(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.

 > 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?

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

 > 3. 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).

 > 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)?

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

 > 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?

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8557#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online