One requirement for the stub installer is that it must be served to the user over SSL. Our existing product delivery system won't work for this because currently bouncer is http-only, and also includes some community mirrors (albeit with extremely small weighting), whose content we don't control and are also http-only. Rob, I'm assigning this bug to you to start off with so we can get some initial requirements figured out. Other than the initial download must be over SSL, are there any other requirements for stub install downloads? How big is the stub installer? Could they be served from an ssl-enabled CDN?

You could add code to bouncer such that this URL bypasses all other bouncer logic and returns a 302 to a SSL CDN URL.

To get the full security benefit, pages with download buttons also need to be SSL. (Otherwise, a MITM attacker can give you a different download, with no UI difference in some browsers.) I assume our front & download pages are the most popular pages on www.mozilla.org, so we might as well make it all SSL-only, and turn on HSTS to win back some performance. Should that be a separate bug?

That would better be asked in bug 794499

Now that we have some requirements and a fairly well fleshed out plan forward, this bug should be about where the actual stub installer files should reside... the hosting of the raw file(s). This might already be decided, but if so I don't know the answer yet so it would be nice to have it stated explicitly. The file(s) will be fronted with an SSL CDN mirror in bouncer, but the CDN still needs to know what the origin would be. Bug 796180 is for the setup of the product in bouncer, and bug 795440 is for setting up the SSL CDN mirror. I propose that the files should live somewhere in here, just like everything else does: https://ftp.mozilla.org/pub/mozilla.org/firefox/ It saves us quite a bit of work if they live in there somewhere...

Don't think there's anything left to do here.