Closed Bug 1304538 Opened 9 years ago Closed 9 years ago

Windows XP SP2 - client side detection javascript

Categories

(www.mozilla.org :: Bedrock, defect)

Product:
www.mozilla.org
Component:
Bedrock
Version:
Production
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: erenaud, Assigned: agibson)

References

(Blocks 1 open bug)

Details

(Whiteboard: [q4 sprint 1])

Attachments

(1 file)

GitHub pull request
44 bytes, text/x-github-pull-request
Details | Review
Original problem statement: Starting January 1st, 2017, Chrome and Firefox will completely refuse connections to sites with SHA-1 certificates. Bedrock itself won't be impacted, due to Cloudflare performing certificate switching for us, but connections to: - download.mozilla.org (bouncer) and - download-installer.cdn.mozilla.net (Cloudfront CDN) will break entirely. Before the year ends, we need to move these two domains to SHA256 certificates, which means Windows XP SP2 clients will not be able to download Firefox installers from these endpoints anymore. Current proposed solution: - Do all detection on client side via javascript to point users to appropriate downloads - Clients with broken JS or JS turned off will get a choice of download platforms (like they do now) that would include something like "Windows XP/Vista". Note: Unable to use the regex from bouncer since we also need to take into account browser. A user on Win XP running a recent Firefox should use the sha2 endpoint for example. Adding IE detection will be necessary. Requirement: Solution must be in place before year end, when Chrome & Firefox will completely refuse connections to sites with SHA-1 certificates
Given this solution, will we also need a sha1 version of bouncer running as well?
(In reply to Jeremy Orem [:oremj] from comment #1) > Given this solution, will we also need a sha1 version of bouncer running as well? Yes. This solution merely directs users on XP/Vista using IE to an alternate domain for bouncer that has a sha1 cert. Then bouncer will need to send those users to an alternate domain for the CDN that has a sha1 cert. The proposal from :ulfr's email was: - download-legacy.mozilla.org - download-installer-legacy.cdn.mozilla.net But they could be anything really, they just have to be something other than the originals from comment #0 so that they can have different certs. Also bouncer will still need its detection for old windows so that it can be sure to send the user to an installer that will work on their system since those systems won't verify our new sha256 signing key. I believe those users are currently still getting Fx 41 installers.
Depends on: 1304763
(In reply to Paul [:pmac] McLanahan from comment #2) ... > systems won't verify our new sha256 signing key. I believe those users are > currently still getting Fx 41 installers. We have sha1-signed installers for the latest version now. See bug 1290737 for more details.
On my side I have: * Added support for a SHA-1 mirror to bouncer: https://github.com/mozilla-services/go-bouncer/pull/52 & https://github.com/mozilla-services/go-bouncer/pull/54 * Deployed https://download-sha1.cdn.mozilla.net/ * Deployed sha1 enabled version of bouncer @ https://download-sha1.allizom.org
Whiteboard: [PBL] → [q4 sprint 1]
Flags: needinfo?(oremj)
Assignee: nobody → agibson
Status: NEW → ASSIGNED
Attached file GitHub pull request —
WIP branch
Testing on demo above I've been able to verify: - IE6 on Windows XP gets sha-1 as expected (browserstack) - IE7 on Windows XP gets sha-1 as expected (local VM) - IE8 on Windows XP gets sha-1 as expected (local VM) - IE8 on Windows 7 gets regular bouncer as expected (browserstack) - IE9 on Windows 7 gets regular bouncer as expected (browserstack) - Firefox 49 on Windows XP gets regular bouncer as expected (browserstack) - Chrome 49 on Windows XP gets sha-1 bouncer, as expected? (browserstack) One thing we're not entirely clear on is what non-IE browsers should get on XP/Vista. We're assuming Firefox can continue to use the regular bouncer since it uses its own trust store. Other browsers (such as Chrome) should get sha-1 since it defers to the OS?
Jeremy, what kind of time frame are we looking at until we can get https://download-sha1.mozilla.org deployed? It would be great to test this against a production endpoint (assuming this is what we'll be using).
Flags: needinfo?(oremj)
When you say "gets sha-1", I'm assuming you mean "gets HTTPS download link with SHA-1 certificate", correct? The reason I ask is because the downloaded installer must always be SHA-1 signed on WinXP, regardless of whether the download link uses SHA-1 or SHA-256. There are really 2 separate things to check for: certificate of the download link and signature of the installer. > Other browsers (such as Chrome) should get sha-1 since it defers to the OS? That is correct: Firefox should get SHA-256 download links. All other browsers should get SHA-1 links. The downloaded installer must be SHA-1 signed in all cases.
(In reply to Alex Gibson [:agibson] from comment #11) > Jeremy, what kind of time frame are we looking at until we can get > https://download-sha1.mozilla.org deployed? It would be great to test this > against a production endpoint (assuming this is what we'll be using). https://download-sha1.allizom.org is the production endpoint for SHA-1. It uses allizom.org because that's the only SHA-1 certificate we have that's usable for this. (SHA-1 certs can no longer be issued).
Flags: needinfo?(oremj)
(In reply to Julien Vehent [:ulfr] from comment #12) > When you say "gets sha-1", I'm assuming you mean "gets HTTPS download link > with SHA-1 certificate", correct? > > The reason I ask is because the downloaded installer must always be SHA-1 > signed on WinXP, regardless of whether the download link uses SHA-1 or > SHA-256. There are really 2 separate things to check for: certificate of the > download link and signature of the installer. When I say gets sha-1, all I mean is the download is initiated from https://download-sha1.allizom.org. I'll defer to :oremj about what the resulting installer is signed with. > > > Other browsers (such as Chrome) should get sha-1 since it defers to the OS? > > That is correct: Firefox should get SHA-256 download links. All other > browsers should get SHA-1 links. > The downloaded installer must be SHA-1 signed in all cases. Thanks for confirming.
(In reply to Julien Vehent [:ulfr] from comment #13) > (In reply to Alex Gibson [:agibson] from comment #11) > > Jeremy, what kind of time frame are we looking at until we can get > > https://download-sha1.mozilla.org deployed? It would be great to test this > > against a production endpoint (assuming this is what we'll be using). > > https://download-sha1.allizom.org is the production endpoint for SHA-1. It > uses allizom.org because that's the only SHA-1 certificate we have that's > usable for this. (SHA-1 certs can no longer be issued). Thanks for confirming, I'll make a note in our download button code for the reason it is this way :)
I would hope there won't be that many people trying to download Nightly on XP, but one open question is what's going to happen to Nightly downloads, which are not part of bouncer: https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
(In reply to Alex Gibson [:agibson] from comment #16) > I would hope there won't be that many people trying to download Nightly on > XP, but one open question is what's going to happen to Nightly downloads, > which are not part of bouncer: > > https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ Ah I see it looks like this is just using sha-256 anyway.
I think our support for this is looking good in :agibson's PR[0]. My remaining worry is that we don't currently have a way (on the mozorg side) to detect problems. We'll need to look for these on the bouncer side. I just wanted to confirm that we'll have logs available for analysis after this runs for a while prior to December 31 that we can analyze for problems with our routing code so that we can adjust before browsers start refusing connections. We should also go ahead and schedule a time to do said analysis to ensure we have enough time to fix problems prior to the end of the year. [0] https://github.com/mozilla/bedrock/pull/4413
Flags: needinfo?(oremj)
Flags: needinfo?(jvehent)
We can have ELB logs (http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/access-log-collection.html) available for bouncer and the stub service.
Flags: needinfo?(oremj)
Flags: needinfo?(jvehent)
Okay. I think we're ready to go live with the changes to mozorg for this then. Are the new domains/certs/bouncer instances ready for production traffic? I just want to be extra sure we're ready before flipping the switch.
No, they aren't ready to accept traffic. The whitelist still needs to be implemented. I may have missed it, but I don't think I have the final copy. We also need QA to test and load test it.
Oops, my head was in stub attribution mode. Yes, the new bouncer and CDN endpoints are basically ready to go, we do need a QA test. Load tests are not required.
(In reply to Jeremy Orem [:oremj] from comment #22) > Oops, my head was in stub attribution mode. Yes, the new bouncer and CDN > endpoints are basically ready to go, we do need a QA test. Load tests are > not required. Jeremy, who is on call to do QA for this change?
Flags: needinfo?(oremj)
I'm not sure if anyone is assigned yet. Stephen, do you know by any chance?
Flags: needinfo?(oremj) → needinfo?(stephen.donner)
Given this is Bouncer-related, I think :mbrandt and I are the best folks to pair up and help test this. I'll sync up with him tomorrow, and ramp up, myself, in the interim.
Flags: needinfo?(stephen.donner)
Sorry to just-now chime in, but Friday's internet/DNS apocalypse, coupled with a Sauce Labs outage (related) kept me from testing in full until late afternoon, PDT :-( With the exception of IE 6 on Windows XP (due to bug 1284925), I've tested with every combination of browser + OS/platform in comment 10, and confirm the same expected results. Additionally, I've tested quite a few JavaScript-disabled cases just to ensure Download Firefox buttons correctly show the "Windows (XP/Vista)" and link to the SHA-1-download Bouncer (https://download-sha1.allizom.org/) + CDN (https://download-sha1.cdn.mozilla.net). I'd still feel more comfortable being able to test the IE 6/Windows XP-specific cases on either https://www.allizom.org or a dark-launched production instance, but am also OK with pushing and staying vigilant, post-push.
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/23432f1f3c68b1abe6ab698b0c95470ccae955fa [fix bug 1304538] Add sha-1 download buttons for IE 6-8 https://github.com/mozilla/bedrock/commit/bfddc3938b97129f0b930fcd97cc235fd239535e Merge pull request #4413 from alexgibson/bug-1304538-sha-1-download-xp [fix bug 1304538] Add sha-1 download buttons for IE 6-8
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I tested this change on staging using IE6 on XP SP2 and can confirm the buttons get the sha-1 bouncer URL as expected.
OK this is now deployed to production and sha-1 bouncer links are now active.
Verified FIXED on production; I've re-tested the various combinations in comment 10, and spot-checked a few more scenarios I did on dev/staging, too, such as disabling JavaScript, and ensuring that the static Download button array includes "Windows (XP/Vista)" and correctly links to https://download-sha1.allizom.org/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: