I understand that there are probably legacy reasons why archive.mozilla.org and download-installer.cdn.mozilla.net, etc. don't redirect to HTTPS, but if a client is able to successfully connect via HTTPS, we should pin them to it with HSTS. As such, could we add HSTS to: archive.mozilla.org download-installer.cdn.mozilla.net download.cdn.mozilla.net download.mozilla.org > Strict-Transport-Security: max-age=31536000 Thanks so much!

Nick and Julian, r?

Nick: Is there any occurrence of serving installers of updates through HTTP (no S) that we must preserve? I'm thinking of a situation where client would fail to update over HTTPS (broken pin, etc...) and would fall back to HTTP instead, but I don't know if that's a thing.

needinfo :rstrong who may have context too.

The only context I have is in regards to the stub installer on XP SP2 not supporting SHA2 etc. and to please thoroughly test this before rolling out.

SHA-2/XP is unrelated to HSTS; there is nothing in HSTS that specifies that you must use SHA-2 certs. Also, only modern browsers understand the HSTS header at all, meaning that XP SP2 systems ignore it entirely. We recently did a roll out on bedrock with much success and no obvious problems with XP clients.

I can't think of any use cases which require HTTP only - IIRC using HTTPS on a CDN was significantly more expensive, so other mitigations were used. That may no longer be true. Besides product delivery, there are many use cases of archive.mozilla.org which may or may not break, it's kinda impossible to enumerate the the world's scrapers, scripts, etc. Socorro is a major internal consumer but moving away from archive.m.o in the near term. Did you leave out (the discouraged but still available) ftp.mozilla.org for some reason ? It's equivalent to archive.m.o. Here's a summary of the current state of things for Firefox, with a couple of queries inline: Release updates (via https://aus5.mozilla.org update request, beta should be similar, so are complete updates) - http://download.mozilla.org/?product=firefox-49.0.1-partial-48.0.2 - http://download.cdn.mozilla.net/pub/firefox/releases/49.0.1/update/win32/en-US/firefox-48.0.2-49.0.1.partial.mar * https not previously required because of mar signing and hash checking against https declared update info * HSTS would swing a lot of traffic to HTTPS, are the CDN contracts up to that ? Release installer (via www.mozilla.org, beta should be similar) - https://download.mozilla.org/?product=firefox-49.0.1-SSL&os=win&lang=en-US - https://download-installer.cdn.mozilla.net/pub/firefox/releases/49.0.1/win32/en-US/Firefox%20Setup%2049.0.1.exe Release stub installer (via www.mozilla.org, beta should be similar) - https://download.mozilla.org/?product=firefox-stub&os=win&lang=en-US - https://download-installer.cdn.mozilla.net/pub/firefox/releases/49.0.1/win32/en-US/Firefox%20Setup%20Stub%2049.0.1.exe - http://download.mozilla.org/?os=win&lang=en-US&product=firefox-latest - http://download.cdn.mozilla.net/pub/firefox/releases/49.0.1/win32/en-US/Firefox%20Setup%2049.0.1.exe * https not previously required because of verification of code-signing of full installer * does the NSIS-based stub respect HSTS ? Nightly/Aurora updates ((via https://aus5.mozilla.org update request), eg - https://mozilla-nightly-updates.s3.amazonaws.com/mozilla-central/20161003030438/Firefox-mozilla-central-52.0a1-win32-eo-20160930030315-20161003030438.partial.mar?versionId=q0frYeZ3F5PtjdLwjnHEbJ7YMGaO5ilz Aurora installer (via https://www.mozilla.org/en-US/firefox/channel/#developer) - https://download.mozilla.org/?product=firefox-aurora-latest-ssl&os=osx&lang=en-US - https://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-aurora/firefox-51.0a2.en-US.win32.installer.exe Nightly installer (via nightly.mozilla.org) - https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-52.0a1.en-US.win32.installer.exe Nightly stub (via nightly.mozilla.org) - https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-52.0a1.en-US.win32.installer-stub.exe

