I wanted to share a story about a support case I worked on recently that might serve to justify the usefulness of commercial OpenNMS Support to folks thinking about it. As always, OpenNMS is published under an open source license and so commercial support is never a requirement, but as this story involves commercial software I thought it might be useful to share it.

We have a client that handles a lot of sensitive information, to the point that they have an extremely hardened network environment that makes it difficult to manage. They place a separate copy of OpenNMS into this “sphere” just to manage the machines inside it, and they have configured the webUI to be accessed over HTTPS as the only access from the outside.

Recently, a security audit turned up this message:


Red Hat Linux 6.6 weak-crypto-key
3 Weak Cryptographic Key Fail "The following TLS cipher suites use
Diffie-Hellman keys smaller than 1024 bits: *
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (768-bit DH key) *
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (768-bit DH key)" "Use a Stronger Key If
the weak key is used in an X.509 certificate (for example for an HTTPS
server), generate a longer key and recreate the certificate. Please also
refer to NIST's recommendations on cryptographic algorithms and key
lengths (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
) ." Vulnerable


and they opened a support ticket asking for advice on how to fix it.

I had some issues with the error message right off the bat. The key used was 2048 bits, so my guess is that the algorithm is weak and not the key. The error message seems to suggest, however, that a longer key would fix the problem.

Anyway, this should be simple to fix. The jetty.xml file in the OpenNMS configuration directory lets you exclude certain ciphers, so I just had the customer add these two to the list and restart OpenNMS.

And then we waited for the nightly scan to run.

This fixed the issue with the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher but not the first one. Nothing we did seemed to help, so I installed sslscan on my test machine to try and duplicate the issue. I got a different list of ciphers, and since openssl uses different name for the ciphers than Java, and it was a bit of a pain to try and map them. I couldn’t get sslscan to show the same vulnerabilities as the tool they were using.

We finally found out that the tool was Nexpose by Rapid 7. I wasn’t familiar with the tool, but I found that I could download a trial version. So I set up a VM and installed the “Community Edition”.

Note: this has nothing to do with open core, which often refers to their “free” version as the “community” version. Nexpose is 100% commercial. They use “community” to mean “community supported”, but it is kind of confusing, like when Bertolli’s markets “light” olive oil which means “light tasting” and not low in calories.

I had to fill out a web form and wait about a day for the key to show up. I had installed the exact version of OpenNMS that the client was using on my VM, so my hope was that I could recreate the errors.

First, I had to increase the memory to the VM. Nexpose is written in Java and is a memory hog, but so is OpenNMS, and it was some work to get them to play nice together on the same machine. But once I got it running, it wasn’t too hard to recreate the problem.

The Nexpose user interface isn’t totally intuitive, but I was able to add the IP address of the local machine and get a scan to kick off without having to read any documentation. The output came as a CVS file, but you could also examine the output from within the UI.

The scan reported the same two errors, and just like before I was able to remove the “TLS_DHE_RSA_WITH_AES_128_CBC_SHA” one just by excluding it in jetty.xml, but the second one would not go away. I found a list of ciphers supported by Java, but nothing exactly matched “TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA” and I tried almost all of the combinations for similar TLS ciphers.

Then it dawned on me to try “SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA” and the error went away. I guess in retrospect it was obvious but I was pretty much focused on TLS based ciphers and it didn’t dawn on me that this would be the error with Nexpose.

It was extremely frustrating, but as my customer was being beat up about it I was glad that we could get the system to pass the audit. While this was totally an issue with the scanning software and not OpenNMS, it would have been hard to figure out without the help we were happy to give.

It may not surprise anyone that a large number of OpenNMS support issues tend to be related to products from other vendors. Usually most of them can be classified as a poor implementation of the SNMP standard, but occasionally we get something like this.

Our clients tend to be incredibly smart and good at their jobs, but having access to the folks that actually make OpenNMS can sometimes save enough time and headache to more than offset the cost of support.