When deprecated != deprecated

Every now and then we hear that a cipher algorithm has fallen to a new cracking technique. This cascades into a new round of deprecating any ciphersuites that rely on the newly cracked algorithms.  Over the years we’ve moved from SSL to TLS, from DES to 3DES, from MD5 to SHA, and so on.  The list of items on MQ’s Deprecated Ciphers page grows slowly but relentlessly over time.

But not all of the ciphersuites that IBM has deprecated are broken.  So why are they on the list and should we use them? This post will attempt to shed some light on those questions.

Non-deprecated deprecation

Sprinkled among all the other deprecated ciphers are a few with no deprecated component As of this writing, these include:

• ECDHE_ECDSA_NULL_SHA256
• ECDHE_RSA_NULL_SHA256
• TLS_RSA_WITH_NULL_NULL
• TLS_RSA_WITH_NULL_SHA256

Note that all of the component protocols—ECDHE, ECDSA, TLS, RSA, and SHA256—are present in one or more ciphersuites that are not deprecated. On the other hand, none of the non-deprecated ciphersuites contain a NULL component.

The obvious conclusion is that these entries made the list because of the NULL components of their respective ciphersuites.  NULL hasn’t been cracked because there’s nothing to crack. So these aren’t deprecated because of a crypto weakness but rather because of a policy that discourages the use of NULL ciphers in a ciphersuite.

Is that really a good thing?

The case for null ciphers

TLS provides three different security functions: authentication, privacy (encryption), and integrity (hashing). The ciphersuite name is the combination of the ciphers used for each function, the last two components being the type of encryption and the type of integrity check. So TLS_RSA_WITH_NULL_SHA256 indicates a ciphersuite in which…

• The TLS protocol uses RSA for authentication.
• No encryption is used therefore no privacy is provided.
• Integrity checks use SHA256 hashing.

Switching from NULL_SHA256 to NULL_NULL results in a ciphersuite that provides authentication but no encryption and no integrity checking.

Consider a new requirement that specifies authentication of existing plaintext MQ channels.  The administrator can use the TLS_RSA_WITH_NULL_NULL ciphersuite to provide that authentication without the overhead of adding encryption and hashing of all the data which, although that isn’t a bad thing, was not given as a requirement.  In some cases where performance is critical, a requirement is stated specifically to omit crypto on the data stream.

Deprecating ciphersuites with NULL components removes the administrator’s ability to specify that a channel will be authenticated without also using integrity and/or privacy on the data. There are plenty of cases where channel authenticity is required but integrity and/or privacy is not. MQ used to recognize this back in the days when we had NULL_MD5 and NULL_SHA, so what happened?

Deprecation from a security perspective

When the crypto community deprecates algorithms like MD5 or SHA1, it has nothing to do with the strength of the cipher. It’s more about the delta between achieved vs. perceived strength, and that this gap expands dramatically after the algorithm is broken. Prior to being cracked these ciphers were strong enough for some intended use but now, assuming we know they are broken, we should consider them as providing zero protection.

From a more pragmatic standpoint, the usual method of choosing cipherspecs is to pick the ones that provide the best performance for a given level of protection.  For use cases in which zero protection is required for privacy or integrity, the NULL cipher is a lot more performant than any broken cipher. Why would anyone deliberately choose the overhead of DES, for example, when NULL meets the requirement?

From that perspective, ciphers with SHA1 or MD5 provide a mere façade of security. People who aren’t aware they are broken might have a false sense of security seeing some non-NULL cipher specified.

However, there is no mistaking a NULL cipher as providing any security.  The delta between the security perceived and that achieved is zero – exactly what we want.  A realistic sense of insecurity is preferable to a false sense of security every time.

Are these deprecated by mistake?

There are valid use cases for ciphersuites with NULL components and the non-NULL ciphers used in these ciphersuites are still considered strong.  It’s easy to look at this and wonder if these ciphersuites were put on the list by mistake.

I do not believe that to be the case.  The IBM MQ team clearly knows about use cases for NULL privacy and/or integrity. We know this because in AMS these are considered features. AMS has always had Protection Policy of Sealed–messages that are signed but not encrypted and thus provide authentication and integrity.  The recent addition of Confidentiality policy–privacy and integrity functions but no authentication–was significant enough to be included in conference presentations and press releases.

Clearly, the MQ Dev team knows about use cases that do not call for authentication, privacy, integrity, or some combination of two of these.

Why deprecate them, then?

So why did IBM deprecate these ciphersuites in MQ? Short answer–because everyone else does.  No, really.  Let me explain.

OWASP, the PCI Security Council, and many other industry groups whose primary concerns are Internet-facing web servers do not rely on TLS for authentication at all, but absolutely require privacy and integrity at all times.  In a purely web context, this policy makes absolute sense.

But because OWASP and other industry groups deprecate weak and NULL ciphers for web servers, lots of scanners flag them. Point one of those scanners at a queue manager and any ciphersuite with a NULL cipher is flagged.  If these were not deprecated, lots of people would be opening PMRs with subject lines like “Help! The security scans of MQ are flagged for weak ciphers!”  That would then require some mechanism to disable all the ciphers with a NULL component.

Which brings us to back to the current approach.  IBM deprecates these by default but provides the means for the MQ administrator to selectively enable one or more of them.  By making the enabling of ciphers a deliberate administrative choice, IBM and the MQ Administrator can be confident that the reason the QMgr gets flagged by the security scanner will be obvious. (In some cases that confidence may be misplaced but those are hopefully the exception.)

The solution will perhaps not be so obvious since that depends a lot on local policies and exception procedures, but at least the MQ parts of that solution will be known to the administrator.  She or he can always back out the configuration that enabled the flagged cipher in the first place if that’s preferable to running the gauntlet of requirements to obtain scanner exceptions.

Not all ciphersuites with NULL are equal

The only down side to this arrangement is that the Deprecated Ciphers page doesn’t distinguish between ciphersuites that are listed because they are broken versus those on the list because they contain NULL ciphers.

These two sets currently overlap at the NULL_SHA and NULL ciphersuites.  These are older ciphersuites that use the broken SSL protocol for authentication. The use case may allow NULL ciphers but the crypto it does call for, authentication in this case, needs to be strong. One of the TLS or ECDHE ciphers with NULL components is preferable to NULL_SHA or NULL_MD5 in this case because the authentication portion must be reliable.

Over time the intersection of these two groups will grow larger.  RSA is already waning in favor of protocols like EDCHE that use ephemeral keys and provide perfect forward secrecy. Extrapolating forward, we can predict a time when TLS_RSA_WITH_NULL_SHA256 will be as undesirable as NULL_SHA is today. When that day comes the MQ administrator will need the skill and knowledge to distinguish good from bad ciphersuites.

The key, if you will excuse the pun, will be for the MQ administrator to understand which of the ciphers are on the deprecated list because they were broken and which are on the list purely for policy reasons.

Putting it all together

The addition of CONNAUTH to MQ has been driving a wave of reconsideration of authentication methods in MQ. Certificates are often preferable to passwords for headless application servers and service accounts, but at times not when doing so incurs the overhead of crypto on all the data traffic.  The use of a ciphersuite that authenticates the connection but doesn’t encrypt and/or hash the traffic can resolve that issue.

Where the use case requires it, don’t be afraid to to enable one of the appropriate deprecated ciphersuites.  Use the syntax that enables these selectively rather than enabling all of them, picking only the one that is needed.

Be prepared to respond to the security team who run the internal scanners, though.  There is a good chance that enabling one of these ciphers will trigger a flag on the scans that will require an exception.

Looking longer term, Elliptic Curve crypto may resolve the tension between performance versus scanner flagging.  EC is more performant for a given strength than older ciphers so it might be possible that the hashing and encryption do not break the performance bounds required for the channel.

The difficulty in switching to Elliptic Curve is that personal certificates for EC are incompatible with older ciphersuites so migrating may require new certs for MQ and the application.  MQ’s ability to use more than one personal certificates makes it possible for a single queue manager to support older and newer EC-based ciphersuites at the same time, thus providing a path for gradual migration of one application at a time.

What direction will you take?

However we approach it, some sort of authentication is required for connections to MQ and chances are CONNAUTH or certificates play a part of that for any given queue manager. Just don’t let the deprecation of ciphersuites will NULL components keep you from using certificates in cases where performance is critical, once you know why and how to use them appropriately.

As always, feel free to contact me with questions or comments. These articles always generate more emails than posted comments, due to the sensitive nature of the topic and that’s okay.  I try to answer all emails and will always hold them in strict confidence, although you might recognize your anonymized use case in a future blog post or conference presentation. Do post comments though when possible so that others benefit from the discussion.