Earlier 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.
Someone better tell these guys to stop selling SSL MITM hardware, then.
Why HTTPS Everywhere isn't on addons.mozilla.org
11–20 of 61 posts
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#12> 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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#13Earlier quoted context omitted.
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).
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, 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
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#14> 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.
Shouldn't be terribly surprising: http://dayswithoutansslexploit.com
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#15Old... 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.
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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#16> 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.
Shouldn't be terribly surprising: http://dayswithoutansslexploit.com 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.
True, I'm not surprised at all. HTTPS Everywhere-like functionality should be integrated into browsers and not a downloadable extra, tricking people into feeling fully secured.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#17> 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?
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#18"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.
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#19> 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?
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...
Re: Why HTTPS Everywhere isn't on addons.mozilla.org
#20Earlier quoted context omitted.
Shouldn't be terribly surprising: http://dayswithoutansslexploit.com 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.
True, I'm not surprised at all. HTTPS Everywhere-like functionality should be integrated into browsers and not a downloadable extra, tricking people into feeling fully secured.
While not "everywhere"...
Force SSL only: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Have site preloaded in Chrome: https://hstspreload.appspot.com