Closed Bug 1105689 Opened 9 years ago Closed 7 years ago

Support stronger hash algorithms than SHA1 for signing certificates

Categories

(Toolkit :: Application Update, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla56
Tracking Status
thunderbird_esr52 --- wontfix
firefox-esr52 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- verified

People

(Reporter: gk, Assigned: robert.strong.bugs)

References

Details

(Keywords: sec-want, Whiteboard: [fce-active-legacy][adv-main56-])

Attachments

(6 files, 15 obsolete files)

12.47 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
7.99 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
1.01 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
36.60 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
208.00 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
7.06 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
SHA1 is not acceptable anymore for signature generation for a while now (see e.g. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf page 14) but the certificates used for signing are not allowed to user other hash algorithms (e.g. from the SHA 2 family):

https://wiki.mozilla.org/Software_Update:MAR (section SIGNATURE_ENTRY.SignatureAlgorithmID)

This bug is about adding support for stronger hash algorithms.
Our choices are to either only support Winxp so3 and above or to use nss or similar to verify the certificate which was not an option when update Mar signing was implemented. If winxp sp3 was the minimum windows version supported nothing would need to be done to app update though a releng bug would be needed to sign with the new certificate.

Note: platforms other than Windows don't support Mar signing yet though that should be completed soon.

Another option would be to serve mars signed with a sha1 certificate to the systems that don't support sha2 etc. and serve mars signed with sha2 or above to systems that support those algorithms.

Have you also filed a bug to change the certificate algorithm when signing the binaries on Windows?
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1)
> Our choices are to either only support Winxp so3 and above or to use nss or
> similar to verify the certificate which was not an option when update Mar
> signing was implemented. If winxp sp3 was the minimum windows version
> supported nothing would need to be done to app update though a releng bug
> would be needed to sign with the new certificate.

What do you mean with "nothing would need to be done to app update"? I was under the impression that at least

https://mxr.mozilla.org/mozilla-central/source/modules/libmar/verify/mar_verify.c#330 and
https://mxr.mozilla.org/mozilla-central/source/modules/libmar/sign/mar_sign.c#98

prevent other signature algorithms from getting used?
 
> Note: platforms other than Windows don't support Mar signing yet though that
> should be completed soon.

Yeah, we plan to ship update signing on Linux, Mac and Windows either next week or with the ESR 31 release afterwards. And we use NSS on all platforms. I know, there might be pitfalls with that approach but trusting a binary blob we can't audit was a bit too much to swallow... We'll see how it goes.
 
> Another option would be to serve mars signed with a sha1 certificate to the
> systems that don't support sha2 etc. and serve mars signed with sha2 or
> above to systems that support those algorithms.

Sounds like a way to go for me.

> Have you also filed a bug to change the certificate algorithm when signing
> the binaries on Windows?

No, just that generic one.
Yes we'll need some libmar enhancements to support it.

We should check with the security team to see if this is something important that they want us to make a priority or not. For example, are we already compromised in other areas in terms of signatures?

At the time this was implemented, we were already using sha-1 for authenticode checks, I'm not sure if that changed or not since then.

See here for some context on why SHA1 was used for MAR signing originally:
https://bugzilla.mozilla.org/show_bug.cgi?id=699700#c40

