1410458 - Firefox download link redirects to insecure http://

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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?

Comment 3

[Jeremy Orem [:oremj]]

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

Comment 4

[Rail Aliiev [:rail]]

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.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

(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?

Comment 6

[Rail Aliiev [:rail]]

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

Comment 7

[Molly Howell (she/her) (no longer active)]

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.

Comment 9

[Daniel Veditz [:dveditz]]

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.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

(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".

Comment 11

[Rail Aliiev [:rail]]

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.

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

FWIW, people on twitter continue to wonder why we have insecure download links:

https://twitter.com/ericlaw/status/930438201658966017

Comment 13

[Chris AtLee [:catlee]]

This should be fixed now that bug 1422844 is done.

Please re-open if this is not the case!