(In reply to Julien Vehent [:ulfr] from comment #2) > Nick: Is there any occurrence of serving installers of updates through HTTP > (no S) that we must preserve? I'm thinking of a situation where client would > fail to update over HTTPS (broken pin, etc...) and would fall back to HTTP > instead, but I don't know if that's a thing. Like updating a really old Firefox, which might not like the CA chain of the current SSL cert ? It's possible I guess, but isn't that the same problem as serving a new installer to such users ? We're already using HTTPS for that.

I think we should hold off on HSTS for product delivery sites until the following items are cleared: 1. Decide to move all CDN traffic to HTTPS. This has cost implications which, at the scale of our product delivery pipeline, are very significant. 2. Once we move to HTTPS by default, evaluate which properties are blocked on an HTTP-only path and decided what to do with those. Only then, enable HSTS. I can't see this happening in the near future. This is, at best, a 2017 goal. We'll get there, but it will take time.

Do we have statistics on what percentage of traffic on our product delivery sites is done via plain http?

Also note that this is only for enabling HSTS, not forcing a redirect from HTTP to HTTPS. It's ensuring that somebody who has retrieved something from our product delivery sites using a browser that supports HSTS continues to use HTTPS in the future.

> Do we have statistics on what percentage of traffic on our product delivery sites is done via plain http? All MAR downloads currently use HTTP, not HTTPS. This represents the majority of traffic. > Also note that this is only for enabling HSTS, not forcing a redirect from HTTP to HTTPS. It's ensuring that somebody who has retrieved something from our product delivery sites using a browser that supports HSTS continues to use HTTPS in the future. As Nick mentioned in comment 6: > * HSTS would swing a lot of traffic to HTTPS, are the CDN contracts up to that ? A given browser may download a small file from the CDN and get HSTS set, which would switch all subsequent update traffic from HTTP to HTTPS forever. This change requires a lot more analysis before we enable it. I think we'll start evaluating cost in 2017.

Sounds good. Shall I leave the bug open for tracking, or would you like to mark it WONTFIX for now?

:ulfr, question for you. Given that we control the MAR downloads, would it hypothetically be possible to: a) preload .mozilla.org, and b) have the product ignore it and use HTTP for the purposes of product delivery Slowly working our way towards HSTS preloading for .mozilla.org in bug 1306346, and this might be one of the more difficult problems to solve. Thanks!

Also I totally meant bug 1351363 above, not bug 1306346.

I'm pretty sure Firefox will honor the preload if it exists. We don't have a way to ignore it, short of writing a different network stack. We need to let the ops team figure out pricing before making changes.

How viable would it be to host the .mar files on another domain? (ie keep the ping URL the same so older clients can still check for updates, but have the ping return a different-domain URL to the mar file itself)

Do you mean something like * create new CDN distribution like http://download-updates.cdn.mozilla.net * don't set HSTS headers on that, teach update system to use it * set HSTS on the domains in comment #0, and possibly ftp.m.o

Yes, except it would need to be an entirely different apex/root domain (eg mozilla-updates.net) since HSTS preload has to apply to the whole domain including subdomains.

Adjusting bug dependency, since this only affects the ability to preload mozilla.org specifically (though perhaps not even that - comment 17) and the other bug is a tracking bug.

Moving files to a different domain doesn't address the fact that we want to serve files through HTTPS, not HTTP. We still need to price that change in traffic with our CDN vendors to move over to HTTPS. Once we do, we can HSTS the whole thing without moving domains.

I agree longer term it may be desirable to serve these files over HTTPS (even though signatures verified already etc), however there's no need to let this bug hold up enabling preloading for *.mozilla.org - and in fact the mars are already served from another domain (mozilla.net), so needn't block.

Please assign back to me if a decision is made on what to do here.

Matt, with your recent changes to how updates are downloaded, could you comment on how enabling HSTS on product delivery sites would impact update downloads?

The change I made (bug 1348087) boils down to making the app update download path almost the same as how regular file downloads work, at least as far as the network is concerned; in other words, we're doing fewer weird and special things. I don't expect there to be any issues with HSTS that are unique to the app update scenario from that perspective. The one worry I do have is just that adding HTTPS gives us an additional way that the update process can fail, through no fault of the user, and by using HSTS we're taking away the possibility of a fallback to plain HTTP if the TLS connection does fail (especially if we apply this to both updates and installer downloads). I would expect us to orphan some users.

There are also the issues with cert pinning in bug 1419189

bug 1419189 isn't related to cert pinning.

Sorry, I meant bug 1063111