Migrate file upload digest algorithm from MD5 to SHA-384 (FIPS 140-3 + NCS) - #1884
Migrate file upload digest algorithm from MD5 to SHA-384 (FIPS 140-3 + NCS)#1884vkalapov wants to merge 5 commits into
Conversation
…+ NCS) LMCROSSITXSADEPLOY-3224
| public static final String VARIABLE_NAME_SERVICE_ID = "__SERVICE_ID"; | ||
|
|
||
| public static final String DIGEST_ALGORITHM = "MD5"; | ||
| public static final String DIGEST_ALGORITHM = "SHA-384"; |
There was a problem hiding this comment.
Shouldn't we use SHA3 alrogirthm instead of SHA2? Also recommended length isn't it 512 instead of 384?
Another important thing is what will happen when this change is applied during blue-green update and there are running mta operations or files upload?
What will happen if files were uploaded and persisted with md5 digest and then read/retrieved from updated instance of deploy service and try to parse stored md5 checksums as SHA-384? I think we have to implement some backwards compatible logic in order to avoid breaking running mta operations/running file uploads.
There was a problem hiding this comment.
SHA3 is needed for ADVANCED requirements, SHA-384 satisfies the moderate requirements in our case.
Mid operation swap was tasted without failures. After the initial upload, the digest is only fetched and checked during write operations (i.e. uploading a new file).
Also tested directly through the API endpoints to upload and start deploy operations separately with the initial being a md5 digest and the latter being after swap with sha-384 changes.
| public static final String VARIABLE_NAME_SERVICE_ID = "__SERVICE_ID"; | ||
|
|
||
| public static final String DIGEST_ALGORITHM = "MD5"; | ||
| public static final String DIGEST_ALGORITHM = "SHA-384"; |
There was a problem hiding this comment.
Is there a performance degradation when the new algorithm is used?
There was a problem hiding this comment.
For file uploads, the operation is typically I/O-bound rather than hash-bound, so we don't expect a meaningful performance difference in practice. Either way, the mandatory performance tests should reveal any regressions.
|
We also use MD5 in MtaMetadataUtil to hash the mta id. Do we need to change the algorithm there? |
The MD5 in MtaMetadataUtil is out of scope for this PR - this one addresses file upload digest only. Since it requires a migration strategy to avoid breaking detection of existing deployed MTAs. |
|
3 participants
What
Change
Constants.DIGEST_ALGORITHMfrom"MD5"to"SHA-384"and update all test fixtures accordingly.Why
SHA-384 satisfies both FIPS 140-3 (FIPS 180-4) and NCS MODERATE requirements. MD5 and SHA-256 are not approved at NCS MODERATE level.
Compatibility
Backward compatible — no breaking change.
The server always computes and stores its own digest on upload (
DatabaseFileService→SqlFileQueryProvider). No client-sent digest is ever read or verified on the server side.isFileAlreadyUploadedwill hit"Unsupported digest algorithm"for the SHA-384 entries returned byGET /files, re-upload on every retry instead of skipping — deploys complete successfully.UploadAppStepdetects mismatch between freshly computed SHA-384 and the MD5 value stored in the CF app environment → one-time forced re-upload of every app binary. Self-heals on the second deploy.LMCROSSITXSADEPLOY-3224