[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22966 [Applications/Tor Browser]: Nasty MitM possibility with the Firefox blocklist service
#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 yawning):
Replying to [comment:5 tom]:
> > 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.
The opt out instructions don't work.
> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1382006 to address
the incorrect information.
Thank you.
> 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.
It might even make it to production before a Tor Browser release that
disables the "Get Addons" pane (#22073).
> 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.
I just pushed a commit to the sandboxed version that forces it off,
because the container setup explicitly only exposes standard extensions
within the container.
> [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?
The XPI says "yeah right" (Keys/signatures omitted for brevity).
{{{
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1496120746499 (0x15c57bee203)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production
Signing Service, CN=production-signing-ca.addons.mozilla.org/emailAddress
=services-ops+addonsigning@xxxxxxxxxxx
Validity
Not Before: May 30 05:05:46 2017 GMT
Not After : May 29 05:05:46 2022 GMT
Subject: OU=Production, C=US, L=Mountain View, O=Addons, ST=CA,
CN={73a6fe31-595d-460b-a920-fcc0f8843232}
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1048578 (0x100002)
Signature Algorithm: sha384WithRSAEncryption
Issuer: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production
Signing Service, CN=root-ca-production-amo
Validity
Not Before: Mar 17 23:52:42 2015 GMT
Not After : Mar 14 23:52:42 2025 GMT
Subject: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production
Signing Service, CN=production-signing-ca.addons.mozilla.org/emailAddress
=services-ops+addonsigning@xxxxxxxxxxx
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22966#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs