1445702 - http://releases.mozilla.org/ must redirect to https://releases.mozilla.org/

Status: RESOLVED DUPLICATE of bug 1431892

(Cloud Services :: Operations: Product Delivery, task, P5)

Comment 1

[Ed Lim [:limed]]

Looks like its redirecting to me:

$ curl -I -L http://release.mozilla.org
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Date: Fri, 16 Mar 2018 17:18:02 GMT
Content-Type: text/html
Content-Length: 183
Connection: keep-alive
Location: https://release.mozilla.org/
X-Cache: Redirect from cloudfront
Via: 1.1 5ecfd97124a5b15f1245ab731d34efe7.cloudfront.net (CloudFront)
X-Amz-Cf-Id: o652S3GOu2S80JHm4ycTscSQ_vgFTocD2K4qOxYWs2XrDywMYLQO5A==

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 26161
Connection: keep-alive
Age: 20
Date: Fri, 16 Mar 2018 17:17:43 GMT
ETag: "ae40bdcebd98c31324060bc6e411b2e4"
Last-Modified: Wed, 21 Feb 2018 23:13:44 GMT
Server: AmazonS3
Strict-Transport-Security: max-age=63072000
x-amz-id-2: 7IoPRPz6Y72z+whuMifruH/W05NQgOIIjdPG5AL6D6LJ4Ykeas7jdugP0mek9bJEqPJM8QDXVnE=
x-amz-request-id: 25418363555DF1BA
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Cache: Hit from cloudfront
Via: 1.1 6f1f8362062a31675dde3c27bc22f2ef.cloudfront.net (CloudFront)
X-Amz-Cf-Id: pF5GX4qoi4utpAthyYxHkM-otCYw4JPbBH3arnQWUydjKdw-X1gLFw==

I tried it in the browser and it redirects as well. So I am unable to reproduce this

Comment 2

[Darkspirit]

https://observatory.mozilla.org/analyze/release.mozilla.org
vs.
https://observatory.mozilla.org/analyze/releases.mozilla.org

Comment 3

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

cloud-services owns releases.mo, so we'll see if we can figure out what's what.

Comment 4

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

Wait, release.mozilla.org is a blog. Why on earth *must* that redirect to releases.mozilla.org?

Comment 5

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

nm. Got side-tracked by #c1.

Comment 6

[Julien Vehent]

:catlee - Can we redirect HTTP to HTTPS for releases.mozilla.org or is it going to break the build multiverse?

Comment 7

[Chris AtLee [:catlee]]

releases.m.o is definitely not used for updates or for initial downloads. AFAICT it's safe to set up a redirect.

Comment 8

[Darkspirit]

Do you have an hour to move forward on this? <3 Thank you.

Comment 9

[Jeremy Orem [:oremj]]

Setting up a redirect on that distribution will also redirect the following domains:

ftp.prod.mozaws.net
archive.mozilla.org
releases.mozilla.org
china-sync.mozilla.org
ftp-ssl.mozilla.org
stage.mozilla.org
stage-rsync.mozilla.org
ftp-cluster.mozilla.org
ftp-test.mozilla.org
ftp.mozilla.org
ftp.eu.mozilla.org
releases.mozilla.com


:catlee, is that okay?

Comment 10

[Chris AtLee [:catlee]]

I think so. Nick, what do you think?

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

tl;dr - very likely no problem for RelEng. Any affect on the CDN origin servers ?

Longer:
We've deprecated some of these domains (no longer resolve in DNS) and the reduced list is:

ftp.prod.mozaws.net
archive.mozilla.org
releases.mozilla.org
ftp-ssl.mozilla.org
ftp.mozilla.org
ftp.eu.mozilla.org
releases.mozilla.com

I've not seen ftp.prod.mozaws.net before so can't really comment on that, or on ftp.eu.mozilla.org. releases.mozilla.com no longer does what it used to, and is now a CNAME for archive.m.o; we may be able to just remove it. ftp-ssl.mozilla.org is probably obsolete too.

From a Release Engineering perspective we mostly use https://archive.m.o and should be OK. Within the release automation, funsize used http://archive.mozilla.org in 61.0b8, but uses https for nightlies. We use aiohttp for downloading and it defaults to following redirects. I can't find any references in the taskcluster graphs for m-c push and nightly for http://, although this doesn't preclude things hardwired in scripts. 

Apart from that it's hard to say with confidence if anything will break, as there are a lot of scrapers and scripts out there. Forcing use of https seems like a net good result.

Comment 12

[Darkspirit]

Even if installer or updater would run into a http to https redirection they are hopefully capable to handle it. Or can we expect bad design decisions, bad contracts, blame and a rollback? ;)

Is this misconfiguration now ready to be fixed?

Comment 13

[Julien Vehent]

> can we expect bad design decisions, bad contracts, blame and a rollback

Please refrain from such language here. We are working through our backlog of issues while being carefully to not break Firefox for our users. It may take some time to get fixed, but it doesn't mean we're not addressing the issue.

Comment 14

[Darkspirit]

Please don't feel offended. I am grateful for what you are working through.
non-abstract wording: "Or can we expect that updater or installer really could break (Unclear to me: could they? If so, is there a Bugzilla entry about it?), that it would cause increased expenses (Which provider doesn't demand the same for http as for https; could Mozilla made pressure to change it?), an uncomfortable situation and a rollback?"

Comment 15

[Darkspirit]

Would it be possible to configure a redirect on "Upgrade-Insecure-Requests: 1" for the meantime? (Assuming the updater doesn't set request headers it can't handle.)
https://blog.kutej.net/2018/06/Nginx-redirect-on-Upgrade-Insecure-Requests-1
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests

Reason: https://www.golem.de/news/mozilla-firefox-63-erweitert-optionen-fuer-trackingschutz-1810-137271.html
linked to http://archive.mozilla.org/pub/firefox/releases/63.0/. It wouldn't have happened with such a solution.

Comment 16

[Darkspirit]

One year has passed since approval.
In the meantime, decision has been made that TLS 1.0 and TLS 1.1 will be disabled in Nightly 72 or 73 in 5-7 months and ride the trains.
Could you try to make this change? Thank you.

Comment 17

[Jeremy Orem [:oremj]]

Julien, any idea who should make the final decision here. It would effectively prevent anyone from downloading Firefox without SSL.

Comment 18

[Darkspirit]

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/mALJa0JM13I/-jxMlOyrBAAJ
https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0012.html

Comment 19

[Julien Vehent]

We still need to wait for bug 1444399 to perform the analysis.