http://www.mozilla.com/ should redirect to https://www.mozilla.com/, and the default method of downloading Firefox should use https rather than http. The integrity of the software I download is more important than who can see my bank password, if only because anyone who can screw with the software I download can also see my bank password. Doing this might help us convince banks that *we* actually care about security, and so they should listen to us when we tell them they should use https correctly. See also bug 358360, related bug for addons.mozilla.org.

Windows XP does have some UI for determining whether an installer is signed and who signed it, but using that alone has a lot of disadvantages: * Users have to look for it. * Users have to know how to tell, based on information in the Windows UI, whether the executable is signed by the right people (Mozilla Corporation?). * It doesn't prevent an attacker from giving you an old, vulnerable version of Firefox (and pretty much preventing you from knowing there's a newer version). * There isn't a Mac equivalent, afaik.

I'm inclined to just WONTFIX this. We've never done that before, and www.mozilla.com doesn't actually send the files out to people. It just redirects you to Bouncer (HTTP). I even checked Microsoft's site, and they do not use any type of HTTPS on downloading. We already have enough trouble as it is with www.mozilla.com redirects and such, and this would just be one more headache that's not really needed, as www.mozilla.com does not send any files at all. Also, I can tell you right now you're not going to get 150 mirrors to make sure they have HTTPS. We already demand a lot from these mirrors. The gains just don't seem to outweigh the costs. I'll defer to IT on mirror-related issues.

