Why HTTPS Everywhere isn't on addons.mozilla.org
41–50 of 61 posts
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#42and yet: https://addons.mozilla.org/en-US/firefox/addon/privacy-badge... 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…
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#43Earlier quoted context omitted.
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?
> 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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#44Earlier quoted context omitted.
A MITM attack? What then? Seems you need signing then.
Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
All they need is an authorised certificate.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#45"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 a…
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#46"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 a…
Security is determined by weakest link. Right now it's AMO.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#47Earlier quoted context omitted.
So with the system of mirrors that is in place with distributing some open source software (e.g. debian, ubuntu, etc.) this is less true. A local mirror could selectively serve bad packages (and serve the correct packages to the verification bots).
Debian has a pretty nice mirroring system. Not only are all packages signed, but the Release file (which includes checksums of package lists) is also signed, preventing a mirror from omitting packages. For repositories which receive security updates (say, wheezy-updates), the index is valid for only few days in the future, which helps to prevent mirrors from withholding security updates [1]. If a mirror isn't updated…
RPMs are usually signed directly.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#48HTTPS 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... ). PanicMode is ridiculously simple extension. Once activated, it will swap HTTP for HTTPS without leaking even a single p…
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#49Earlier quoted context omitted.
A MITM attack? What then? Seems you need signing then.
Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
More people should be aware of SSL Strip and how to protect yourself against it.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#50Earlier quoted context omitted.
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.
All someone needs to do is hack the AMO servers and change out the XPI -- and no one would no the difference, because the packages aren't signed. 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.