Now that it is within the realm of practical plausibility to actually falsify site certificates signed with SHA-1 and deploy them in the real world, it's time to cut that monkey loose. Mozilla is embarking on a plan of increasing deprecation , but Google is dumping SHA-1 certificates entirely in Chrome 56, in which they will become untrusted . Ordinarily we would follow Mozilla's lead here with TenFourFox, but 45ESR doesn't have the more gradated current SHA-1 handling they're presently using.
So, we're going to go with Chrome's approach and shut the whole sucker down. The end of 45ESR (and the end of TenFourFox source parity) will occur on June 13 with the release of Firefox 54 (52.2 ESR); the last scheduled official 45ESR is 45.9, on April 18. For that first feature parity release of TenFourFox in June after 45.9, security.pki.sha1_enforcement_level will be changed from the default 0 (permit) to 1 (deny) and all SHA-1 certificates will become untrusted. You can change it back if you have a server you must connect to that uses a SHA-1 certificate to secure it, but this will not be the default, and it will not be a supported configuration.
You can try this today. In fact, please do switch over now and see what breaks; just go into about:config , find security.pki.sha1_enforcement_level and set it to 1 . The good news is that Mozilla's metrics indicate few public-facing sites should be affected by this any more. In fact, I can't easily find a server to test this with; I've been running with this setting switched over for the past day or so with nothing gone wrong. If you hit this on a site, you might want to let them know as well, because it won't be just TenFourFox that will refuse to connect to it very soon. TBH, it would have to cause problems on a major, major site for me not to implement this change because of the urgency of the issue, but I want to give our users enough time to poke around and make sure they won't suddenly be broken with that release.
That release, by the way, will be the end of TenFourFox 45 and the beginning of the FPR (Feature Parity Release) series, starting with FPR1. Internally the browser will still be a fork of Gecko 45 and addons that ask its version will get 45.10 for FPR1 and 45.11 for FPR2 and so on, but the FPR release number will now appear in the user agent string as well as the 45.x version number, and the About box and site branding will now reference the current FPR number instead. The FPR will not necessarily be bumped every release: if it's a security update only and there are no new major features, it will get an SPR bump instead (Security Parity Release). FPR1 (SPR2) would be equivalent, then, to an internal version of 45.10.2.
The other thing we need to start thinking about is addons. There is no XUL, only WebExtensions , according to Mountain View, and moreover we'll be an entire ESR behind even if Mozilla ends up keeping legacy XUL addons around. While I don't really want to be in the business of maintaining these addons, we may want to archive a set of popular ones so that we don't need to depend on AMO. Bluhell Firewall, uBlock, Download YouTube Videos as MP4 and OverbiteFF are already on my list, and we will continue to host and support the QuickTime Enabler. What other ones of general appeal would people like added to our repository? Are there any popular themes or Personas we should keep copies of? (No promises; the final decision is mine.)
The big picture is still very bright overall. We'll have had almost seven years of source parity by June, and I think I can be justifiably proud of that. Even the very last Quad G5 to roll off the assembly line will have had almost eleven years of current Firefox support and we should still have several more years of practical utility in TenFourFox yet. So, goodbye SHA-1, but hello FPR1. The future beckons.
( * The real reason: FPR and SPR are absolutely hilarious PowerPC assembly language puns that I could backronym. I haven't figured out what I can use for GPR yet.)