[tor-bugs] #22966 [Applications/Tor Browser]: Nasty MitM possibility with the Firefox blocklist service

[Tor Bug Tracker & Wiki]

#22966: Nasty MitM possibility with the Firefox blocklist service
--------------------------------------+--------------------------
 Reporter:  basvd                     |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  High                      |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Major                     |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by tom):

 It's intentional that certificate errors are ignored. We have to deal with
 tls-intercepting and messed up middleboxes. Updates are the same way.
 Blocklists should be signed, and edited blocklists (such as with Burp)
 should not be accepted. If you can find a way to bypass that, please file
 a Mozilla security bug and collect a nice bounty.

 Replying to [comment:4 yawning]:
 > Replying to [comment:3 basvd]:
 > > Blocklist is using this one: extensions.blocklist.enabled (..and
 that's default true)
 >
 > So their "Privacy Notice" is full of shit and links to incomplete opt
 out documentation.  Like I said, I don't doubt that this happens.

 Describing it as 'full of shit' seems inaccurate to me. It links to
 incorrect documentation and thus is misleading people about actually
 opting out, but it clearly describes that it collects technical
 information that can be used to identify people.

 I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1382006 to address
 the incorrect information.



 I am confused why the add-on blocklist is (attempted) to be disabled via
 the old pref. Extension blocklisting and updating (and that it is enabled
 in Tor Browser) is discussed in detail in #21200 and is actually targeted
 as the first onion service Mozilla deploys. That is behind schedule but
 nonetheless - the fact that it's used in Tor Browser was (I thought) well
 established.

 The certificate thing is a misunderstanding. Breaking TLS sounds bad, but
 shouldn't matter in practice.

 That Mozilla could block Tor Extensions (like Tor Launcher) also sounds
 bad, but also in practice doesn't matter - when this is done the browser
 stops working but does not bypass the (no-longer-present) proxy. If Tor
 wanted to turn off blocklist updating nonetheless, I'd say that's
 reasonable since we discourage users from installing custom extensions and
 in general don't support that use case.

 If you can find a way for Mozilla to force install extensions, flip prefs,
 or update extensions outside of the extension developer's control[0] -
 that would be a very concerning bug.

 Mozilla *can* revoke CAs unilaterally without Tor's control via OneCRL.

 [0] I know HTTPS Everywhere uses a separate additional signing key that
 Mozilla doesn't control that should prevent Mozilla from pushing updates.
 I actually haven't checked NoScript but I hope it does the same?

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