Note that we'd also need a new stop-gate upgrade path. Upgrading from X -> Y where Y is signed with the new signature ID wouldn't be possible directly because no old updater would know what to do with a signature id of 2, so it would have to first be upgrade from X -> X2(signed with sigid1, build has support for sig id2) -> Y(new mars with sig id2).
(In reply to Brian R. Bondy [:bbondy] from comment #3)
> Yes we'll need some libmar enhancements to support it.
> 
> We should check with the security team to see if this is something important
> that they want us to make a priority or not. For example, are we already
> compromised in other areas in terms of signatures?
> 
> At the time this was implemented, we were already using sha-1 for
> authenticode checks, I'm not sure if that changed or not since then.
> 
> See here for some context on why SHA1 was used for MAR signing originally:
> https://bugzilla.mozilla.org/show_bug.cgi?id=699700#c40
> 
> Note that we'd also need a new stop-gate upgrade path. Upgrading from X -> Y
> where Y is signed with the new signature ID wouldn't be possible directly
> because no old updater would know what to do with a signature id of 2, so it
> would have to first be upgrade from X -> X2(signed with sigid1, build has
> support for sig id2) -> Y(new mars with sig id2).

Does that apply even if we include both the SHA-1 and SHA-2 based signatures?
We do have support for multiple signatures in the MAR file, and the docs indicate that that we currently use OR semantics.  But this was added for b2g where each one was going to use the same algorithm id, but it was just different parties signing each one.

It looks to me like a new MAR file would be rejected with a new signature ID that contained 2 signatures:

See the last if blog below in the C code for mar_extract_and_verify_signatures_fp:

>  for (i = 0; i < signatureCount; i++) {
>    /* Get the signature algorithm ID */
>    if (fread(&signatureAlgorithmIDs[i], sizeof(uint32_t), 1, fp) != 1) {
>      fprintf(stderr, "ERROR: Could not read signatures algorithm ID.\n");
>      return CryptoX_Error;
>    }
>    signatureAlgorithmIDs[i] = ntohl(signatureAlgorithmIDs[i]);
>  
>    if (fread(&signatureLen, sizeof(uint32_t), 1, fp) != 1) {
>      fprintf(stderr, "ERROR: Could not read signatures length.\n");
>      return CryptoX_Error;
>    }
>    signatureLen = ntohl(signatureLen);
>
>    /* To protected against invalid input make sure the signature length
>       isn't too big. */
>    if (signatureLen > MAX_SIGNATURE_LENGTH) {
>      fprintf(stderr, "ERROR: Signature length is too large to verify.\n");
>      return CryptoX_Error;
>    }
>
>    extractedSignatures[i] = malloc(signatureLen);
>    if (!extractedSignatures[i]) {
>      fprintf(stderr, "ERROR: Could allocate buffer for signature.\n");
>      return CryptoX_Error;
>    }
>    if (fread(extractedSignatures[i], signatureLen, 1, fp) != 1) {
>      fprintf(stderr, "ERROR: Could not read extracted signature.\n");
>      for (i = 0; i < signatureCount; ++i) {
>        free(extractedSignatures[i]);
>      }
>      return CryptoX_Error;
>    }
>
>    /* We don't try to verify signatures we don't know about */
>    if (signatureAlgorithmIDs[i] != 1) {
>      fprintf(stderr, "ERROR: Unknown signature algorithm ID.\n");
>      for (i = 0; i < signatureCount; ++i) {
>        free(extractedSignatures[i]);
>      }
>      return CryptoX_Error;
>    }
>  }
<strike>See the last if blog below in the C code for mar_extract_and_verify_signatures_fp:</strike>
See the last "if" block below in the C code for mar_extract_and_verify_signatures_fp:
(In reply to Brian R. Bondy [:bbondy] from comment #5)
> We do have support for multiple signatures in the MAR file, and the docs
> indicate that that we currently use OR semantics.

I think the current code requires that all signatures be verified ("AND" semantics).  From the end of mar_extract_and_verify_signatures_fp:
>   if (numVerified == signatureCount && keyCount == numVerified) {
>     return CryptoX_Success;
>   }
> 
>   if (numVerified == 0) {
>     fprintf(stderr, "ERROR: Not all signatures were verified.\n");
>   } else {
>     fprintf(stderr, "ERROR: Only %d of %d signatures were verified.\n",
>             numVerified, signatureCount);
>   }
>   return CryptoX_Error;
> }
(In reply to Brian R. Bondy [:bbondy] from comment #3)
> Yes we'll need some libmar enhancements to support it.
Besides tooling changes to generate mar files and possibly checking multiple certificates are there app update client changes required to support verifying sha2 and above?
Flags: needinfo?(netzen)
> I think the current code requires that all signatures be verified ("AND" semantics)

Agreed.  Same argument holds for needing the upgrade path to go through a specific version though.

> Besides tooling changes to generate mar files and possibly checking multiple 
> certificates are there app update client changes required to support verifying sha2 and above?

I was speaking more towards libmar changes being needed.  I don't think there's any changes beyond that.
Flags: needinfo?(netzen)
So I can plan out this work will the libmar changes only apply to the tools for creating mars or will these changes also apply to client app update code?
If we're going the 2 MAR route, we'll need to:
i) Detect which type of hash check will happen, we'll just only do a sha1 if that's all that's avail on xp sp2.
ii) Add code to always verify only the stronger hash when more than one hash is available.
iii) Specify from updater code which hash to use for the verify
iv) Change libmar to accept only the matching "hash / sign" algorithm ID passed in
v) Possibly add some tooling to support signing / hashing in different ways
s/
If we're going the 2 MAR route, we'll need to:
/
If we're going the 2 signature and hash route, we'll need to:
It is my understanding that if we continue to support WinXP SP2 there will be an installer with the binaries signed with a SHA1 cert and systems greater than WinXP SP2 will have an installer with the binaries signed with a SHA2 cert. If this ends up being the case there will need to be separate MAR files for the clients with the binaries signed with a SHA1 cert and the clients with the binaries signed with a SHA2 cert. With that in mind I think the 2 MAR route is the way to go.
If you go with two separate MARs then you have to make sure that you can't feed the "weak" one to systems that are capable of understanding the stronger one. "SHA1? nice try, no update for you."
Is bug 1079858 work basically fixing this bug here?
Keywords: sec-want
The current plan to move XP users to ESR 52 (bug 1303827) would take care of the need for two sets of MAR files as discussed above; all supported systems as of 53 would support SHA2 natively if that plan does get used. That doesn't necessarily raise the priority of this bug, but it does make the implementation effort an awful lot smaller.
Matt's statement in comment #18 is what I had planned on.
Priority: -- → P2
Target Milestone: --- → mozilla53
Attached patch patch libmar data files (obsolete) — Splinter Review
Just started on this and the patches are no where near complete. I am going to try to include backwards compatibility so an update watershed won't be necessary. When we have to have an update watershed the backwards compatibility can be removed.

So far I've gotten the libmar tests passing on Windows.
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #20)
> Created attachment 8815637 [details] [diff] [review]
> patch libmar data files
> 
> Just started on this and the patches are no where near complete. I am going
> to try to include backwards compatibility so an update watershed won't be
> necessary. When we have to have an update watershed the backwards
> compatibility can be removed.
Since the cert verification was changed to AND semantics chances are this will require an update watershed. :(
Depends on: 1321951
Dan and Al, I'm planning on going with SHA384 since it is less vulnerable to a length extension attack. I am also considering changing the key size from 2048 to 4096. Can I get your input or the input from someone else on the security team on both of these choices? Thanks!
Flags: needinfo?(dveditz)
Flags: needinfo?(abillings)
Talked with dveditz and got his go ahead with using SHA384 since it is less vulnerable to length attacks than SHA512 and a key size of 4096.
Flags: needinfo?(dveditz)
Flags: needinfo?(abillings)
Dan, we changed the requirement to only validate with one of the certificates to requiring all certificates to validate for B2G. Would you have a problem with reverting to the original requirement to only validating with one of the certificates?
Flags: needinfo?(dveditz)
Attached patch patch - libmar data files (obsolete) — Splinter Review
Attachment #8815637 - Attachment is obsolete: true
Attachment #8815638 - Attachment is obsolete: true
Attachment #8815639 - Attachment is obsolete: true
Attached patch patch - libmar client code (obsolete) — Splinter Review
Attachment #8818427 - Attachment is obsolete: true
Comment on attachment 8818707 [details] [diff] [review]
patch - libmar client code

Stephen, can I get you to do a review of this... especially the changes to MacVerifyCrypto.cpp? Thanks!
Attachment #8818707 - Flags: review?(spohl.mozilla.bugs)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #31)
> Created attachment 8818711 [details] [diff] [review]
> patch - update tests
> 
> Pushed to try
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=d6e56372c1fe119323fb495f14b36db8b8738069
Try run looks good
Note to self: the following wiki will need to be updated
https://wiki.mozilla.org/Software_Update:MAR
Comment on attachment 8818707 [details] [diff] [review]
patch - libmar client code

Review of attachment 8818707 [details] [diff] [review]:
-----------------------------------------------------------------

This looks mostly fine to me. I'd like to take another look at the next patch. Thanks!

::: modules/libmar/sign/mar_sign.c
@@ +94,5 @@
>              XP_MIN_SIGNATURE_LEN_IN_BYTES);
>      return -1;
>    }
>  
> +  *ctx = SGN_NewContext (SEC_OID_PKCS1_SHA384_WITH_RSA_ENCRYPTION, *privKey);

nit: drop the space between SGN_NewContext and (

::: modules/libmar/verify/MacVerifyCrypto.cpp
@@ +156,5 @@
>                                  signatureData,
>                                  &error);
>    if (!verifier || error) {
>      CFRelease(signatureData);
>      return CryptoX_Error;

I just realized that we should be releasing |error| when not NULL. It would be great to do this throughout this function while we're here. See https://developer.apple.com/reference/security/1393861-sectransformsetattribute?language=objc

@@ +161,5 @@
>    }
>  
>    SecTransformSetAttributePtr(verifier,
> +                              kSecDigestTypeAttribute,
> +                              kSecDigestSHA2, &error);

nit: place &error on separate line to keep with existing style in this function.

@@ +169,5 @@
> +    return CryptoX_Error;
> +  }
> +
> +  int digestLength = 384;
> +  CFNumberRef dLen = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &digestLength);

dLen would need to be released when we're done with it. See https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029

It might be easier to just pass the following to SecTransformSetAttributePtr instead of dLen:

(__bridge CFNumberRef)@384
Attachment #8818707 - Flags: review?(spohl.mozilla.bugs)
Comment on attachment 8819067 [details] [diff] [review]
patch - libmar client code

__bridge isn't already available (see previous try push) so I just went with releasing it.
Attachment #8819067 - Flags: review?(spohl.mozilla.bugs)
Rail, heads up that we're going to need SHA384 certificates with a key size of 4096 for this bug just as was done for the SHA1 certificates with a key size of 2048 that you created for bug 720777. It will likely be a month or so before we need them.
Flags: needinfo?(rail)
The reason it will likely be a month or so is because I want to land bug 641212 at the same time. Since this will require a watershed since the cert check requires all certs to validate and this will allow for a simpler approach where we only support lzma in bug 641212.
Comment on attachment 8819067 [details] [diff] [review]
patch - libmar client code

Review of attachment 8819067 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you!
Attachment #8819067 - Flags: review?(spohl.mozilla.bugs) → review+
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #39)
> Rail, heads up that we're going to need SHA384 certificates with a key size
> of 4096 for this bug just as was done for the SHA1 certificates with a key
> size of 2048 that you created for bug 720777. It will likely be a month or
> so before we need them.

Rail, can the new certificates you create be used on oak first so this can be tested on oak before landing for nightly?
Attachment #8818426 - Flags: review?(mhowell)
Attachment #8818711 - Flags: review?(mhowell)
Attachment #8819067 - Flags: review?(mhowell)
Comment on attachment 8818708 [details] [diff] [review]
patch - update data files

Matt, I don't plan on landing this on m-c until after the lzma work is done. I am going to try to get this landed on oak as soon as releng can get the certs and mar signing set up.
Attachment #8818708 - Flags: review?(mhowell)
I'm going to look at this either today or on Monday. Let me know if this is urgent.
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #44)
> I'm going to look at this either today or on Monday. Let me know if this is
> urgent.
Definitely not urgent... in a week or two should suffice
Attachment #8819067 - Flags: review?(mhowell) → review+
Attachment #8818711 - Flags: review?(mhowell) → review+
Attachment #8818708 - Flags: review?(mhowell) → review+
Attachment #8818426 - Flags: review?(mhowell) → review+
It sounds like we need to support 2 mar signing in parallel. It's going to be a combination of bug 1186425 (new signing format support) and bug 869498 (need to package and deploy the new signmar binary, installed in parallel). I'll file a separate releng bug for this.
Depends on: 1324498
I filed bug 1324498 to track Releng work and hope I didn't miss anything.
Flags: needinfo?(rail)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #26)
> Dan, we changed the requirement to only validate with one of the
> certificates to requiring all certificates to validate for B2G. Would you
> have a problem with reverting to the original requirement to only validating
> with one of the certificates?

Do you mean signatures rather than certificates? Each signature probably has a couple of certs in a chain.

Why would we have multiple signatures, some of which are invalid?

If they're different kinds of signatures, and there's some way to know ones that don't meet our current requirements it would be OK to pretend those don't exist and validate the ones that do meet the requirement.
Flags: needinfo?(dveditz) → needinfo?(robert.strong.bugs)
(In reply to Daniel Veditz [:dveditz] from comment #48)
> (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from
> comment #26)
> > Dan, we changed the requirement to only validate with one of the
> > certificates to requiring all certificates to validate for B2G. Would you
> > have a problem with reverting to the original requirement to only validating
> > with one of the certificates?
> 
> Do you mean signatures rather than certificates? Each signature probably has
> a couple of certs in a chain.
Signatures created using different certificates.

Per the security review the certificates are self signed.

Note: the signatures are checked using native API's on Windows and Mac and with NSS on Linux also per the security review.

> 
> Why would we have multiple signatures, some of which are invalid?
I don't recall why exactly it was decided during the security review to support multiple certificates and succeed if only one succeed but iitc it was so if we change certificate formats as we are doing in this bug we could fail on the old cert, succeed with the new cert, and thereby not have to perform an update watershed.

> 
> If they're different kinds of signatures, and there's some way to know ones
> that don't meet our current requirements it would be OK to pretend those
> don't exist and validate the ones that do meet the requirement.
That is what I am hoping for though I'm not sure how valuable it will be over time since they shouldn't change often.
Flags: needinfo?(robert.strong.bugs) → needinfo?(dveditz)
The typical risk of ignoring bad signatures in a case like this is a scenario like
* good package signed correctly by signature "A"
* it gets tampered with, invalidating "A"
* it gets resigned with signature "B" that the bad guys got somehow

Bad signature A can be a warning sign that something funny is going on, though I guess the bad guy could just remove the old signature in that case. There's a difference between an unknown cert and a tampered package, and in a PKI situation you'd get an error about the signature failing vs. a bad cert.

That doesn't match this case because we're not using publicly issued certs, we're requiring the package to be signed by the one and only known good cert. If we ever supported _two_ certs in the downloader (a primary and a backup?) then we'd have to validate both signatures if we found both certs just in case. Then bad guys could just remove one, so don't do that -- just support one cert. Then it's OK to ignore signatures by certs you don't know.
Flags: needinfo?(dveditz)
I'd like CryptoEng to have a look at this and also briefly look at our SHA-2 implementations elsewhere for comparison. Adding JC.
Keep in mind that the implementation design that was created with the security team for this required that we use the system provided crypto instead of NSS if at all possible.
The patches looks good to me. They use SHA384 from openssl, which is fine. According to the comments differences between SHA512 and SHA384 were discussed (and in this case 384 is the better options).
jc and dveditz, can both of you provide feedback in regards to whether we can move forward with using SHA-384 or if a different algorithm should be used? Thanks!
Flags: needinfo?(jjones)
Flags: needinfo?(dveditz)
Robert: Franziskus' analysis matches mine. SHA384 is a good choice.
Flags: needinfo?(jjones)
Removing the needinfo for dveditz since he already ok'd the use of SHA384
Flags: needinfo?(dveditz)
Target Milestone: mozilla53 → mozilla56
QA Contact: amasresha
Depends on: 641212
Attached patch patch - libmar data files (obsolete) — Splinter Review
This patch applies on top of the patches in bug 641212
Attachment #8818426 - Attachment is obsolete: true
Attachment #8885612 - Flags: review+
Attached patch patch - update tests (obsolete) — Splinter Review
This patch applies on top of the patches in bug 641212
Attachment #8818711 - Attachment is obsolete: true
Attachment #8885616 - Flags: review+
Attached patch patch - update data files (obsolete) — Splinter Review
This patch applies on top of the patches in bug 641212
Attachment #8818708 - Attachment is obsolete: true
Attachment #8885617 - Flags: review+
Priority: P2 → P1
Patches are ready to land on oak for manual testing after the releng bugs are ready and the changes from bug 641212 that are already on oak have been manually tested. So, hopefully soon. After that both bug 641212 and this bug will land on m-c.
Whiteboard: [fce-active]
Removed adding tags = libmar to xpcshell.ini. Carrying forward r+
Attachment #8819067 - Attachment is obsolete: true
Attachment #8889281 - Flags: review+
Attached patch patch - libmar data files (obsolete) — Splinter Review
Updated after recent lzma changes
Attachment #8885612 - Attachment is obsolete: true
Attachment #8889557 - Flags: review+
Attachment #8885616 - Attachment is obsolete: true
Attachment #8889558 - Flags: review+
Attached patch patch - update data files (obsolete) — Splinter Review
Landed on oak along with bug 641212
Attachment #8885617 - Attachment is obsolete: true
Attachment #8889559 - Flags: review+
I had to update the data files for bug 641212. Carrying forward r+
Attachment #8889557 - Attachment is obsolete: true
Attachment #8891230 - Flags: review+
Attachment #8889559 - Attachment is obsolete: true
Attachment #8891231 - Flags: review+
I put these in their own patch since they intentionally have windows line endings.
Attachment #8891234 - Flags: review+
Pushed by rstrong@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/f72832cc0480
use SHA384 certificates to sign app update mar files. Part 1 - convert the libmar code from SHA1 to SHA384. r=mhowell, r=spohl, a=app_update_sha384
https://hg.mozilla.org/mozilla-central/rev/a0469afc3098
use SHA384 certificates to sign app update mar files. Part 2 - libmar test mar files signed with a SHA384 cert. r=mhowell, a=app_update_sha384
https://hg.mozilla.org/mozilla-central/rev/0fcbe72581bc
use SHA384 certificates to sign app update mar files. Part 3 - libmar test extracted SHA384 signatures from the test mar files. r=mhowell, a=app_update_sha384
https://hg.mozilla.org/mozilla-central/rev/92f6879a8f9f
use SHA384 certificates to sign app update mar files. Part 4 - app update SHA384 DER encoded certtificates. r=mhowell, a=app_update_sha384
https://hg.mozilla.org/mozilla-central/rev/23d91b010a0e
use SHA384 certificates to sign app update mar files. Part 5 - app update test change for the new test mar file size. r=mhowell, a=app_update_sha384
https://hg.mozilla.org/mozilla-central/rev/a6c502679d44
use SHA384 certificates to sign app update mar files. Part 6 - app update test mar files signed with a SHA384 certificate. r=mhowell, a=app_update_sha384
Flags: in-testsuite+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Verified as fixed.
Test runs are available here: https://testrail.stage.mozaws.net/index.php?/reports/view/494
Status: RESOLVED → VERIFIED
Whiteboard: [fce-active] → [fce-active][adv-main52-]
Whiteboard: [fce-active][adv-main52-] → [fce-active][adv-main56-]
When updating Fx 56.0 to 56.0.1 using the partial.mar or complete.mar files, updates fail.
D/L files from https://ftp.mozilla.org/pub/firefox/releases/56.0.1/update/linux-x86_64/en-US/

The error in Linux terminal is: "ERROR: Unknown signature algorithm ID."  That error is shown in code from comment 5, above.
Same error when installing firefox-56.0-56.0.1.partial.mar, and firefox-56.0.1.complete.mar

I didn't see an error or have problem installing firefox-55.0.3-56.0.partial.mar.
The Mozilla Firefox version is installed in /opt.

Only SHA256, 512 are listed on the v56.0.1 D/L page (above)  - and those check out on the downloaded files.
I also verified signatures on the two 56.0.1 update files.

No idea what the problem is, except a change for checksums used in Fx landed in v56 & that's the 1st one I saw this error or had a problem installing updates.

After updating 55.0.3 to 56.0, rechecking for updates should show another is available (56.0.1), but shows "up to date."

In about:preferences, it lists Version 56.0 (64-bit), but Update History shows last update was 55.0.3.
Whiteboard: [fce-active][adv-main56-] → [fce-active-legacy][adv-main56-]
You need to log in before you can comment on or make changes to this bug.