Why HTTPS Everywhere isn't on addons.mozilla.org

Post by bzbarsky » Wed, Nov 26, 2014, 4:03 PM UTC

click170 wrote: post #49

Iburinoc wrote: post #7

Earlier quoted context omitted.

Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.

Its possible to MITM an HTTPS connection, trick you into thinking it is secure by providing a green lock favicon, and intercepting or sniffing everything you do over that connection. And it will work on nearly every website in existance. More people should be aware of SSL Strip and how to protect yourself against it. http://www.thoughtcrime.org/software/sslstrip/

Post by justcommenting » Wed, Nov 26, 2014, 5:15 PM UTC

edraferi wrote: post #42

justcommenting wrote: post #8

and 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…

...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 revie…

Post by bigiain » Wed, Nov 26, 2014, 10:38 PM UTC

bzbarsky wrote: post #52

bigiain wrote: post #10

Earlier quoted context omitted.

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 authenti…

> Without cert pinning In the case of Firefox connecting to addons.mozilla.org, there is cert pinning.

Post by bzbarsky » Thu, Nov 27, 2014, 6:32 AM UTC

bigiain wrote: post #55

bzbarsky wrote: post #52

Earlier quoted context omitted.

> Without cert pinning In the case of Firefox connecting to addons.mozilla.org, there is cert pinning.

I didn't know that, thanks. (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...)

Post by fastball » Tue, Dec 02, 2014, 10:02 PM UTC

snowwrestler wrote: post #22

fastball wrote: post #5

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

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