All that would be needed would be a redirect for download.html (for sure don't want to ssl all of mozilla.com). Mirrors would not need to do ssl - sentry (will at some point soon) do md5 checks to verify the files mirrors are sending are valid. My concern would be more around breaking client downloads or somehow interfering with someone getting the product - which we don't want to do. Perhaps QA could test using https (which works now)?

> Mirrors would not need to do ssl - sentry > (will at some point soon) do md5 checks to verify the files mirrors are sending > are valid. Mirrors would need to use SSL for this to improve the integrity of downloads for users. So this would be a lot of work, but I think it would be worth it.

(In reply to comment #3) > All that would be needed would be a redirect for download.html (for sure don't > want to ssl all of mozilla.com). Mirrors would not need to do ssl - sentry > (will at some point soon) do md5 checks to verify the files mirrors are sending > are valid. If just the download web page is HTTPS and not the actual mirrors, this would become just like bug 358360 basically (having the web site be secured but the downloads not [for add-ons]).

> I even checked Microsoft's site, and they do > not use any type of HTTPS on downloading. Sure, but we can be better than Microsoft on this. We should avoid falling into the trap of "Microsoft picked X over security here, so we can probably get away with doing the same", because that won't help us keep users safe or stay ahead of competition.

One alternative would be to add a link-hash-checking feature to Firefox. For example, if a link has a "sha256" attribute and a "type" attribute, Firefox could make sure both match (and for HTML, don't start parsing or displaying it until it is fully downloaded and has been checked). There could be a status bar indicator that a link has such a hash, so users looking at the status bar can tell that the download is safe despite the http URL. Bug 292481 covers this. Browsers known to not support the link-hash-checking feature could be directed to a smaller set of https-supporting mirrors, or they could be given the less-safe http download. This approach has the advantage of putting less burden on the download servers, so it would be easier for us and would probably also be easier for other software providers. But it would require adding a feature to Firefox and then waiting until users have the new version.

(In reply to comment #1) > * Users have to look for it. > * Users have to know how to tell, based on information in the Windows UI, > whether the executable is signed by the right people (Mozilla Corporation?). > * It doesn't prevent an attacker from giving you an old, vulnerable version of > Firefox (and pretty much preventing you from knowing there's a newer version). You could say exactly the same about making the site force SSL. * Users have to look for it. * Users have to know how to tell, based on information in the UI, whether the SSL certificate is signed by the appropriate authority. * It doesn't prevent an attacker from poisoning DNS and feeding you a non-SSL URL if the user doesn't know the site is supposed to be SSL to begin with. That and SSL certificates are expensive. A lot of our mirrors don't have those kind of resources and barely pay for their bandwidth. (Not to mention the amount of CPU drain on each of the servers to encrypt/decrypt the SSL would negate a lot of the gain we get by having so many mirrors -- we'd need that many more to make up the difference)

And to go with that, if you do know what SSL means and you want to validate that your personal copy came from us, you can always download it from https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0/ (the http version redirects to releases.m.o if you go into a releases directory -- the https version doesn't, yet, mostly for that reason, although that may change at some point if enough people use it that it causes load problems)

> > * Users have to look for it. > > * Users have to know how to tell, based on information in the Windows UI, > > whether the executable is signed by the right people (Mozilla Corporation?). > > * It doesn't prevent an attacker from giving you an old, vulnerable version of > > Firefox (and pretty much preventing you from knowing there's a newer version). > > You could say exactly the same about making the site force SSL. For the first two points, you're right. But I think users are more likely to check for that kind of thing before downloading than after downloading. For the third point, SSL helps much more than exe signing, because an attacker can't make https://www.mozilla.com/ tell you that the current version is Firefox 1.0.4 and link to the Firefox 1.0.4 download.

If I understand http://en.wikipedia.org/wiki/Merkle-Damgard_hash_function correctly, it should be possible to compute the SHA-256 of a file incrementally while downloading it. So there need not be a separate "verification" step that makes these downloads significantly slower :)

Oops, that comment was meant for bug 292481.

(In reply to comment #10) > > > * It doesn't prevent an attacker from giving you an old, vulnerable > > > version of Firefox (and pretty much preventing you from knowing there's > > > a newer version). > > > > You could say exactly the same about making the site force SSL. > > For the third point, SSL helps much more than exe signing, because an attacker > can't make https://www.mozilla.com/ tell you that the current version is > Firefox 1.0.4 and link to the Firefox 1.0.4 download. But only if the user was expecting it to be https. If they aren't, then it doesn't matter. The attacker could just feed them an http version that doesn't redirect to https.

That falls under the first point. https and the accompanying authentication information are easier for users to check than exe signing, and it has the additional benefit of preventing users from getting out-of-date versions due to a MITM attack.

How about we use https://download.mozilla.org instead of http://download.mozilla.org for download links? We could possibly also make the download page on www.mozilla.com redirect to an SSLized version, but I think pointing to bouncer via https benefits the user more. What do you think?

How about serving torrents (bug 222261) over SSL?

Given the success of Firesheep and Evilgrade demos, I'm surprised we haven't seen a wifi worm yet. We can fix this now while it's only a PR problem, or we can fix it later in a worm-triggered firedrill. A firedrill that involves temporarily losing 95% of our mirrors would be extremely unpleasant.

SSL isn't expensive any more: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Going to "summary up" some of the internal comments related to this bug. Since we use mirrors, forcing https isn't going to be easy or cost effective. I agree that this adds some protection but we should also look at the likely hood of an attack in this area vs the cost. I would be more worried about a mirror being compromised which https doesn't solve. A stub installer on the other hand would fix this issue. The stub installer can delivered via https via our infrastructure. This would provide adequate protection if a mirror was comprised and the binaries where replaced.

How do we generate enough momentum to move forward with a stub installer? It's been talked about like forever but I've never seen any traction.

I tend to think a stub installer is a bad idea in terms of UX. "I download X and now I need to download Y.". But you should get someone with more understanding in those things to consider this. If the stub install is going to be downloaded over the mirrors, I don't see how it is any safer.. it could be compromised. Chris: > Since we use mirrors, forcing https isn't going to be easy or cost effective. Where is the data to back that up?

We _had_ a stub installer back in the Mozilla Suite days. People didn't seem to like it. > If the stub install is going to be downloaded over the mirrors, I don't > see how it is any safer.. it could be compromised. Presumably you'd download the small stub itself over HTTPS, and embedded in it are the hashes for the parts it's going to download from the mirrors.

Is it practical to make all of mozilla.com HTTPS-only and use HSTS, ignoring downloads? If so, then I think we can and should implement a signature-verification-indication-on-links-based (link fingerprinting) approach instead of implementing a stub installer. Note that getting all the mirrors to use HTTPS doesn't protect us against bad mirrors.

(In reply to comment #24) > Is it practical to make all of mozilla.com HTTPS-only and use HSTS, ignoring > downloads? If so, then I think we can and should implement a > signature-verification-indication-on-links-based (link fingerprinting) approach > instead of implementing a stub installer. I know that there's a community out there who would love to see us implement metalink, which has an http header that contains a hash that is currently in the RFC editors queue: http://datatracker.ietf.org/doc/draft-bryan-metalinkhttp/

(In reply to comment #24) > Is it practical to make all of mozilla.com HTTPS-only and use HSTS, ignoring > downloads? If so, then I think we can and should implement a > signature-verification-indication-on-links-based (link fingerprinting) approach > instead of implementing a stub installer. > I don't think it's practical - also removes CDN and any page load performance we gain from there.

(In reply to comment #26) > I don't think it's practical - also removes CDN and any page load performance > we gain from there. Closing this (as mrz says).

This wasn't fixed and I would like to talk to mzr about this before we WONTFIX this.

What would you like to talk about?

Note that even if it's not technically feasible to make all downloads HTTPS, making the HTTPS download a bit easier to find wouldn't hurt. Googling for the obvious terms fails and it's not obvious from our site either. Like putting a "Secure Download" next to "Other Systems and Languages" here: https://www.mozilla.org/en-US/products/download.html

Beyond the actual security gains here, there are also perceived gains. I just had a good scare when trying to install Firefox on a new computer. STR: - pull up Internet Explorer - go to getfirefox.com - start downloading the latest version. - note that the save dialog box says you're getting something from mozilla.3c.stonekitty.com! Wait, from where?! What? - note that you're on an http connection! It's pretty hard at this point to know whether Mozilla is using a mirror system or whether you're having a MITM attack. And that sucks. A lot. It gets worse when you Google stonekitty.com, and get a superuser post saying that it might have served somebody malware.[1] A second anecdote informs why I care about this bug, and why I'm pretty surprised Mozilla isn't already using HTTPS for this. I work in the professional services department of a search company. A few months ago, I accidentally installed malware on a customer's Windows server. What happened was that I tried to install Chrome by: 1. searching for Chrome on Bing (it was the default search engine in IE). 2. clicking on the first sponsored link in the results 3. downloading Chrome from that site, and attempting to install it Unfortunately, the sponsored link on Bing was to a malware site that was a mirror of Chrome's download webpage. There's more security expertise on this bug than I have, but HTTPS is definitely needed when downloading software as important as a browser. I agree with others that question how we can trust our bank's website if we got our browser from an insecure location? I recognize that there are financial issues with making things secure, but that's going to be a lousy rationale after the download binaries or mirrors are hacked. Strongly suggest fixing this, unless I'm missing something. [1] http://superuser.com/questions/223826/firefox-wants-to-connect-to-crowdcache1-stonekitty-net-on-tcp-port-9911-sype-tra/223868#223868

The idea that SSL is too costly does not factor the cost or complexity of harmed users. Additionally the computational complexity is known to be untrue even for large sites when properly configured. If HTTPS is not possible because load balancing with mirror sites is important I'd ask Mozilla to consider changing the way that mirror sites are used. A securely available stub installer that verifies signatures is probably the only reasonable alternative to HTTPS secured downloads. Even with HTTPS, I'd still advocate the use of a stub installer fetched from a single location that is heavily controlled, monitored and audited. Something based on TUF ( https://www.updateframework.com/ ) is almost certainly the correct path for the stub/updater. Mirror sites run by possibly hostile parties are a real problem in that maliciousness by mirror admins is only one part of the problem. If it's not a server admin, it may be a MITM on a hostile network. The browser is the root of all trust on the web. I hope Mozilla takes every step to protect this root during the most vulnerable times - the first download and subsequent update downloads.

Stub installer is being worked on (bug 675970). Discussions related to that should be in that bug. This bug is about initial full download & browsing on www.mozilla.org. 1. We can have a discussion on how to handle initial full downloads (outside of a stub installer) and I could certainly advocate doing that over SSL. This does exclude a large swath, if not all, of the mirror network and increases (substantially) the cost of using a CDN for initial downloads over SSL. 2. Browsing www.mozilla.org. Forcing SSL for that exacts a performance penalty or cost penalty. Currently static content off that site (images, css, js) are offloaded to two CDNs. Switching to all SSL would mean either self-hosting that content and taking the performance penalty or paying the increased CDN delivery rates for SSL. And because we care, it also limits the number of CDN players. Not many have been able to pass our SSL qualification tests (see addons.mozilla.org for one who has). I'd offer it's a tradeoff on what we're trying to achieve. I'd prefer to focus efforts on the initial product download first and then consider the whole site. Thoughts?

I've commented on #675970 as suggested. re: 1) I think it's reasonable to offer an *option* of files over SSL/TLS that is not served over a mirror - I'd love to see if it gets any use at all. It would at least make it significantly more difficult to attack people who are aware that they need to secure themselves. This would also likely be useful for software distributors that base their software on pre-build Mozilla software. re: 2) It seems possible that Mozilla.org fully supporting SSL would prevent link spiking, content injection and other stuff that SSL/TLS was designed to prevent. Adam Langlely has a good writeup on the costs: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html For those that don't want to click the link, I'll extract the important bits: "In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." A fantastically relevant quote from Adam is this part: "If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more." The rest of the blog post explains important facts about SSL/TLS performance and future improvements to SSL/TLS. It's a great read and I highly encourage everyone to read it. I think that securing javascript content is pretty important and I'd be surprised if your CDN would rather lose you as a customer than fix their systems. However, a good start is the download site, even if you can't actually ensure that everyone gets to it as expected.

> I think that securing javascript content is pretty important and I'd be > surprised if your CDN would rather lose you as a customer than fix their > systems. However, a good start is the download site, even if you can't > actually ensure that everyone gets to it as expected. Part of the challenge is getting them to recognize they aren't as compliant as we want. Second is getting them to update their large infra to support just me (I guess no one else is pushing). EdgeCast rolled their ADN platform with better SSL support and passed the test at https://www.ssllabs.com/ssldb/index.html . That' what we're using for AMO right now (and we're looking at a couple other providers).

(In reply to Jacob Appelbaum from comment #34) > re: 1) I think it's reasonable to offer an *option* of files over SSL/TLS > that is not served over a mirror - I'd love to see if it gets any use at > all. I disagree. This is a real security issue, and it needs to be treated as one. The first time people download their browser, it needs to be provided by SSL only. Giving users the option teaches the lesson that SSL is good, but it's not always necessary, which seems worse than not having it at all. This is very clearly a time when it's necessary. Mozilla should lead on this, especially if the cost is as minimal as Jacob says above. I'd love to see some figures here, but ultimately I can't help but think that the numbers aren't relevant vs. the security issue at hand. I'll also note that Chrome is downloaded via HTTPS, and that even sites like github and bitbucket are now providing secure code downloads.

(In reply to matthew zeier [:mrz] from comment #33) > I'd offer it's a tradeoff on what we're trying to achieve. I'd prefer to > focus efforts on the initial product download first and then consider the > whole site. > > Thoughts? Protecting the pages that link to the download is as important than hosting the downloads themselves over HTTPS would be. Otherwise, sslstrip attacks would make the HTTPS download for the installer trivial to undo. Also, for past releases, we have had multiple marketing pages that had "download" links (that I think linked to the main download page). All of these pages would have to be HTTPS-only in order to get the full security benefit (i.e. to prevent sslstrip attacks).

> Protecting the pages that link to the download is as important than hosting > the downloads themselves over HTTPS would be. Otherwise, sslstrip attacks > would make the HTTPS download for the installer trivial to undo. I think that aligns with the spirit of what I was saying, "focus efforts on the initial product download". So whatever ends up punting me to http://www.mozilla.org/en-US/firefox/fx/?from=getfirefox should punt me to the SSL version only (& always). > Also, for past releases, we have had multiple marketing pages that had > "download" links (that I think linked to the main download page). All of > these pages would have to be HTTPS-only in order to get the full security > benefit (i.e. to prevent sslstrip attacks). In the past yes. Unless I"m remembering incorrectly, there's an effort to consolidate all downloads to the same page from all properties.

(In reply to matthew zeier [:mrz] from comment #38) > I think that aligns with the spirit of what I was saying, "focus efforts on > the initial product download". So whatever ends up punting me to > http://www.mozilla.org/en-US/firefox/fx/?from=getfirefox should punt me to > the SSL version only (& always). OK. I think that is an awesome idea. > > Also, for past releases, we have had multiple marketing pages that had > > "download" links (that I think linked to the main download page). All of > > these pages would have to be HTTPS-only in order to get the full security > > benefit (i.e. to prevent sslstrip attacks). > > In the past yes. Unless I"m remembering incorrectly, there's an effort to > consolidate all downloads to the same page from all properties. Just to be clear, I mean that all the marketing pages should (eventually) also be HTTPS if they link to the download page, to prevent sslstrip attacks. Otherwise, an attacker can just rewrite the links on those pages to point to his own download page.

Okay, next. Who makes this happen?

(In reply to matthew zeier [:mrz] from comment #40) > Okay, next. Who makes this happen? I think this would be Fred & James, assigning to Fred, let us know!

A special case of this bug is the experience that HTTPS Everywhere (https://eff.org/https-everywhere) users have today. Those users see everything on mozilla.com and mozilla.org as secure, except that if they click a download link, they will (invisibly) be sent a binary over unsafe HTTP. Depending on the timeline for resolving this bug completely, a good intermediate step would be to detect users who are clicking the "download Firefox" button from the HTTPS version of a page, and send them to the subset of mirrors that supports HTTPS today.

(In reply to Peter Eckersley from comment #42) > a good > intermediate step would be to detect users who are clicking the "download > Firefox" button from the HTTPS version of a page, and send them to the > subset of mirrors that supports HTTPS today. *that* might actually not be very hard to pull off. It probably ought to be filed as a separate bug though (product=Webtools, component=Bouncer). We'd need to add a flag to the mirror table to indicate if a mirror supports https or not, and then just add that to the selection criteria when serving a response over https.

Somebody please correct me if I'm misunderstanding something, but doesn't this bug undermine ALL security within Firefox? My understanding is that users have no way of knowing whether they are getting a genuine version of the browser, and as such it's possible that you could be using a compromised version for years. When I downloaded Firefox the other day, I downloaded it from http://mozilla.3c.stonekitty.com. That's absurd, right? Who is stonekitty? Should I trust them? To the average user, their homepage doesn't inspire confidence, with it's hacker-style ones and zeros. Mirrors have to go, unless they're major, trustworthy organizations with established security practices. Peter, I love your work, but I really don't think a temporary workaround is worth any effort. We need a proper fix (no mirrors, https only) on a short timeline. Is there an estimate for when this will be fixed or are there at least people working on it actively? Where's the feature page?

Please follow along in bug 675970 for our work on a stub installer that will be served from Mozilla managed SSL hosts.

(In reply to Michael Lissner from comment #44) > Somebody please correct me if I'm misunderstanding something, but doesn't > this bug undermine ALL security within Firefox? No, it doesn't. On Windows we codesign binaries with a purchased certificate. Windows verifies this signature on both the Firefox installer, and the installed binaries. On Linux and Mac, we provide detached GPG signatures that can be verified by hand.

(In reply to Ben Hearsum [:bhearsum] from comment #46) > On Linux and Mac, we provide detached GPG signatures that can be verified by > hand. Really? Where are they? I have actively looked for a detached signature before, but never found it. Whose key is used for the signing? [Feel free to reply by email if this is drifting off-topic for this bug.]

(In reply to Tom Lowenthal [:StrangeCharm] from comment #47) > (In reply to Ben Hearsum [:bhearsum] from comment #46) > > On Linux and Mac, we provide detached GPG signatures that can be verified by > > hand. > > Really? Where are they? I have actively looked for a detached signature > before, but never found it. Whose key is used for the signing? [Feel free to > reply by email if this is drifting off-topic for this bug.] Alongside all of the files. Eg: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/8.0/linux-i686/en-US/ You're right though, this is drifting off-topic, let's take any follow-up to the mozilla.dev.builds newsgroup.

(In reply to Ben Hearsum [:bhearsum] from comment #46) > (In reply to Michael Lissner from comment #44) > > Somebody please correct me if I'm misunderstanding something, but doesn't > > this bug undermine ALL security within Firefox? > > No, it doesn't. On Windows we codesign binaries with a purchased > certificate. Windows verifies this signature on both the Firefox installer, > and the installed binaries. > How does someone know what certificate is supposed to sign the Firefox release? What stops an attacker from getting a CA to sign something that looks like a normal Firefox release? > On Linux and Mac, we provide detached GPG signatures that can be verified by > hand. They're not handed out by default on the download page. If you have to go digging for it but you're not even aware, no one really uses it. In fact, I'd love to see the download stats - how many people download both builds and signatures? We can assume that every download is a checked signature if we like; it probably isn't but lets be optimistic... Are such numbers available?

(In reply to Mike Lissner from comment #44) > Somebody please correct me if I'm misunderstanding something, but doesn't > this bug undermine ALL security within Firefox? Yes. You're exactly correct. I have found in the wild a backdoor that pretends to be Firefox - if it was signed by a CA, I believe any CA, it would probably fool every user that checks. I'd bet almost no users check it though, so I bet you can just not sign it and fool them. Does anyone have data to contrary?

This bug continues to be the most shocking one I'm aware of (and I track a LOT of bugs). We go to such great pains to make Firefox secure. We train so many users about checking for HTTPS when logging into things. But we don't bother with HTTPS on the download page? This really needs to get fixed immediately. It's a HUGE security hole.

Here's the malware that pretends to be Firefox disclosed in the wild: https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=465

Adding this to the mozilla.org backlog. Needs discussion as to priority or whether still valid.

Why would this no longer be valid?

Closing per comment 13.

Reopening per comment 14.

(In reply to Dave Miller [:justdave] from comment #13) > (In reply to comment #10) > > > > * It doesn't prevent an attacker from giving you an old, vulnerable > > > > version of Firefox (and pretty much preventing you from knowing there's > > > > a newer version). > > > > > > You could say exactly the same about making the site force SSL. > > > > For the third point, SSL helps much more than exe signing, because an attacker > > can't make https://www.mozilla.com/ tell you that the current version is > > Firefox 1.0.4 and link to the Firefox 1.0.4 download. > > But only if the user was expecting it to be https. If they aren't, then it > doesn't matter. The attacker could just feed them an http version that > doesn't redirect to https. We have HSTS pinning in Firefox (and Chrome) which means that if we pin mozilla.org to HSTS, we will always rewrite http:// links to mozilla.org to https:// links to mozilla.org automatically in Firefox, and the attack described in comment 13 would be impossible for Firefox and Google Chrome.

(In reply to Brian Smith (:bsmith) from comment #57) > We have HSTS pinning in Firefox (and Chrome) which means that if Emphasis on "if" in that sentence. > described in comment 13 would be impossible for Firefox and Google Chrome. But still possible in IE, which delivers a significant number of downloads, last I checked. Right?

What's your proposed solution for non-HSTS users? Just redirecting to https wouldn't make a significant difference - even if we got rid of http://www.mozilla.org entirely, they could still be MITMed if they entered that URL. If you want a bug tracking HSTS pinning for mozilla.org, that should really be a new bug.

(In reply to :Gavin Sharp (away Jan 16-23) from comment #59) > What's your proposed solution for non-HSTS users? Just redirecting to https > wouldn't make a significant difference - even if we got rid of > http://www.mozilla.org entirely, they could still be MITMed if they entered > that URL. It is not true that it wouldn't make a significant difference. It is true that is possible that the user can get MITM'd on the first visit to http://mozilla.org in a browser that doesn't force HSTS. However, when that MitM doesn't happen, the initial redirect will allow us to convince the browser (if it supports HSTS) to use HTTPS for all future requests to the website. Further, since the redirect puts https://mozilla.org in the address bar and in all links on the website, users that share links to mozilla.org are much more likely to share the HTTPS URLs than HTTP URLs. > If you want a bug tracking HSTS pinning for mozilla.org, that should really > be a new bug. I am happy to do that, but AFAICT that would be part of implementing the fix for this bug. FWIW, some people in the security engineering and networking teams (including me) are very interested in advocating that websites switch to HTTPS and HSTS exclusively (using HTTP only to redirect to HTTPS) and we're hoping that mozilla.org can provide an example for websites across the internet to follow, like google.com, facebook.com, and twitter.com. It hurts our (platform engineering's) credibility when we advocate for HTTPS Everywhere but our own website doesn't do that. This is why platform engineers are so interested in this bug, and why we're very interested in hearing about *why* this can't be done, so we know how to improve Gecko and web standards to support our cause so that it becomes practical for us to fix this bug. So, we (I) would be particularly disappointed about closing this bug WONTFIX, as it seems to mean that webdev is saying that it doesn't support our "HTTPS Everywhere" idea. However, perhaps there is a misunderstanding about what this bug is about between platform engineering and webdev. If so, we should meet up and clarify things.

Mozilla.org's web dev team will priorizite this bug into an upcoming sprint. Thanks everyone for the commentary.

Bug 798611 now contains a link to a spreadsheet that has all of the HTTP resources on Mozilla.org that would need to be switched to HTTPS before this change.

(In reply to Brian Smith (:bsmith) from comment #60) > (In reply to :Gavin Sharp (away Jan 16-23) from comment #59) > > What's your proposed solution for non-HSTS users? Just redirecting to https > > wouldn't make a significant difference - even if we got rid of > > http://www.mozilla.org entirely, they could still be MITMed if they entered > > that URL. > > It is not true that it wouldn't make a significant difference. My comment was specifically about non-HSTS supporting clients. Whether the "users more likely to share https:// URL" improvement is "significant" is rather subjective, and weighs against the costs of implementing this (which from my naive perspective also seem "significant"). I'm all for fixing this if the people in a better position to make that tradeoff disagree. My point was really just to highlight that fixing this does not fully address the concern that Sam seemed to have about IE users potentially being MiTMed.

A hack we used on eff.org a few years back was to embed an https:// image in the HTTP page, and set the HSTS header via that. Our motivation was to give proper security to anyone with a client that was capable of being secured (ie, a client that does HSTS) while still being accessible to poor souls stuck on evil networks that block HTTPS altogether. I don't have a full picture of what this was like for every old version of Windows and IE, and after a while we decided it was easier to just redirect everything to HTTPS. I think that's probably the right way for Mozilla to go, too. If the answer is that it's genuinely expensive, I think we'd be interested to know what the main cost sources are (new load balancers? dev time?).

Now that we are serving up downloads via SSL and all the blocker bugs are resolved, I think we are ready to force SSL on mozilla.org. Can anyone think of reasons why we shouldn't proceed with the http to https redirect?

A discussion is ongoing https://groups.google.com/d/topic/mozilla.dev.planning/VilxIruhhBU

Hey look! All of the blockers are resolved! So, what does everyone think about forcing SSL on mozilla.org now?

Sounds good to me!

(In reply to Chris More [:cmore] from comment #69) > Hey look! All of the blockers are resolved! So, what does everyone think > about forcing SSL on mozilla.org now? Can you please make sure that the Symbol Server and Source server work over HTTPS, or at least that they don't get broken by this change. These are very important for debugging crashes in release builds: https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_symbol_server

This is about www.mozilla.org so we should be fine on that front. symbols.mozilla.org is a separate system.

After 7 years, 8 months ago, I am flipping this bug to resolved fixed! woo hoo!