Why HTTPS Everywhere isn't on addons.mozilla.org
lists.eff.org
Why HTTPS Everywhere isn't on addons.mozilla.org
1–10 of 61 posts
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#2Would 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 (closed as 'invalid' 4 month ago) implies? How does the Chrome store do it?
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#3Old... 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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#4Would 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 (closed as 'invalid' 4 month ago) implies? How does the Chrome store do it?
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#5Old... 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? T…
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#6Old... 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? T…
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.
A MITM attack? What then? Seems you need signing then.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#7Earlier 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.
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#8and 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 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
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#9Earlier 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.
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).
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#10Earlier 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.
Unless, as the article points out, the attacker has your private SSL key (perhaps leaked via Heartbleed).
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...)