At my company, we use Solarwinds Web Help Desk. It a great piece of software for managing tickets, inventory, and even works as a service calendar, though we don’t really use that feature. We recently moved offices and had some downtime on our help desk server. I took this opportunity to make security improvements to our help desk.
I started off with an SSL certificate from DigiCert. We purchased a wildcard cert so we could secure multiple subdomains. I followed the directions in the WHD Administrator Guide to enable SSL. I’m new to the whole certificate thing so this was a little rocky but I got it done just the same. Feeling accomplished, I went to SSL Labs to test my site’s security. I got a surprising ‘C’ grade. That didn’t feel very good. SSL Labs told me that my grade was due to weak cipher strength, TLS v1.1 & 1.2 not enabled, Secure Client-Initiated Renegotiation is allowed, and Forward Secrecy was not an option. However, the Admin Guide didn’t mention anything except how to setup the SSL cert and force clients to use HTTPS. I’m a fan of Steve Gibson’s SecurityNow! podcast over at TwiT.TV so I understand how important it is to improve your security beyond just an SSL cert.
After some digging online, I came up with a great set of changes to make to the help desk. It wasn’t easy so I’m posting them here. It’s worth noting the specs of our system before moving on. Your system may vary but the principals will be the same.
Here are the specs of our install:
Web Help Desk Version: 12.1.0 – Build #12.1.0.300
OS Name: Mac OS X
OS Version: 10.9.4
Architecture: x86_64
Java Version: 1.6.0_65 x86_64 (Apple Inc.)
Tomcat Server number: 7.0.35.0
Now, let’s address each issue:
Weak Ciphers
I was directed by WHD tech support to this forum post: https://thwack.solarwinds.com/thread/64296 Someone in my exact situation was asking the right questions in the right place. Another person responded to change the ciphers in the /Library/WebHelpDesk/conf/tomcat_server_template.xml file. I did that and was now getting a ‘B’ grade. Nothing else had changed. I pressed on thinking that I was done in this area… (skip to Forward Secrecy to see what ciphers I ended up using)
TLS v1.1 & 1.2
I know that the WHD is a Java web app that runs on Apache Tomcat. I inspected the /conf/tomcat_server_template.xml file further and found the line that specifies that TLS be used as the main protocol. SSL Labs showed that TLS v1.0 was running but why not v1.1 or 1.2? I’ve done some work with Apache before but not Tomcat so I felt a little lost. Luckily, Tomcat is well documented. I kept running into this security document on Tomcat’s website: http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html I didn’t need the SSL cert parts of it but found an area that talked about changing the “protocol=TLS” line to “sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2,SSL3” I did this and broke WHD. After a couple of hours, it occurred to me that Tomcat uses Java to implement security features and I wasn’t using the latest v1.7.0_65. Apple computers always requested a version supplied by Apple, even if a newer version is installed. I read in this post (http://stackoverflow.com/questions/12757558/installed-java-7-on-mac-os-x-but-terminal-is-still-using-version-6) how to change that. I installed the Java JDK v1.7.0_65 from Oracle(http://www.oracle.com/technetwork/java/javase/downloads/index.html) and changed the alias for “Home” in the /Library/Java directory to stop looking at the Java “1.6.0_65” home and to now look at /Library/Java/JavaVirtualMachines/jdk1.7.0_65.jdk/Contents/Home instead. I did this by first removing the /Library/Java/HOME alias in Terminal (sudo rm /Library/Java/HOME) and creating a new symlink (sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_65.jdk/Contents/Home /Library/Java/) WHD errored out and said that “Unlimited Strength Jurisdiction Cryptography” wasn’t enabled. WHD also told me it was missing two files from its directory (local_policy.jar & US_export_policy.jar) Since I just upgraded Java, I wanted the newest versions of those files as well. Downloaded the needed files here: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html I extracted them and placed them in the /Library/WebHelpDesk/conf/java6jce/ directory. Now, TLSv1.1 and v1.2 are enabled and SSL Labs shows the help desk has an ‘A-‘ rating. You can even leave the protocol=TLS” alone, if you want. Pretty good but we can do better.
Forward Secrecy (a.k.a. Ciphers – Part 2)
In researching forward secrecy, I found out that this has little to do with WHD itself and everything to do with Tomcat and how it handles TLS/SSL. I found a blog post talking about Tomcat SSL Hardening: http://blog.bitmelt.com/2013/11/tomcat-ssl-hardening.html I ended up changing my ciphers again to this list:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHAWe’re now getting an ‘A’ rating! Feeling pretty good now.
Secure Client-Initiated Renegotiation
Why is something with “secure” in its name a problem? Normally, it’s not; but, in this case, this feature opens you up to a Denial-of-Service attack. No Bueno. In the previous blog post (http://blog.bitmelt.com/2013/11/tomcat-ssl-hardening.html) the author mentioned changing the protocol="HTTP/1.1" to protocol="org.apache.coyote.http11.Http11NioProtocol” in the server.xml file (/conf/tomcat_server_template.xml for my purpose.) I made the change and broke WHD. It then occurred to me that the same documentation I’ve been using to configure the SSL protocol (http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html) keeps referring to Tomcat v7.0.54. I’m using v7.0.35. So, I downloaded the latest version of Tomcat from http://tomcat.apache.org/download-70.cgi. I extracted the update and copied all the files to the /Library/WebHelpDesk/bin/tomcat directory and made sure that the permissions were changed to match what was there before (owner=root, group=admin) I added protocol="org.apache.coyote.http11.Http11NioProtocol” again and WHD is fully functional. Still have an ‘A’ rating on SSL Labs and Secure Client-Initiated Renegotiation is unsupported.
Conclusion
WHD is a great product. I recommend anyone use it. However, it’s worth saying that any product that runs on open source software is likely not to keep up-to-date with each version of that software. WHD was happy running on an older version of Java and an older version of Tomcat; and, until I did some digging, so was I. Now that I know more about the security options available, I’m a little disappointed that Solarwinds doesn’t make it easy to turn these features on. It doesn’t even document them in their guide. Oh well. Oracle, Apache, and several well-informed users came to my rescue with their free documentation. Consider this post as me giving back.
Amore Open Source 