Why HTTPS Everywhere isn't on addons.mozilla.org
lists.eff.org
lists.eff.org
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.
Aren't there many ways you could make it safer still?
Should we trial this medicine on humans? No, that's another pointless crusade. Aren't there many other ways you could make it safer still? Your argument applies to any requirement and thus to none.
Weigh that against the many thousands more that might be
experiencing the benefits
Why commercial enterprises still aren't providing even a fraction of the level of archive integrity assurance completely volunteer free software projects were decades ago is utterly beyond reason.
Security is determined by weakest link. Right now it's AMO.
I would be disappointed if a security add on could easily be circumvented because of a poor choice of distribution.
Keep in mind that such security addons may be used by activists and journalists in hostile environments, you do have a different opinion when overlooking this kind of details could mean imprisonment and torture.
I find it quite ironic that HTTPS Everywhere is arguing HTTPS is not safe enough to offer them a reasonable guarantee of integrity.
HTTPS might be better than getting a website in cleartext, but you'd have to be a madman to claim that HTTPS is safe, sane, or secure.
Force SSL only: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Have site preloaded in Chrome: https://hstspreload.appspot.com
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.
Nothing is 100% secure.
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.
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.
If a mirror isn't updated, the user is eventually warned during updates:
> E: Release file for http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 20min 30s). Updates for this repository will not be applied.
It mostly negates the need for https mirrors for authenticity, although many still offer it. To my knowledge, most projects with mirror networks operate similar to this.
[1] e.g. https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates... has the pseudo-header Valid-Until: Tue, 02 Dec 2014 20:50:35 UTC
RPMs are usually signed directly.
Without cert pinning here's also the problem of the attacker convincing some browser-trusted CA to issue an SSL cert for addons.mozilla.org, then MITMing you with that.
(And with 600+ trusted roots, many of which are owned by various governments, against state level attackers an ssl connection's claim of authenticity has to be considered very close to worthless...)
In the case of Firefox connecting to addons.mozilla.org, there is cert pinning.
(In retrospect, it's such an obvious thing for them to do - I don't know why I didn't assume it was likely enough to be implemented and check before I posted that...)
All they need is an authorised certificate.
More people should be aware of SSL Strip and how to protect yourself against it.
Not in the case of Firefox connecting to AMO, because it uses a pinned certificate for that.
I perform HTTPS interception on all out-bound traffic on my network and I don't recall making an exception for AMO, and I have a number of add-ons installed. Though, it wouldn't be the first time I've forgotten about something like that.
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.
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.
HTTPS provides a secure connection, in theory, but what if AMO is itself compromised? They are just a 3rd party host for the EFF's extension, after all.
HTTPS or not, the only way to check that the code you get from AMO is the same code the EFF gave AMO, is to check it against the EFF's signature.
Not to also mention, MITM attacks on the actual SSL connection.
Serving over HTTPS isn't a valid package signing strategy.
The AMO cert is pinned in Firefox. If you MITM the connection, Firefox will refuse to connect to it.
This is why the company I work for created PanicMode (https://chrome.google.com/webstore/detail/panic-mode/lamdafc...).
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.
Also, any interest in porting it to Firefox?
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.
- 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.
- amo wasnt affected by heartbleed
- signatures arent foolproof either
- HTTPS everywhere.. is supposed to advocate for TLS being
safe ?
Since this was from April, I wonder what has happened since then? Has Firefox added public key pinning or the other option presented?
You can check the latest status at https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
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
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.
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.
-- an HTTPS everywhere user
HTTPS Everywhere means MITM Everywhere. It makes interception easier.
HTTPS everywhere has way too much overhead.
There should be a built-in hsts editor.
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.