Users shouldn't download untrusted executables over untrusted networks and run them, because of the risk of MITM attacks. See, e.g. "Insecurities within automatic update systems" by P. Ruissen, R. Vloothuis. I'd guesstimate that under 1% of Firefox downloads are secured against MITM attack. In theory, very skilled users can use the SHA1SUMS.asc file and gpg to protect themselves, but it's a PITA, and there are no instructions. Users who are both skilled and clairvoyant could calculate checksums and come up with a working HTTPS URL from which to download the checksums securely. Remember, most users find the second step in 'Download and Install' to be complicated. There are SSL certs for www.mozilla.org (and this site) already in place. I filed a similar bug against Chrome/Chromium and they fixed it. (https://code.google.com/p/chromium/issues/detail?id=53116) They have changed things so that by default at least, users download Chrome over https. I imagine that doing so for Firefox would require a large infrastructure change, compared to the way Firefox is delivered today (over donated, geographically dispersed bandwidth), but that is the bug/issue I'm suggesting under this bug ID. Note: The Mozilla Manifesto's Principle 4 reads: "Individuals' security on the Internet is fundamental and cannot be treated as optional." This is an offshoot of related Bug 687164 - Make the SHA1SUMS file available over HTTPS.
This doesn't need to be a security bug. CC'ing some folks, but I don't think this is a high priority item.
Do we really have to wait 'till there's news of exploitation of this before making it other than P5? It's a gaping hole in the security of the products. We (appropriately, IMO) make a big deal about promptly revoking a compromised cert, but the entire database of certs is still delivered insecurely. Seems inconsistent to me.
Matthew, please be friendly. I CC'ed our release manager, someone from the security team, and someone from the IT team. I trust that the three of them together will properly prioritize this. Marking this P5 is my team's way of saying "this bug has been looked at by us", no need to take it as anything more than that.
Signed windows installers served insecurely appears to be state-of-the-art. I personally hand out the secure https://ftp.mozilla.org link to people but our IT department says we can't afford to route everyone that way. Once the initial client is installed the content of future updates are downloaded securely. We're also working on a network installer https://wiki.mozilla.org/Features/Firefox/Network_Installer Although I don't see it mentioned explicitly on that page, one of the goals is for the small stub to be served over TLS, and then it will know how to check the validity of the bulk download in much the same way as our updates.
(In reply to Daniel Veditz from comment #4) > Signed windows installers served insecurely appears to be state-of-the-art. > I personally hand out the secure https://ftp.mozilla.org link to people but > our IT department says we can't afford to route everyone that way. This part makes this an IT bug IMHO.
Assignee: nobody → server-ops
Component: Release Engineering → Server Operations
QA Contact: release → cshields
Downloads are almost always served from our mirror network, not by us directly, so I'm not sure how this would work out in practice. We could certainly require that only HTTPS mirrors would be allowed in the main rotation, but some of the mirror admins might consider that an undue burden and opt to stop public mirroring altogether. It might cost us some goodwill, and increase the bandwidth burden on other mirrors. There's no feasible (technical) way we could force mirrors to not serve content over HTTP or FTP... at best we could refuse to list the unsecured options in the main bouncer config. The presence of mirrors seems somewhat problematic in the first place, as it automatically requires an extra level of trust- not only do you have to trust Mozilla, you also have to trust the mirror you're using. Yet many other Open Source projects are done this way. I suppose we could eschew all our mirrors and just run our own (CDN maybe), but that doesn't seem all that good either. Google does not have this problem with Chrome because Chrome downloads come from dl.google.com... not a mirror network. They control the download location, and thus can control how it's served. We do not have that level of control under the current design. Because of all this, I believe this is more of a policy decision than a technical one. mrz, care to comment? Related note: I believe we serve automatic updates ourselves, and not through the mirror network... and I believe those are done over SSL. But I'm not 100% on either of these points. Someone on the main Firefox team might be better able to answer that.
(In reply to Jake Maul [:jakem] from comment #6) > Related note: I believe we serve automatic updates ourselves, and not > through the mirror network... and I believe those are done over SSL. But I'm > not 100% on either of these points. Someone on the main Firefox team might > be better able to answer that. Updates are delivered over http via the mirror network. However, Firefox receives information about the update directly from us over SSL, including the file size and checksum of the update. So, those are a non-issue per dveditz's comment #4.
I didn't mean to convey an unfriendly tone. Sorry if I did and thanks for informing me of the overloading of the Importance/Priority field. Sounds like we're all roughly in agreement. Glad to see the responses. I feel what's important is that the situation change so the bulk of new installs are done securely. (And yes, I am on a mission - http://snurl.com/wv8xp - to improve security, and am having some success.) I do think that it is truly important, and that the way we've been doing distribution has gradually become unacceptable.) As long as the bulk actually become pretty secure, it doesn't much matter how. However, if the download is signed, but the signature verification is difficult enough that it rarely happens, then this goal isn't met. I don't think we make usable user guidance on how to do a GnuPG signature verification of our products readily available. As noted in the related bug I mentioned, I anticipated a switch to TLS would be quite a difficult fix, but I opened this bug anyway because TLS provides higher penetration (i.e. more secure installs) than the other solutions I'd considered. A network installer served over TLS could be as good at penetration (ignoring edge cases), and allow us to continue to rely on the extant mirror network. I don't know if any of you can see the Chrome bug (they feel it hasn't been fully addressed; it's still not public) but there's a discussion of important unresolved problems with current signed Chrome installers that's relevant. I just noticed that the network installer wiki page lists "Use https for all network requests" as a requirement, which implies that we will be serving a LOT of data over https if the network installer is completed and becomes popular. It lists Linux support and Replacement of existing installers as non-goals. It doesn't help much that the updates to any machine already compromised by the initial installer are secured; that would be closing the gate after the horse has bolted.
Most of these concerns are going to be resolved with the new installer, which will be downloaded securely and then itself ensure the integrity of the binaries. So I am going to WONTFIX this request as it is. Please feel free to follow and comment on those bugs. The parent tracking bug for the project is 675970 cheers!
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
I just noticed that "Linux support" is explicitly listed as a non-goal for the new installer. (See https://wiki.mozilla.org/index.php?title=Features/Firefox/Network_Installer&diff=353618&oldid=349346 which also shows an edit I did per 'Be Bold'; I hope it was a good idea.) My MAIN POINT: We don't have and need to come up with a game plan for addressing this issue on Linux. I also just noticed that Bug 358384 - "Force https for www.mozilla.org and Firefox downloads" is a near duplicate of this one; perhaps it should be marked as such. Do you agree that a better title for this (my) bug would be "By default, users should be downloading our products securely (e.g. over https, or with a trusted signature, to ensure integrity and authenticity)?" Perhaps it should be changed to platform Linux? I'll leave it to others (e.g. Corey) to make any title, status or dupe changes thought appropriate. (Some thoughts: All of the major package managers for Linux try to be secure but all have (as of '09 anyway) vulnerabilities (per https://www.cs.arizona.edu/people/jsamuel/papers/samuel-cappos-login-feb09.pdf ; see snurl link above). I wonder what the prevalence of secure downloading is for our products on Linux. I suppose we could redirect Linux users to their package managers or the self update feature.)
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.