The following Network Automation versions are affected by the Bar Mitzvah vulnerability:
- NA 9.1x
- NA 9.2x
- NA 10.x
- NA 9.1x
NOTE: If you have Horizontal Scalability or Multi-Master you have to follow the next step in all your Cores.
For more information about the Bar Mitzvah vulnerability, please refer to: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2808
How to fix the Bar Mitzvah vulnerability in NA 9.1x?
The recommended approach is to upgrade to Network Automation 10 and install the latest available patch of NA. After upgrading to NA 10.x, it is required to follow the configuration steps for the java.security file as listed in the NA 10.x section below.
If upgrading to NA 10.x is not possible, then upgrade from NA 9.1x to NA 9.20 and then follow the instructions below for NA 9.20.
How to fix the Bar Mitzvah vulnerability in NA 9.20?
The recommended approach is to upgrade to the latest available patch of NA 9.20. After install patch 9.22.02, it is required to follow the configuration steps for the java.security file as listed in the NA 10.x section below.
NOTE: NA 9.22.02 is the latest patch at the moment of write this document.
Install NA 9.22.02 patch:
How to fix the Bar Mitzvah vulnerability in NA 10.x?
It is required to follow the configuration steps for the java.security file as listed in the “Configure the java.security file to disable the RC4 algorithm” section.
Configure the java.security file to disable the RC4 algorithm
This configuration is required for NA 10.x and NA 9.2x. See the 9.2x and 10.x sections above for details.
File location on UX based O.S:
File location on Windows O.S:
1. Within the java.security file, find the following property
2. If the property is commented, add a new line using the example mentioned in the next lines.
3. Add the following algorithms to the "disabledAlgorithms" list:
Example. The following is how it should look:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH
* If the property existed and was uncommented, simply add SSLv3, RC4 and DH to the existing list.
4. Restart NA services.
Note about the jdk.tls.disabledAlgorithms property
As the name suggests, this property controls which algorithms will be disabled to be used by this product during secure (TLS) communications. This means that any algorithm (also known as cipher) found in this list (when uncommented) will no longer be accepted or used for secure communications. Example of secure communications used by this product can be:
HTTPs (Secure HTTP)
LDAPs (Secure LDAP)
Care should be taken when configuring this property as other applications that need to communicate securely with this product can be dependant on the algorithm being disabled. Although highly unlikely, applications with support for a single cipher that is being disabled by this property will no longer be able to communicate securely with this product causing communication failure.
By default, the java.security file comes with the property commented and with a few algorithms in the list. The following is an example for a default configuration in an JDK7 installation
# jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 2048
If during the configuration suggested in this article, the disabledAlgorithms property ends up configured as the following example, a large number of highly known and well supported algorithms will be disabled, and the chances that certain applications that only support such algorithms fail will increase.
Should you encounter this scenario, or any other scenario where secure communication are broken following this configuration change, the following approach is suggested:
1. Leave the default property commented out.
2. Start with a new property with the minimun required values as follows: jdk.tls.disabledAlgorithms=SSLv3, RC4, DH.
3. Add algorithms one at a time to the list.
4. Restart NA and test all secure communications.
5. Repeat steps 3-4 untill all algorithms have been added.
If you encounter that disabling a specific algorithm breaks your secure communications with a third product:
Review the other product's documentation to find out if support for other algorithms can be added so that it does not depend on the specific algorithm being blocked.
If no good results, open up a support case to have this validated by HP