NOTE: This is the TECHNICAL version. You may be interested in the Short and Concise Version.
I’m writing this to provide some general information related to GroupWise, Security, and the MD5 hash algorithm. You may not fully understand what MD5 is or how it works, and that’s okay. But you do need to be aware that your GroupWise system could be at risk if you are using MD5 anywhere in your system. Since there are potentially many points of exposure, it’s important to cover all of the bases.
GroupWise Vulnerability with MD5 Hash – A little background
It was reported even back as far as 2009 that the MD5 algorithm had been cracked. But very little was known about it, and the likelihood of this being a problem or a threat to you was very miniscule. However, this may have changed recently since scripts have been written and published that easily exploit data encrypted with MD5. In November 2011, a tool called Bozocrack (https://github.com/juuso/BozoCrack/) was released that makes cracking MD5 a breeze. It’s easy to speculate that tools such as this could be used to launch major attacks on servers around the world in efforts to find vulnerable systems and expose the encrypted data.
Furthermore, we have seen a trend with 3rd party certificate vendors that are now requiring SHA1 based certificate requests and rejecting MD5 ones completely. Some have even revoked existing MD5 based certificates and have forced customers to re-issue more secure certificates.
How does MD5 relate to a GroupWise Vulnerability?
If you’re wondering what MD5 has to do with GroupWise, there are actually several different areas within GroupWise that could be affected by this. First, let me explain the points of exposure, and then I’ll explain why this could be a problem for you and your GroupWise system.
Communication between GroupWise Agents
Most people have adopted 128 bit SSL encryption as the accepted standard for communication between two points, and GroupWise fully supports this configuration. It’s a standard practice to configure end-to-end encryption on the GroupWise agents using 128 bit SSL certificates. Nearly every communication point of GroupWise can be configured to use a secure certificate, and it’s very possible that the certificates being used are based on the MD5 hash:
- Agent to Agent communication (Such as Post Office to Message Transfer Agent, Post Office to Post Office, etc)
- Client to Post Office Communications (Used by the GroupWise Clients)
- SOAP Protocol (Used by Data Sync Mobility Pack and other 3rd party applications)
- IMAP (Protocol used by some email clients / mobile phones to retrieve email)
- POP3 (Protocol used by some email clients / mobile phones to retrieve email)
- SMTP (Protocol used to transfer email across the internet to/from the sender/recipient)
Another common practice is to use 128 bit Secure LDAP encryption for all authentication to the GroupWise system. This ensures that when a GroupWise user connects to the system, the password is securely encrypted using a 128 bit SSL Certificate. Using Secure LDAP for authentication is not a default setting, and must be setup by an administrator. There are certainly other configurations, however they are not relevant since the purpose of this document is to discuss the Secure LDAP authentication using a 128 bit SSL Certificate. With OES, the default SSL certificates utilize the SHA-1 hash algorithm, but it is possible to manually create a certificate based on the MD5 hash.
Encryption for WebAccess is configured differently because WebAccess is actually a Tomcat based application that runs through the web server. For Windows based systems, this web server is IIS. Apache is used as the web server on both Linux (GroupWise 7 – GroupWise 2012) and NetWare (GroupWise 8 and prior). Since the application is controlled by the web server, the security protocol is configured within the Web Server itself, rather than the GroupWise component. Regardless, a certificate must be created to allow secure communication, and it’s possible that this certificate was created using the MD5 hash.
Why GroupWise may be Vulnerable
The starting point of any SSL Certificate is with a Certificate Signing Request (CSR). There are a couple of different ways that you can create a CSR. Two of the most common methods are listed below, and here are the reasons why you should be concerned:
- Since many of the points referenced above are exposed to the Internet, they are potentially vulnerable if they utilize the MD5 algorithm.
- If Novell’s common tools were used to create the CSR (Certificate Signing Request), it’s likely that your certificates use the MD5 hash.
GWCSRGEN is a tool that ships with GroupWise and is used to create CSRs for your GroupWise agents. The CSR is then processed by either your local Certificate Authority (Within eDirectory tree) or by your 3rd party certificate provider, such as Thawte, Verisign, or others. The nice thing about GWCSRGEN is that it’s a GUI tool that is very simple to use, and only takes a few minutes. It used to be my favorite method for creating CSR’s. The problem with GWCSRGEN is that it uses the MD5 hash algorithm, and there doesn’t seem to be a way to change that. We’ve tested this extensively, and found that even with GroupWise 2012, the GWCSRGEN tool still uses MD5.
If you look through the GroupWise documentation, you’ll see many references to this tool for creating CSR’s for SSL certificates. And even though Novell fully supports and recommends this tool, it is no longer a valid or practical CSR creation tool. In fact, it’s very likely that a CSR created with GWCSRGEN will be rejected by most 3rd party certificate providers because it doesn’t meet their minimum requirements.
OPENSSL is a Linux based command line tool that ships with SUSE Linux Enterprise Server (SLES). If you’re running GroupWise on Linux, this is a good way to create CSR’s for your GroupWise system. Even though our testing has shown that OPENSSL generally creates SHA-1 based certificates, the certificates should still be tested and confirmed. If running GroupWise on Linux, you should not just assume that OPENSSL was used to create the CSR’s, because after all, Novell’s officially supported method is to use the GWCSRGEN utility. Additionally, companies running GroupWise on NetWare or Windows do not have OPENSSL readily available to them.
How to Determine Your SSL Certificate Hash
Regardless of how your Certificates and CSR’s were created, it’s important to check them to determine if you are using any with MD5 hash algorithms. If you find any that are using MD5, they should be replaced.
All of the GroupWise agents and components running on one server typically utilize the same certificate. You can check the certificate status with a standard web browser by going to the HTTPS Web Console for each agent. For example, the Post Office Agent typically uses port 7181, so the URL would be the IP Address of the server at port 7181. Assuming SSL is configured, the address would be https://xxx.xxx.xxx.xxx:7181 (for example, https://192.168.0.15:7181). You can find the exact port numbers and IP addresses in ConsoleOne on the agent network configuration screen as depicted below.
Once the page has loaded, you can use your browser to review the details of the certificate. An example of an MD5 and an SHA-1 Certificate are shown below.
It’s more difficult to check the status of the Certificate used by LDAP. This is because the LDAP service is not typically available to a browser, nor is it accessible via the Internet. But it’s actually quite easy. If GroupWise is using eDirectory as the LDAP source (most common scenario), GroupWise should be configured to use a *.DER certificate file in the global LDAP configuration. The file is exported from the Server Certificate Object in eDirectory that is subsequently assigned to the LDAP server secure configuration. To examine the properties of this file, you should be able to just copy it to a Windows system and double-click it. This will open it in a Certificate application and allow you to examine it. If you are using any other LDAP source, the process should be similar.
To check the status of your WebAccess certificate, just login to GroupWise WebAccess with a browser, and then analyze the certificate that is associated with it. Examples are listed below.
Certificate that utilizes MD5 Hash
Certificate that utilizes SHA1 Hash
Internal Testing results
Here are some scenarios we have tested or experienced recently when working with certificates on GroupWise:
- We have tested and confirmed that by using GWCSRGEN from any GroupWise 2012 or earlier distribution, on Windows or Linux, the resulting certificate uses the MD5 hash algorithm. It makes no difference whether the certificate is minted internally by a self signed Certificate Authority or if the CSR is presented to a 3rd party certificate vendor. Furthermore, when using ConsoleOne to mint the certificate as a self signed certificate, ConsoleOne mistakenly reports that the certificate is SHA-1, but the resulting certificate file is actually MD5 based.
- OPENSSL, if used correctly, will create Certificate Signing Requests using the SHA-1 hash algorithm.
- Related to secure LDAP authentication and associated certificate, we’ve found that in general, Certificate Services running on an OES2 or OES11 server are configured to use the SHA-1 hash algorithm by default. Therefore, if an OES server is being used as the secure LDAP source, the certificates are most likely already using the SHA-1. However, it’s possible to manually create MD5 based certificates, so these certificates still need to be checked.
Replacement of MD5 Certificates with SHA1 Certificates
Replacing the SSL certificates is beyond the scope of this document. If you have confirmed that your certificates are using an MD5 hash, we recommend that you replace them as soon as possible. If you feel that this task is beyond your expertise, or if you’d like to have someone just “Take care of it”, I invite you to contact my team of GroupWise experts and let us help you take care of it quickly and easily. We guarantee our services with a 100% money back guarantee.