[HTTPS-Everywhere] HTTPS-Everywhere needs to be on firefox addons

[Yan Zhu]

Hi all,

The good news is that HTTPS Everywhere is going in AMO eventually. The
question is when.

The main reason I haven't put it in AMO *yet* is because AMO offers
*less* security to users than EFF self-hosting it, ironically. AMO
doesn't do any code signing for extensions, so they're only protected by
HTTPS. As we saw with Heartbleed, SSL private keys can be compromised.

Why wasn't HTTPS Everywhere affected by Heartbleed? Because we sign
updates with an offline signing key that EFF keeps on a dedicated
airgapped machine. So even if SSL is totally broken, the integrity of
updates is guaranteed. Yay!

Luckily the AMO update servers weren't using a vulnerable version of
OpenSSL, even though the servers that hosted static files (favicons,
etc.) were. Had the update servers been affected by Heartbleed, someone
could push a malicious update to almost any addon that you had installed
from AMO. This is pretty terrifying, given that a malicious Firefox
addon can completely and invisibly pwn your browser.

So there's two situations that would make me comfortable with putting
HTTPS Everywhere in AMO:

1. AMO allows us to sign updates with our offline signing key, which is
what Chrome Web Store already does. This is *by far* the easiest route
from my perspective. I have opened a bug with Mozilla; please star it!
https://bugzilla.mozilla.org/show_bug.cgi?id=999014

2. Once public key pinning lands in Firefox (supposedly scheduled to
happen this summer), we can sign HTTPS Everywhere with a CA-signed
certificate via this arcane process:
https://developer.mozilla.org/en-US/docs/Signing_a_XPI. It would take
some wrangling to make it work with an offline private key but probably
not impossible.

More info inline, but the above was the gist of it.

On 04/20/2014 01:58 PM, Dave Warren wrote:
> On 2014-04-20 12:53, Andrew Sillers wrote:
>>
>> Without further comment, I'll call out:
>>
>> * the FAQ entry on this topic:
>> https://www.eff.org/https-everywhere/faq#amo
>>
> 
> This one doesn't seem to make sense to me. The Mozilla privacy policy
> would only apply to Mozilla possibly keeping track of who downloads the
> add-on, but wouldn't automatically make the add-on start intruding on
> privacy somehow, would it?

This answer is outdated; as mentioned above, the privacy policy isn't
the blocker anymore. Will update the FAQ.

> More importantly, if a user is happy with a less restrictive privacy
> policy, what's the problem?

Nothing in particular, except that we realize that users rarely read
privacy policies. So there is an argument for developers to provide them
with the maximum amount of privacy by default (which is supposedly what
we do by not making AMO an option).

This is kind of a moot point because I think the popularity benefit of
being in AMO outweighs the minor-and-possibly-hypothetical privacy loss.

>> * the extant discussion on this topic in the bug tracker:
>> https://trac.torproject.org/projects/tor/ticket/9769
>>
> 
> While the approval process is a factor, having some code in the rulesets
> that says "Do not apply this rule to versions below 'x'" should negate
> the issue of time-sensitive rules, save for the fact that an
> incompatible rule simply won't run until the extension is updated. A
> small price to pay for making this easy and safe for users.

It seems that you're talking about a tangential issue here, which is
whether/how ruleset updates should be hosted if/when we get to a point
where ruleset updates are independent from extension updates (which will
happen if Zack's GSoC project works out). AFAIK, there is no way in AMO
to let us update rulesets without updating the entire extension, so we
will need to self-host ruleset updates if we want them to be separate
from extension updates.

> 
> As far as signing, the ruleset update signing has already been discussed
> and can still be done separate from rule updates using EFF's key.

Confused here. What's the difference between "ruleset update" and "rule
update"?

> 
> It ultimately may not be as simple as just uploading to Mozilla and
> being done with it, but it's pretty close to that and it's not as though
> EFF is releasing frequent enough updates for Mozilla's slight delay to
> be a significant factor, at least IMO.
> 


-- 
Yan Zhu  <yan at eff.org>, <yan at torproject.org>
Staff Technologist
Electronic Frontier Foundation                  https://www.eff.org
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x134

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140421/62d2c620/attachment.sig>