
Why HTTPS Everywhere isn't on addons.mozilla.org - sinak
https://lists.eff.org/pipermail/https-everywhere/2014-April/002050.html
======
Steko
"main reason I haven't put it in AMO _yet_ is because AMO offers _less_
security to users than EFF self-hosting it"

Another pointless crusade. Aren't there many ways you could make it safer
still? Wouldn't some of those be really dumb because they would prevent many
people from accessing the add on?

How many people are you making more secure? Close to no one because 98% of
Firefox https everywhere users have some other add on from AMO. Weigh that
against the many thousands more that might be experiencing the benefits of
your add on if it were hosted where 99% of add ons people use are hosted.

~~~
n09n
It's almost as if their priorities aren't the same as yours.

~~~
Steko
My priorities are completly irrelevant here, I've been a happy user of https
everywhere since idk since I heard of it (years? idk). My criticism is that
their own stated priority is being crippled by a self-imposed and arbitrary
rule.

~~~
cbr
It looks to me like they're trying to use not being in AMO as leverage to get
Mozilla to implement additional security features. If they said "we'd like
these features, but we're ok being in AMO in the mean time" Mozilla would
probably mostly ignore them, and these are generally useful features that
should help others if developed.

------
johannh
> 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.

I find it quite ironic that HTTPS Everywhere is arguing HTTPS is not safe
enough to offer them a reasonable guarantee of integrity.

~~~
geofft
HTTPS is a lower bound of reasonable security, not an upper one. The argument
for HTTPS _everywhere_ is that it's the smallest possible thing you can do to
make yourself slightly secure.

Would you find it ironic that someone selling combination locks for gym
lockers wants a better lock on their storefront?

~~~
riquito
> Would you find it ironic that someone selling combination locks for gym
> lockers wants a better lock on their storefront?

More like he wants to add additional security measures because the lock isn't
secure enough. I wouldn't buy a lock then.

~~~
philtar
It's called layering.

Nothing is 100% secure.

------
blcknight
Old... but interesting, I guess.

From the bug report:

> We don't require update.rdf files to be signed when they're served over
> HTTPS, since HTTPS provides the same level of verification as an updateKey,
> and we don't see significant benefit to the additional level of
> verification.

I'm kind of confused by that comment - Mozilla are saying that signing the
software itself is somehow the same as serving it over HTTPS? Think about
other software repositories. That's like saying serving Fedora packages over
HTTPS is the same as signing the RPM's... it's not, and it's kind of an absurd
thing to suggest.

You can independently verify the signature of the RPM itself, offline, outside
of the browser. I can't see how that could be considered anything but a
significant benefit.

~~~
fastball
I think the idea is that you don't need the extra security of signing, because
if the file was served over HTTPS then you can be secure in the knowledge that
it has not been modified.

The reason you sign packages is to ensure that the file you want and the file
you get are actually the same. If you have a secure connection to the trusted
host of said file, you don't need to worry about that.

~~~
mikeash
The difference is that signed code lets you keep the signing key offline, and
therefore it can be much more secure.

For a concrete example, consider the case where the server is compromised and
an attacker wants to insert malware. HTTPS does nothing at all to help, here.
The attacker has control over the server and can make it serve whatever it
wants, and since the server still has its normal certificate and key, the
attacker's malware-infested code will show up just like legitimate stuff
would. If the code was signed using a key that isn't kept on the server
(normally a code signing key will be kept on a developer's computer, and often
protected by a password so it rarely exists in memory unencrypted) then the
attacker can't force the server to serve malware that will be accepted by
downloaders.

~~~
pserwylo
> If the code was signed using a key that isn't kept on the server (normally a
> code signing key will be kept on a developer's computer, and often protected
> by a password so it rarely exists in memory unencrypted)

And to take this even further, you have the option of keeping the key on a
machine that is completely disconnected from any network. In addition, this
machine could use a Hardware Security Module to further increase the security
of the signing key.

------
passfree
HTTPS is a good idea but it really doesn't work for me. I am one of those
paranoid people who want full end-to-end SSL without exceptions. HTTPS
Everywhere doesn't fill the bill.

This is why the company I work for created PanicMode
([https://chrome.google.com/webstore/detail/panic-
mode/lamdafc...](https://chrome.google.com/webstore/detail/panic-
mode/lamdafciglhnjofdfejeepoemldmblkb)).

PanicMode is ridiculously simple extension. Once activated, it will swap HTTP
for HTTPS without leaking even a single packet. Not even pre-flight requests
are spared.

PanicMode is not good for general purpose browsing mainly because 99% of the
site break badly, i.e. they do not support SSL at all. That is very telling
and sad reality. The way I use it is with profiles. I have a bunch of chrome
profiles that I use for different purpose. One of my profiles is just for
social browsing - facebook etc. I have another one for company stuff. Those
profile have panic mode installed and activated. Because I care about security
in those profiles I don't mind if I click on a facebook link and it doesn't
open up because at least I know that I am protected against side-channel
attacks.

It is a very simple mechanism but works well when used effectively.

~~~
goblin89
> PanicMode is ridiculously simple extension. Once activated, it will swap
> HTTP for HTTPS without leaking even a single packet. Not even pre-flight
> requests are spared.

Sounds pretty cool and useful to me. As it tends to happen, though, all
promises of additional security a Google Chrome extension makes are
invalidated by a single notice—

> Panic Mode can read and change all your data on the websites you visit

