STR: bkelly@valen:~$ curl -i https://download.mozilla.org/\?product\=firefox-latest HTTP/1.1 302 Found Cache-Control: max-age=60 Content-Type: text/html; charset=utf-8 Date: Fri, 20 Oct 2017 15:33:20 GMT Location: http://download.cdn.mozilla.net/pub/firefox/releases/56.0.1/win32/en-US/Firefox%20Setup%2056.0.1.exe Content-Length: 123 Connection: keep-alive <a href="http://download.cdn.mozilla.net/pub/firefox/releases/56.0.1/win32/en-US/Firefox%20Setup%2056.0.1.exe">Found</a>. Reported here: https://twitter.com/m_gol/status/921394040351969280

BTW, the user got this link from the README we publish here: https://ftp.mozilla.org/pub/firefox/releases/latest/README.txt I guess its an old entry point, etc.

This works correctly: bkelly@valen:~$ curl -i https://download.mozilla.org/\?product=firefox-latest-SSL HTTP/1.1 302 Found Cache-Control: max-age=60 Content-Type: text/html; charset=utf-8 Date: Fri, 20 Oct 2017 15:55:07 GMT Location: https://download-installer.cdn.mozilla.net/pub/firefox/releases/56.0.1/win32/en-US/Firefox%20Setup%2056.0.1.exe Content-Length: 134 Connection: keep-alive Seems a bit odd to explicitly require the -SSL to get a safe download. Can we make -SSL and no -SSL work the same?

Rail has addressed this before, is it worth reconsidering at this point?

Heh, this issue pops up every few months. And every time I forget why we keep it this way. :) The main concern that I have is the fact that the stub installer uses that bouncer alias to fetch the full installer: https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/browser/branding/official/branding.nsi#21,22. It would be great to evaluate the risks of switching to https there. Maybe we should talk about this in details with release drivers.

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #4) > The main concern that I have is the fact that the stub installer uses that > bouncer alias to fetch the full installer: Isn't this bad for the integrity of the download?

AFAIK, the stub installer has extra checks and verifies the binary. mhowell may have better information about this.

Yes, the stub installer verifies the code signature of the full installer that it downloads, checking that it is both trusted by the system and matches a pinned issuer and subject name.

If I go to https://www.mozilla.org/firefox/new the green button gives me a download from https:// If I go to https://www.mozilla.org/en-US/firefox/all/ all of the download links are https:// -- and stay https:// when you click on them (links are using -SSL names). Normal people will get a secure download. (In reply to Rail Aliiev [:rail] ⌚️ET from comment #4) > The main concern that I have is the fact that the stub installer uses that > bouncer alias to fetch the full installer: > https://dxr.mozilla.org/mozilla-central/rev/ > 20d57b9c4183973af4af5e078dff2aec0b74f928/browser/branding/official/branding. > nsi#21,22. It would be great to evaluate the risks of switching to https > there. There's no "risk" to switching to https; I assume the reason is cost. We could swap the bounce around so the _default_ is served over https:// and the stub installer adds -itssafetrustus or -mustverify (or more realistically, -nossl) to get the insecurely-served version. Since the official web pathways seem to do the right thing (serve bits securely) the main reason for swapping the default behavior would be to avoid going through these alarms and having to explain it over and over. Given the time suck it is each time this could well be worth it.

(In reply to Daniel Veditz [:dveditz] from comment #9) > Normal people will get a secure download. And yet a user ended up with the one that redirects to http://. At a minimum we should remove all references to that link on our sites. In this case they got it off the ftp site's readme. The ftp readme is on the first page of google search results for "firefox download link".

FTR, switching to https only is really easy, just need to flip the ssl-only from False to True in https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/releases/bouncer_firefox_beta.py https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/releases/bouncer_firefox_release.py https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/releases/bouncer_firefox_devedition.py https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/releases/bouncer_firefox_esr.py Then we can either uplift the changes to the corresponding branches or let them ride the trains.

FWIW, people on twitter continue to wonder why we have insecure download links: https://twitter.com/ericlaw/status/930438201658966017

This should be fixed now that bug 1422844 is done. Please re-open if this is not the case!