Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed support for cryptographically broken algorithms MD2, MD4, MD5 #78

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

LowAmmo
Copy link

@LowAmmo LowAmmo commented Sep 30, 2022

Addresses the deprecation that has been there since iOS 13

Also added a project file to the repo to make future maintenance easier

Description

  • Removing all the code supporting MD2, MD4, MD5
    • They have been deprecated by Apple for being cryptographically broken
    • Cleans up warnings seen by anyone targeting an iOS version >13.0
  • Also included a project file to make future updates & testing easier

Motivation and Context

Issue: #77

Trying to eliminate warnings we see in our application (from consuming SwiftJWT, which consumes this)

How Has This Been Tested?

Unit testing in the repo/code. Also verified passivity in our application.

Checklist:

  • I have submitted a CLA form
    (as on other PRs, submitted one electronically, so, assuming that would apply to this, too?)
  • If applicable, I have updated the documentation accordingly.
  • If applicable, I have added tests to cover my changes.

@LowAmmo
Copy link
Author

LowAmmo commented Feb 28, 2023

@dannys42, @mman - Modified the PR to clean things up and match the other related repos that just rely on loading the Package.swift to dynamically generate the xcode project, etc.

@mman
Copy link
Contributor

mman commented Feb 28, 2023

@LowAmmo I took a quick look and it LGTM. I will have to get some time to pull your branch and see whether the compilation will be clean... thanks!

@mman
Copy link
Contributor

mman commented Mar 7, 2023

@dannys42, @mman - Modified the PR to clean things up and match the other related repos that just rely on loading the Package.swift to dynamically generate the xcode project, etc.

Tried your fork in my project and it builds cleanly now! LGTM!

@sonarcloud
Copy link

sonarcloud bot commented Mar 28, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@LowAmmo
Copy link
Author

LowAmmo commented Nov 19, 2024

@dannys42 - I think this would be the last one (other than possibly updating to reference to proper dependency versions from Swift-JWT, depending on what versions everything gets released to cocoapods, under).

Thanks...in advance... 😄

@dannys42
Copy link
Contributor

@LowAmmo Thanks for the PR and apologies for the delay. I just want to confirm whether errors/warnings are visible in recent versions of Xcode/Swift? I'm running Xcode 16.1 and not seeing any warnings/errors for macOS or iOS builds.

I understand that these hash algorithms are not cryptographically secure, however they are still hashing functions that may be used in some legacy cases and perfectly fine (e.g. for data integrity checks). As a library that other applications may depend on, I'm hesitant to remove them unless they're causing a problem or difficult to maintain.

@CLAassistant
Copy link

CLAassistant commented Nov 20, 2024

CLA assistant check
All committers have signed the CLA.

@LowAmmo
Copy link
Author

LowAmmo commented Nov 20, 2024

@dannys42 - No worries!

To see the warnings, just need to consume this library in an iOS app that targets iOS 13 or newer as the minimum iOS version.

My rationale was that if we know they are cryptographically broken...probably no one should be using them anymore (so they should be able to not upgrade to the new version of this library). But if you think there are consumers that would want to still use those methods, I could modify this change to consider those erroneous options if the targeted iOS version is 13 or greater.

@dannys42
Copy link
Contributor

@LowAmmo Interesting. I wonder why those warnings don't show when the SPM is targeting iOS in Xcode.

If the underlying calls are deprecated, then I think it would be prudent to annotate those options as deprecated (if possible). It looks like Apple took a different approach and is labeling the hashes as insecure in code. Insecure.MD5. While that's an API breaking change, I think that's a reasonable step as well.

Either way, it wouldn't hurt to update the inline comment stating that these methods are insecure for cryptographic purposes.

For reference, here's what Synk has to say:

MD5 isn't all bad
While the usage of MD5 in security and cryptography is depreciated, it can still be used as a hash algorithm in hash map data structures for example. So, just because you see MD5 being used, doesn’t necessarily mean it is an insecure implementation. It depends on the usage.

Also probably worth mentioning that Amazon S3 ETags may also use MD5 hashes.

@LowAmmo
Copy link
Author

LowAmmo commented Nov 21, 2024

In that case...I'll see what I can get away with so that properly using everything doesn't produce any warnings in code...

Thinking that mimicking what Apple did makes sense. Deprecate "md5", but add a new value "md5_insecure" to try to highlight the same thing - that it's cryptographically busted, but could still be useful for hashmaps, etc.

@LowAmmo
Copy link
Author

LowAmmo commented Nov 21, 2024

@dannys42 - I think I have a solution that meets your requests.

Working on cleaning up the code...

Pretty much starting from scratch.

Wasn't sure what you would like the "new" version to be - 3.0.0, 2.0.3, 2.1.0?
(2.1.0 is probably most correct, since these changes are all passive now, but that would require a change to other libraries to consume the new version, etc. Which I am definitely not opposed to get PRs out there for, just want to make sure we do a strategy that works for everyone)

@LowAmmo LowAmmo force-pushed the Issue77-remove-md2-md4-md5 branch from ce64a36 to 7bc967e Compare November 21, 2024 21:43
@LowAmmo
Copy link
Author

LowAmmo commented Nov 21, 2024

@dannys42 - So to try to still force developers to update, I obsoleted md2, md4, & md5 for iOS. But, created an md5_insecure as an alternative.

But, this way they are still available to anyone targeting earlier iOS versions (just have to consume slightly differently), or anyone not doing iOS.

Also cleaned up preprocessor directives so that it should be easier to add support for things like VisionOS, etc., in the future.