As a side note, I noticed that lately my sensitivity to these kinds of threats
has come down significantly due to multitude of useful extensions and apps
requiring ridiculous permissions. Seems like a dangerous trend: not knowing
that an app is going to do sneakily collect your data is one thing; knowingly
and willingly grant every little extension wildcard access time after time is
quite another. I was very happy to ditch Android because of that. Perhaps I’m
too paranoid, of course.

------
zobzu
Im all for signing stuff but:

\- amo wasnt affected by heartbleed

\- signatures arent foolproof either

\- HTTPS everywhere.. is supposed to advocate for TLS being safe ?

So the criticism seems quite misguided in this case.

~~~
Confusion

      - amo wasnt affected by heartbleed
    

If you only address issues that have already happened, you will never provide
adequate _protection_. The point is to ensure sane behavior when AMO _is_
affected by some exploit.

    
    
      - signatures arent foolproof either
    

Yeah, and actually, why bother with HTTPS at all: it's not foolproof, is it?

    
    
      - HTTPS everywhere.. is supposed to advocate for TLS being 
        safe ?
    

No, it advocates for TLS being safe _if used with HTTPS everywhere_. So
_before_ you have HTTPS everywhere enabled, you need an additional measure.

~~~
zobzu
you contradicted yourself here - or voluntarily misunderstood the point.

------
anonfunction
> Once public key pinning lands in Firefox (supposedly scheduled to happen
> this summer)

Since this was from April, I wonder what has happened since then? Has Firefox
added public key pinning or the other option presented?

~~~
reedloden
Yes, Firefox has supported public key pinning for a while now.

You can check the latest status at
[https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning)

~~~
anonfunction
Thanks.

------
justcommenting
and yet: [https://addons.mozilla.org/en-US/firefox/addon/privacy-
badge...](https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-
firefox/?src=search)

Given the inconsistency of EFF and Mozilla's "policy" on this issue, plausible
context to what's written might include something like an inability to
upstream HTTPSEverywhere into Firefox by default due to political pushback
from large advertising sponsors of Mozilla. EFF certainly resolved these
issues for PrivacyBadger, which nevertheless has problems of its own.

Similarly, working with Mozilla to make AMO more secure for everyone by
default seems like a pretty straightforward and desirable option for EFF. it's
unclear why that hasn't happened here..and perhaps having useful code
upstreamed into a larger project doesn't earn people enough credit and
recognition. maybe we'll see a BetterAMOEverywhere extension that would enable
EFF to integrate HTTPSEverywhere into AMO. ;-)

Yet here we are in 2014 with HTTPSEverywhere not baked into Firefox by default
default and a world in which non-techies can't even find what should be
browser-integrated functionality in the same place they find most other
extensions. Awesome.

The effect for most users is not unlike the the sort of bikeshedding over GPL
vs. BSD licenses that has kept so much of the internet in plaintext [0].

[0] as mentioned in phk's 'operation orchestra' talk

~~~
edraferi
_...working with Mozilla to make AMO more secure for everyone by default seems
like a pretty straightforward and desirable option for EFF. it 's unclear why
that hasn't happened here._

The bug report [1] was closed as WONTFIX. Essentially, AMO is more worried
about malicious updates by extension authors than hijacking of legitimate
extensions:

 _The "hijacking" we worry about is from the addon authors themselves: we
review and OK a benign add-on and then it self-updates into malware or adware.
This is not a hypothetical worry. The EFF isn't going to do that, obviously,
but the number of entities we trust to that extent who cannot simply host on
AMO is so small that we can't spare the coding resources to create an
exception mechanism._

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=999014](https://bugzilla.mozilla.org/show_bug.cgi?id=999014)

~~~
justcommenting
to me, WONTFIX is just a signal that personal conversations with Mozilla devs
as humans--or at least a more subtle understanding of why Mozilla's not
budging--are that much more important as next steps.

and i don't necessarily disagree with the technical merits of EFF's position,
either. but what does it say about EFF if they don't feel the same way about
PrivacyBadger being available through AMO? seems inconsistent, if we're to
take the given rationale at face value.

and more broadly, it seems clear that if EFF's goal is to maximize the number
of people using HTTPSEverywhere, the status quo for providing access to their
code is not optimal.

i hope Mozilla/EFF will be able to work out a solution that increases the
availability of HTTPSEverywhere's functionality.

------
mtmail
Would addons.mozilla.org really have to store the private keys of the
developers as the discussion on bugzilla
[https://bugzilla.mozilla.org/show_bug.cgi?id=999014](https://bugzilla.mozilla.org/show_bug.cgi?id=999014)
(closed as 'invalid' 4 month ago) implies? How does the Chrome store do it?

~~~
jessaustin
Only if that service intended to do some signing on the developers' behalf,
which could make sense for cases like this in which app data would be updated
more often than app code.

------
joelthelion
What a great way to make sure no one uses their add on.

\-- an HTTPS everywhere user

------
Animats
HTTPS Everywhere is security theater. Encrypting everything creates pressure
to cache encrypted content, using "caching services" such as Cloudflare. If it
goes through Cloudflare, it's decrypted at Cloudflare. Cloudflare is a man-in-
the-middle.

HTTPS Everywhere means MITM Everywhere. It makes interception _easier_.

------
ck2
You should be using the hsts policy list in firefox anyway.

HTTPS everywhere has way too much overhead.

There should be a built-in hsts editor.

------
joshAg
> 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!

WHY IN THE WORLD AREN'T YOU USING AN HSM!?!?! If you're at the point where you
feel the need for a dedicated airgapped machine to hold the signing key, then
you are at the point where you need an HSM.

------
JBiserkov
Even better, why HTTPS everywhere is not a default, in all browsers?

