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

[Yan Zhu]

On 04/21/2014 11:14 AM, Yan Zhu wrote:
> 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

Wow, that sure got marked as invalid and closed quickly. It seems that
at least one Mozilla dev. is strongly against considering this option.

Probably going to go with #2.

> 
> 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/4b4e6fba/attachment.sig>