Hopefully, this is more what you're looking for?

…D4, MD5 for iOS

Rework md5 into md5_insecure
Provide a SHA1_insecure

Update travis.yml
@LowAmmo LowAmmo force-pushed the Issue77-remove-md2-md4-md5 branch from 328609a to a67f264 Compare November 21, 2024 22:36
Copy link
Contributor

@dannys42 dannys42 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, I'm sorry I didn't realize there would be so much code change. I'll have to look at the unit tests and such later, but overall I think your changes look pretty reasonable.

I had a few thoughts in some areas in case you had some ideas, but if not that's ok. Need to go too crazy.

@@ -51,17 +54,28 @@ public class Digest: Updatable {
public enum Algorithm {

/// Message Digest 2 See: http://en.wikipedia.org/wiki/MD2_(cryptography)
@available(iOS, introduced: 2.0, obsoleted: 13.0, message: "This function is cryptographically broken and should not be used in security contexts. Clients should migrate to SHA256 (or stronger).")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: Personally I'm not fond of the word "broken" because it implies that it doesn't work. But I understand it is a common industry phrasing. I like Apple's description of just plainly saying it is not cryptographically secure. (Some more detailed discussion on the topic if you're interested: https://www.quora.com/What-is-broken-cryptography)

But I'm ok with leaving your comment here as is.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to say "insecure" instead of "broken"

case md5

/// Message Digest 5
/// - NOTE: Do NOT use for cryptography, considered insecure
case md5_insecure
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're adding _insecure for md5 and sha1, why not md2 and md4?

It'd be cool if there was a way to group the insecure methods under ".insecure.md5"... but I'm not sure that could be done as an enum. :-/

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just because Apple has deprecated md2 & md4 & md5 -which causes build warnings. But, as you pointed out (and I was able to implement), they have the "Insecure" wrapper around MD5 - that doesn't generate warnings, and is still available.

So, just trying to represent what Apple is representing - that consumers shouldn't use md2, md4, or md5 for secure things, but if they want to, they can MD5 for Insecure operations.

#if os(macOS) || os(iOS) || os(tvOS) || os(watchOS)
engine = DigestEngineCC<CC_MD2_CTX>(initializer:CC_MD2_Init, updater:CC_MD2_Update, finalizer:CC_MD2_Final, length:CC_MD2_DIGEST_LENGTH)
#elseif os(Linux)
#if os(Linux)
fatalError("MD2 digest not supported by OpenSSL")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to exclude md2 as a case in the enum for Linux?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, good idea!

Excluding the definition for md2 from the enum if building for Linux.

self.engine = DigestEngineCC<MD4_CTX>(initializer:MD4_Init, updater:MD4_Update, finalizer:MD4_Final, length:MD4_DIGEST_LENGTH)
#elseif os(iOS)
if #available(iOS 13, *) {
fatalError("MD4 digest is cryptographically broken")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the failure here is more that MD4 is not supported on iOS 13 and above, not that it is insecure?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is still supported (as far as I can tell), it just generates a build warning (guessing that may mean that soon it will stop being supported).

@dannys42
Copy link
Contributor

Wasn't sure what you would like the "new" version to be - 3.0.0, 2.0.3, 2.1.0?
(2.1.0 is probably most correct, since these changes are all passive now, but that would require a change to other libraries to consume the new version, etc. Which I am definitely not opposed to get PRs out there for, just want to make sure we do a strategy that works for everyone)

Thanks for trying to keep the API backward compatible. If we're following semver, then yes I think this qualifies as a minor version bump (i.e. 2.1.0).

Do the other libraries actually require these changes? It's probably safe leaving them at "from: 2.0.x", since "update packages" should resolve to the latest in the 2.x.y line, no?

@LowAmmo
Copy link
Author

LowAmmo commented Dec 3, 2024

@dannys42 - Not sure on SPM, but with the way Cocoapods works, Swift-JWT pulls in v. 2.0.1 -> 2.0.999
https://github.com/Kitura/Swift-JWT/blob/master/SwiftJWT.podspec#L17

Using the pessimistic operator. So, to pull in a 2.1.0, we would have to make a PR on Swift-JWT to either change to "2.1" (to accept any future minor versions also), or "2.1.0" (to accept any future defect version fixes on that minor version). Could also change to ">="...but that would make any future major API changes pretty tough to do.

If the offer still stands, I'll gladly take on the role of maintaining the cocoapod repo for all of these libraries (BlueRSA, BlueCryptor, SwiftJWT, etc.), since I know it's a dying system...but...we won't be switching off it anytime soon... 😦

* Don't define "md2" for Linux
* Rework deprecation warnings to say "cryptographically insecure" (instead of "broken")
@LowAmmo
Copy link
Author

LowAmmo commented Dec 3, 2024

@dannys42 - Looks like SonarCloud is now running to test the builds... Any idea of how to mark the "hotspots" as safe? (since they are used expressly for the insecure support cases?) (not sure I have the privileges/ability to mark them...)

Copy link

sonarcloud bot commented Dec 4, 2024

Quality Gate Failed Quality Gate failed

Failed conditions
2 Security Hotspots

See analysis details on SonarQube Cloud

@LowAmmo
Copy link
Author

LowAmmo commented Dec 12, 2024

@dannys42 - Guessing whatever little freetime you had in early November is busy again (or you're possible taking the "use it or lose it" December PTO... 😉 ). But, just hoping pull in some of these PRs sometime soon (and possibly getting things published to cocoapods) is still on your radar! 😄

-Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants